Rhys,
I'd like to go back to some of the issues you have raised.
Just for the sake of argument, let's say that I buy your
argument about the desirablility of having the e-mail name
at least optionally available in the certificate, so that
a "bolt-on" PEM could access it by referencing the e-mail
name.
I would suggest that:
1. The user's common name should be used in addition, to
qualify the mailbox name. Many small offices have only one
mailbox, and they share access to it. You would want to be sure
who your were talking to (or listening to) in that case. The
user's common name is probably a more user-friendly index
to search for than the e-mail name itself, in any case.
2. While granting that you COULD break up the Internet name
into domainComponent names as you have suggested, I
don't understand any particular reason why you SHOULD
do so. It just seems to make a short Internet address look
like a complicated X.400 address, without adding any content.
I doubt that you intended to make it look more "official"? :-)
3. So suppose that we make up one attribute for the mailbox
name, let's call it pemMailbox, and one attribute for the
organization portion of e-mail address (the part that comes after
the @-sign -- I've forgotten exactly what it is called.) For the
moment, let's call the second one pemMailHost. I don't
particularly care whose arc these OID's are registered under,
or what their final names should be.
4. What else do we need? Well, in a previous message I
pointed out that even though any Internet mail address
is fully qualified, if you want to use it with any practical DUA
you'd better at least include the country code. In some
countries without NADF-type organizations, it may be ugly,
but necessary, to specify the ADMD also.
In my case, we would have
C=US, pemMailHost=GTE.COM, pemMailbox=Jueneman,
CN="Jueneman, Robert R."
If my secretary had access to my mailbox to receive unencrypted
mail sent to me, but to sign mail only under her own name,
we would have
C=US, pemMailHost=GTE.COM, pemMaibox=Jueneman,
CN="Neilson, Theresa"
In Peter William's horrific example, we would have
C=US, pemMailHost=cs.ucl.ac.uk, pemMailbox="/I=P
/S=Williams/OU=cs/O=ucl/PRMD=UK.AC/ADMD=GOLD 400
/C=GB/", CN="Williams, Peter"
A couple of notes:
1) pemMailHost and pemMailbox ought to be of type
directoryString, and preferably Teletex, of length at least
64, and perhaps 128.
2) Internet mailbox names are not supposed to be case
sensitive, so the ASN.1 description should be:
pemMailHost ATTRIBUTE ::= {
WITH SYNTAX DirectoryString (ub-pemMailHost)
EQUALITY MATCHING RULE caseIgnorematch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
ID { id-at-pemMaiHost } }
and the same thing for pemMailbox.
Temporarily ignoring the potential requirement for supporting
both e-mail names and traditional DNs, would this scheme
satisfy your e-mail-as-DN objectives? If it does, I'll address
the other potential requirements next week.
G'day, mate!
Bob