From: "William H. Geiger III" <whgiii(_at_)openpgp(_dot_)net>
Perhaps I am a little slow here but this does not make sense. My
understanding on an Identity CA like Verisign is to verify and certify the
identity of a keyholder not what he is going to do with the key. If
Verisign signs my key certifying that the holder of public key 0xFFFFFFFF
is William H. Geiger III what difference does it make what I am doing with
that key?? If Verisign want's to sign keys signifying more than that then
they should have a separate signing key to do so (one key to certify
identity, a separate key to certify someone as a CA).
It seems that there is an attempt to push PGP down the same ugly path that
X.509 has gone down. Using the key as a payload for dynamic data opens up
a whole list of problems that PGP does not need to be saddled with.
Equating VeriSign with X.509 is too narrow a view. In an environment
where the CAs are not third parties, but part of the user's security
domain, it sometimes makes sense to carry privileges in certificates
which also certify an identity. And sometimes it doesn't. X.509
supports the following three scenarios (along with others which may
be less useful):
1) binding a digital signature public key to a name only. The name
can then be used on access control lists.
2) binding an encryption public key to a name and a set of roles,
privileges, and categories.
3) binding a set of roles/privileges/categories to another (base)
certificate, using an "attribute certificate" which contains
no public key at all.
Instead of saying "here's a technology, what can we do with it", it
makes more sense to say "here's our problem, how can we use technology
to solve it". The public key certification problems I see usually boil
down to the three X.509 scenarios above: long term (multiple years)
identity, medium term (1 year) categories such as nationality or
security clearances, and locally-administered access to information,
which may range from hours or days up to a year. The problems faced by
web site operators and addressed by third party CAs such as VeriSign
may differ, so the ways they choose to use X.509 may also differ.
The problems of grass-roots trust establishment are different
still, and PGP has evolved to satisfy them.
What do you mean by "ugly path"? And is it a result of business
drivers you may not necessarily agree with, rather than a feature or
limitation of a particular technology? If there is "an attempt to push
PGP ...", perhaps the attempt is motivated by a specific real-world
problem or business scenario. And perhaps those with the ugly problem
would be better served by X.509, rather than by pushing PGP in an
unnatural direction.