From: Charles Breed <cbreed(_at_)pgp(_dot_)com>
These limitations are ALL related to the X.509 certificate structure.
If S/MIME (PKCS #7) could handle additional cert types, like PGP or
SDSI, life would be better :)
A pgp 'certificate' is comprised of 1) Key Packet w/preferred
algorithm, 2) User ID Packet, may contain DN, CN, email,... 3)
Signature Packets making the binding or assertion of Packet 1 and 2.
Since X509 has only one sig wrapped around the whole thing, it will
always be very limiting.
The X.509 certificate format itself is not inherently "very limiting".
It is trivial to encode the semantics of PGP or SPKI/SDSI into X.509
certificates, if that is the desired usage model.
For example, the User ID can be a DN (which includes CN as a subset),
an rfc822 or DNS name, EDI name, URI, IP address, and/or two forms of
privately-defined names (an OID itself, and a blob tagged by an OID).
Multiple names are allowed in a single certificate.
The Key Packet definition of the public key algorithm and parameters
is of course included in the X.509 subjectPublicKeyInfo field, and if
one wants to encode symmetric algorithms into certificates (I don't),
that can be done with extensions.
If you want different authorities (or the same authority) to bind
separate attributes together using separate signatures, that is the
precise purpose of the X.509 attribute certificate. An ID cert and a
collection of attribute certs taken together offer whatever Packet
(or Payload) structure you care to define. (I gag at the thought of
putting W3C/Java Manifests into an X.509 certificate extension, but in
theory that too could be done.)
If you want SDSI naming semantics (names local to the issuer -
"Billy-Bob's Dave"), you can of course put that kind of name into an
X.509 DN - as a naked CN. If you want SPKI names (no name, just the
hash of the public key), that can go in a DN too ("SN=92847cf8"),
although including the PK hash explicitly in a cert containing the
subject's public key would just be wasting space.
In other words, the ASN.1 certificate definition from X.509 does not
place restrictions on the contents or semantics or trust model that can
be embodied in those certificates. Traditionally, X.509 certs have
been used to encode heirarchical trust and global names, and the
defined set of extensions are geared toward enabling those models to
provide security for the X.500 Directory. But since local names are a
subset of global names, and the mechanisms for enforcing web-of-trust
are a subset of those required for heirarchical trust, the existing
X.509 certificate structure can be used in traditionally-non-X.509
environments simply by not using some of it's capability and by defining
other environment-specific extensions.
Arguments over certificate encoding are just red herrings. I don't
care how Simple SPKI turns out to be, an application that supports
X.509 and SPKI and PGP will be more complex than one that supports
X.509 only. X.509 can encompass all the functionality (trust model,
naming model, and authorization model) of SPKI and PGP, whereas the
converse is not true. X.509 is a framework, a vessel into which
diverse capabilities can be poured, the PKI equivalent of Base64.
A friendly challenge: I'll encode the most complex PGP-cert you can
come up with in X.509 format if you'll encode a traditional X.509-model
v3 cert in PGP format :-).
If everyone who needed to use Public Key Certificates would agree to
use a single low-level encoding, life would be better :-).