I am convinced that there simply isn't _any_ guaranteed,
foolproof way to associate a user's (or a CA's) Internet email
address with his certificate/distinguished name. There are
just too many possible mappings, both 1:many and many:1.
I may have multiple certificates (for different roles) and only
one mailbox, or I may have one certificate and multiple mailboxes
depending on the content (e.g., one for PEM, one for personal,
one for urgent business use, etc.)
I dissagree. If the Address <-> DN mapping is a straightforward
bijection as I have sugested in previous messages then it is
foolproof.
As I said in my message to Hoyt Kesterson on 5 Oct regarding
X.509 DN semantics, there is too much overlap of constructs
going on here. If I intend my DN to reflect my affiliation with
my company, I may have C=US, O=GTE, OU=GTE Labs,
CN=Robert Jueneman, but I may choose to send and receive
my email via CompuServe or some other VAN, in which
case my email address might be #12345(_at_)Compuserve(_dot_)COM(_dot_)
How could you possible derive that from my DN?
I would have to agree that a mapping which takes Jueneman(_at_)gte(_dot_)com
into
C=US, O=GTE, OU=GTE Labs, CN=Robert Jueneman is probably to ambigous.
The answer is to use DN's which align with RFC822 addressing methods.
Namely: map Jueneman(_at_)gte(_dot_)com to organisation=Internet,
domainNameComponent=com, domainNameComponent=gte, commonName=Jueneman
I have yet to hear any rational reasons why this wont work.
brad