On Tue, 22 Feb 1994, Stephen D Crocker wrote:
3. So why not simply permit the use of ENs? A very good idea. We've
already said we'd do this. But then a funny thing happened. The
X.DN structure is a tad too restrictive. I'm told that some of the
normal EN special characters aren't permitted in ordinary text
values. Also, it's not clear what OID to use.
The RFC <-> X.400 mapping documents specify encodings for special
characters I believe (I haven't checked the latest versions of these).
Things like "(a)" for "@" and so on. So, this isn't a hassle IMHO.
To throw a cat into the fire, here's an e-mail <-> DN mapping scheme that
solves two problems: (a) having an automatable and reversible mapping
scheme, and (b) having a scheme that can be extended into a DNS-based CA
hierarchy if the Internet decides to go for that route.
Each e-mail address is translated into a DN of the form:
C=aa, O=Internet, OU=bb, OU=cc, ..., CN=nn
where "aa" is the top-level domain component on the e-mail address, "bb",
"cc", ... are the domain components in reverse order (encoded with the X.400
mappings where necessary) and "nn" is the local part (also encoded).
If the top-level domain component is not 2 characters in length, it
defaults to "US". If the top-level domain component is "US", then "bb"
is also "US" (see below).
So, rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au becomes:
C=AU, O=Internet, OU=edu, OU=qut, OU=fit, CN=rhys
crocker(_at_)tis(_dot_)com becomes:
C=US, O=Internet, OU=com, OU=tis, CN=crocker
Jueneman(_at_)gte(_dot_)com becomes:
C=US, O=Internet, OU=com, OU=gte, CN=Jueneman
kjhoule(_at_)iowegia(_dot_)dsm(_dot_)ia(_dot_)us becomes (I got this out of my
mail logs in case
you are wondering who this is. :-) ):
C=US, O=Internet, OU=us, OU=ia, OU=dsm, OU=iowegia, CN=kjhoule
The reason for the double-up in this case is to distinguish between
domains like "com" and domains like "com.us". As far as I know, domains
like "com.us" don't currently exist but if the US hierarchies are ever made
consistent with the rest of the world they could exist some day, and
reversibility of the mapping will be impossible without this hack. It's
not an overly ugly hack in any case.
Of course, there are nasties like jueneman%wotan(_at_)gte(_dot_)com, but they
aren't
impossible to handle:
C=US, O=Internet, OU=com, OU=gte, OU=wotan, CN=jueneman
Maybe something other than OU may be useful here, but there is no need to
get hung up about it because the number of people who don't have a
more usual address and have to use the '%' hack is decreasing all the time.
Even Bob has a normal address, despite the weirdnesses in his mailer.
We can quibble about upper versus lower case, whether we should use a
different OID from "OU", and whether "real names" should be in there, but
I think you get the basic idea.
The thing I like about such a scheme is that it gives plenty of points to
insert domain CA's while preserving the subordination rules. This is one
thing that Bob's CN="real name <email name>" proposal does not address.
Given that there is no technical reason why there can't be multiple CA's for
each domain, different PCA's can set up Internet-based hierarchies of CA's
with different levels of assurance but all with the same naming structure.
i.e. if you can trace the signing back to a commercial PCA, then it has
commercial assurance, but if you can only trace it back to a "well it is
unique but that's all it is" PCA, then it has a much lower level of
assurance. And of course, there is nothing stopping people getting
"conventional" DN's if they really want to.
Cheers,
Rhys.