Rhys,
Thanks for posting your draft. As we discussed, I think this is an
interesting idea that has the potential for saving the investment
we've made in X.500 style distinguished names.
In looking at how a PEM implementation would make use of your scheme,
I would suggest the slightly tighter rule of reserving the RM
attribute for just the string to the left of the @, and using the DC
attribute for the components of the host name.
The e-mail address encodings may include an optional "commonName"
(CN) attribute in the same set as the "rfc822Mailbox" attribute,
indicating the actual name of the entity. For example:
<{DC=au}, {DC=edu}, {DC=qut}, {DC=fit}, {RM=rhys, CN="Rhys
Weatherley"}>
This provides greater flexibility, and permits translation of the
common Internet "name <address>" and "address (name)" formats. The
"commonName" attribute is optional, but encouraged. Any of the usual
string representations for the attribute may be used.
The same idea also permits adding synonyms for the DC attributes.
That is, the suggestion in the next section is not fundamentally
different from the fusing of CN and RM attributes.
The encodings described above are intended to guarantee some level of
uniqueness with respect to other X.500 naming authorities. Compliant
PEM implementations would normally conceal the X.500 structure from
the user and present the Internet syntax.
4. Specifying E-mail Addresses In Traditional DN's
It may sometimes be desirable for a user with a traditional X.500 DN
to include their e-mail address in the DN so that it can be signed
and bound to the user's public key together with the DN. To
facilitate this, a RM attribute may appear in a traditional DN as a
member of the same set as the CN attribute. An example of this is
the following:
<{C=AU}, {O="Queensland University of Technology"}, {OU="Faculty
of Information Technology"}, {CN="Rhys Weatherley",
RM="rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au"}>
Note that there are now two meanings for the RM attribute. They may
be distinguished by the presence of a DC attribute. If there is a DC
attribute in the DN, then the RM attribute has the meaning from
section 3, and if there is no DC attribute in the DN, then the RM
attribute has the meaning from this section.
I would avoid this form and use DC attributes.
5. Interleaving Traditional DN's With Internet Addresses
[Note: this mechanism was suggested by Steve Crocker. I'm not sure I
like it myself at the moment. It needs lots of discussion. It also
needs consultation with X.500 experts to determine if it is
feasible/desirable.]
It is possible to interleave the encodings presented in section 3
with a traditional DN, to produce a single DN which contains both a
traditional DN and an e-mail address encoding. Two examples follow:
<{DC=au, C=AU}, {DC=edu}, {DC=qut, O="Queensland University of
Technology"}, {DC=fit, OU="Faculty of Information Technology"},
{RM=rhys, CN="Rhys Weatherley"}>
<{C=US}, {DC=com}, {DC=gte, O="GTE Laboratories"},
{RM="jueneman%wotan", CN="Bob Jueneman"}>
These encodings can be processed in two separate ways by compliant
PEM implementations to extract the traditional DN and the e-mail
address.
This mechanism does have one slight draw-back: it is difficult, if
not impossible, to automate the process of choosing which domain
component corresponds to which attribute in the traditional DN to
interleave the two. Therefore, user input would be required to guide
the DN-creation process. The mechanisms from sections 3 and 4 do not
require such guidance.
I had in mind that the interwoven form is what the user or CA creates.
I did not have in mind ever attempting to weave
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"}, {CN="Rhys
Weatherley"}>
and
<{DC=au}, {DC=edu}, {DC=qut}, {DC=fit}, {RM=rhys}>
into a DN after the fact. The only time the idea of weaving these
together should come up is in a discussion of the concepts involved.
It is also unclear at this stage as to whether such encodings would
confuse existing PEM and X.500 implementations.
Yes, this needs to be checked, but I think that if DC and RM are
standard attributes, there's no reason why an existing implementation
should be affected. These are, after all, just examples of legal DNs.
Note that these examples attempt to pair up the domain components with
the structure of the distinguished name. Some users and/or CAs might
attempt to use this scheme a bit differently. It would appear
consistent with this proposal to have CAs issue certificates in the
usual way and let each user issue himself a subordinate certificate
with the his email address encoded. Thus, if the CA at Queensland
University of Technology issues Rhys Weatherly a certificate with the
DN of
<{C=AU}, {O="Queensland University of Technology"}, {OU="Faculty of
Information Technology"}, {CN="Rhys Weatherley"}>
Rhys could then issue himself a certificate of
<{C=AU}, {O="Queensland University of Technology"}, {OU="Faculty of
Information Technology"}, {CN="Rhys Weatherley"}, {DC=au}, {DC=edu},
{DC=qut}, {DC=fit}, {RM=rhys}>
However, this has the drawback that Rhys can lie about his mailbox and
fool someone. For example, he could just as well issue a certificate for
<{C=AU}, {O="Queensland University of Technology"}, {OU="Faculty of
Information Technology"}, {CN="Rhys Weatherley"}, {DC=com}, {DC=tis},
{RM=crocker}>
and it would still follow the name subordination rule. Therefore, a
PEM implementation needs to check that the mail address is
legitimately assigned, and this requires checking up through a path
that corresponds to the domain name.
To be clearer about this, whenever a certificate with the DN of
<{DC=au, C=AU}, {DC=edu}, {DC=qut, O="Queensland University of
Technology"}, {DC=fit, OU="Faculty of Information Technology"},
{RM=rhys, CN="Rhys Weatherley"}>
is received, it would have to checked through a chain that included
<{DC=au, C=AU}, {DC=edu}, {DC=qut, O="Queensland University of
Technology"}, {DC=fit, OU="Faculty of Information Technology"}>
and
<{DC=au, C=AU}, {DC=edu}, {DC=qut, O="Queensland University of
Technology"}>
and
<{DC=au, C=AU}, {DC=edu}>
and
<{DC=au, C=AU}>
all of which should be straightforward. However, when
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"}, {CN="Rhys
Weatherley"}, {DC=com}, {DC=tis}, {RM=crocker}>
shows up, it would not be sufficient that it had been issued by the
a CA named
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"}, {CN="Rhys
Weatherley"}>.
There would also have to be a check made to see if
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"}, {CN="Rhys
Weatherley"}, {DC=com}, {DC=tis}>
<{C=AU}, {O="Queensland University of Technology"},
{OU="Faculty of Information Technology"}, {CN="Rhys
Weatherley"}, {DC=com}>
existed in the chain, and in particular, the issuer for the latter
must be a recognized top level authority for the domain name system.
All a bit complicated, admittedly. The only alternatives I see,
however, are to dispense with the usual form of DNs completely and
switch directly to email addresses.
Steve