Mark,
The proposal that Rhys is working on has the form of interweaving the
usual attributes with email attributes. My interpretation of what
Rhys is proposing is that two attributes, DC and RM, will be reserved
for mail addresses. The DC attribute will be use build up the domain
name on the right hand side of the @. The RM will hold the entire
left hand side of the mail address. Thus
M(_dot_)Wahl(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk is
represented as
<{DC = uk},
{DC = ac},
{DC = ucl},
{DC = cs},
{RM = M.Wahl}>
This can be interwoven with a more descriptive
<{C = UK},
{O = "University College London"},
{CN = "Mark Wahl"}>
(Maybe I left out some of the RDN's in your DN; add them in when you
respond.)
The weaving process generates something like:
<{DC = uk, C = UK},
{DC = ac},
{DC = ucl, O = "University College London"},
{DC = cs},
{RM = M.Wahl, CN = "Mark Wahl"}>
One might insist that the combined DN be doubly unique, so that the EN
can be extracted to yield a unique EN, and the remaining components
also yield a unique DN. This is conservative in the sense that these
compound DNs are at least as safe as the existing DNs and also make it
easy to extract and/or index by EN. Alternatively, one might permit
DNs which have just DC and RM components and no other data. In either
case, this form of names makes it possible to build certificate
fetchers and responders that work off of ENs, which I think is an
essential feature.
Comments?
Steve