Once upon a time , email addresses, especially "internet" or
rfc822 addresses, were a common component in X.509 subject names.
But a few years ago they became a deprecated component in PKIX
(RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have
language like this in their respective RFC's:
The email address SHOULD be in
the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject
distinguished name.
[RFC 2632 sec 3]
Could someone explain why this happened? I remember the process
at the time... but vaguely. Looking thru old notes & the mail
archives &c led me to a couple of possible explanations:
attribute EmailAddress added another string type, complicating parsing
[but what about other allowed attributes]
email addresses in general usually bring in their own hierarchy,
which may be askew from the directory [so?]
the email address + common name implies a path thru the directory,
which doesn't really exist ; eg cn=mike,e=mike(_at_)foo implies
there is a node e=mike(_at_)foo containing a leaf node cn=mike
[As a directory person, _I_ wouldn't think that way:^)]
None of these seem terribly convincing, except perhaps the middle one.
Are there better arguments?
I need to explain this to folks who know this capability exists
in CA's and / or remember using or seeing cert subjects with
email attributes in them. During the period when this was being
debated I really wasn't much concerned with it & don't remember
the issues very well. For that matter I personally don't care
one way or the other but don't want to issue certs with deprecated
contents any longer than necessary.
Thanks, ==mwh
Michael Helm
ESnet/LBNL