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.
cb
At 11:28 AM 7/3/97 -0700, John Myers wrote:
Ron Craswell wrote:
Imagine that there is no UA mapping mechanism and certificates are bound
to people directly by the E-Mail Attribute. Now imagine that you just
paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
you to undergo DNA testing and a polygraph scan. Now imagine your
e-mail address gets changed.
Imagine you marry or divorce and your name gets changed. Imagine you
move to another state and your drivers license and address gets
changed. Imagine your employer is acquired or divests and your
organizational affiliation gets changed. Imagine you emigrate to
another country and your national ID number changes.
Oh well... (or, heaven forbid, that you
have two e-mail addresses. Nevermind, nobody has more than one e-mail
address.)
So you put two e-mail addresses in the cert, or you have two certs for
the same key pair.
All sarcasm aside, the important thing is to map your understanding of a
person's identity with the contents of the data they're sending you. If
your understanding is based on their e-mail address then that's an
appropriate binding. If, OTOH, it's based on a VISA number, or Driver's
License, or SSN, etc. then that's what's appropriate to be in the cert.
If your understanding of an identity is based on something other than
their e-mail address, then there's no need for the UA to map their
identity to an e-mail address. The appropriate thing then is for the UA
to present the identity in the form that it is based.