I'm responding to this note because I think its important. Note, however, that
there no longer appears to be a proposal on the table that calls for the
removal of the non-cert mechanisms from MIME/PEM. As such, this is now
an entirely academic discussion as far as I'm concerned, one which has
little if anything to do with the current MIME/PEM specification.
In order to be concrete, let me propose a certificate that looks something
like
the following:
Certificate=signature{
SubjectDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>},
serial=1;
IssuerDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>, serial=0;
other necessary junk}
Assuming that the PEM/MIME implementation creates the certificate so that the
user doesn't have to calculate it by hand, why on earth does this raise the
bar
more than about a centimeter off the floor? How much simpler could it possibly
get?
More like 100 meters, I'd say. You think this is simple enough, and from the
perspective of someone that deals with this stuff all the time it probably
looks OK. But just isn't that simple.
Let me illustrate this by pointing out a very specific problem in your
supposedly simple example. You've included a personal name field in the
address, and doing so for this purpose is in fact incorrect. Personal names are
not useful as part of a distinguished name. They are completely under the
user's very casual control, and may in fact change on every single message a
user sends. (I routinely receive mail from people who do this, and in fact we
have a gadget on our system here that generates random email personal names.)
There are also lots of cases where personal name fields end up getting lost,
removed, or even amended. This is fine since they are inherently write-only and
only serve to communicate limited information to recipients. They are entirely
untrustworthy and as such any inclusion of them in a distinguished name should
be completely forbidden.
As such, personal name information, along with any RFC822 comments (which are
used for all sorts of things besides communicating names) should not be
included in this field. Doing so will practically guarantee interoperability
problems.
There's also the issue of source routes and percent hacks. I'd be in favor of
dropping the former and would say you have to keep the latter, but this
is also something that would need to be dealt with.
I think the fact that you of all people would make this mistake illustrates the
problems with this approach far more eloguently than anything else I could say.
Likewise, if you want to use some other form of globally unique identifier as
a
certificate DN, maybe even someone's country code and phone number, that's OK
too, although I personally might not give such a certificate much credance.
By your statement "But now you've bought everyone into setting up their
distinguished names and all that", I have to conclude that you don't agree
that
the use of an RFC822 e-mail attribute would be acceptable for use as a DN in
an
X.509 certificate.
There are many other problems with the currently defined attributes for RFC822
addresses. For one thing, the ones I'm familiar with are only useful as
information returned by the directory -- they are not capable of being used as
part of a distinguished name. Specifically, they typically allow a list of
addresses rather than a single, canonical address. (This is a matter of
implementation practice rather than what any of the specifications say, I'm
afraid. In particular RFC1274 is silent on whether or not you can put more than
one email address in an RFC822Mailbox attribute. But you'll find that this is
what happens in practice.)
The bottom line is that current thinking about this stuff equates RFC822
addresses more with attributes like "GIF image of person's dog" than with
something that's intended to be used as some kind of identifier.
Another, more insidious problem is that the people who defined some of these
attributes obviously didn't know much about RFC822 email. The syntax rules are
appalling, and inconsistent with RFC822. This is not acceptable.
The final, crushing blow comes from the fact that there's no single
standardized attribute to use for this. The one we normally use is what's
defined in RFC1274 (which I note is long past the date by which it should have
been revised). In order for certificates to be at all inobtrusive there has to
be a single, universally standardized attribute for this purpose with specific,
standardized content. I don't believe this is the case at present, and until it
is the bar is about 1000 meters up, in my opinion.
I can only think of two reasons why you might think that. The first would be a
concern that the rfc822 attribute is not included in X.521's list of
(allegedly) "useful attributes," and is therefore nonstandard and difficult to
sell. I don't agree, but if you wish, use another attribute. How about
commonName, or even description? Using a more strongly typed and accurate
attribute like rfc822 would be preferable, but would the X.500 standards
police
come and put us all in jail if we dared to misuse one of their holy attributes
in a PEM certificate, i.e., outside of X.500? If so, put a different OID on
it
and call it "pemCommonName."
This makes matter much much worse rather than beter, and illustrates the
complexity of DNs quite nicely.
The second reason might be that you are hung up on equating the DN in the
certificate with a DN that is used to uniquely qualify and sometimes look up
an
entry in an X.500 directory, and are concerned that existing directory schemas
might not support that usage. In other words, you might feel that both the DN
in the certificate and the DN in the directory have to make use of the same
organizational or geopolitical naming scheme, as God, ISO, and the ITU
apparently intended.
I could not care less about the use or non-use of actual directory services for
this, so this is entirely irrelevant.
At this point in the deployment of PEM and/or PEM/MIME, I don't think it would
be prudent to even assume that X.500 exists, much less that it is the norm.
So concerns about whether the use of an rfc822 attribute as a DN in a
certificate would conform to someone's X.500 directory schema should be of
very
little concern.
I don't assume anything about X.500. It doesn't and won't exist in all the
places where I need it to be, so it is irrelevant as far as I'm concerned.
The only connection with X.500 that concerns me is that use of it tells
us something about how difficult DNs and certs are to use in practice. And
what it tells us isn't good news.
In point of fact, however, there is no reason at all that I am aware of that
would require that the DN in the certificate match the DN of the entry that
contains the certificate. Indeed, the users identified by the directory DN are
not necessarily even one-to-one with the number of certificates, so such a
correlation will generally be impossible.
In summary, I hope that I have illustrated why certificate-based systems can
be
simple and easy to use, especially if rfc822 email names are used as DNs in
self-signed certificates.
You have done exactly the opposite, as far as I can tell.
Ned