Michael,
The story is that rfc822 addresses in the Subject Field become
deprecated for reasons like not fitting into a directory-oriented scheme.
PKI-Politics++
The interesting part is that practically no *practitioners* care
about this deprecation as this use is the "de-facto" standard.
Not even VeriSign care (check their personal e-mail certs as
found in this signed mail if you want to confirm this),
in spite of being active in the authoring of 2459!
I'm pretty sure that this will not change as the problem by having
e-mail addresses in the subject field is *unknown* by the majority
of certificate issuers. My guess is that you run into *less* problems
by using the de-facto standard as there are probably quite a few
systems out there ("inferior" but anyway), that don't bother with
SubjectAltName. To use duplicate data as 2459 suggests seems
like a political thing (follow the "true" and "de-facto" standard
at the same time), rather than an example of good engineering.
As a conforming PKIX/SMIME-app MUST interpret the "de-facto"
standard there are no problems at all by using it. The
"deprecation" will BTW have no effect as no SW engineer in
his right mind, will ever remove support for the current practice as
it is likely to just lead to complaints.
Personally I don't think SubjectAltName has any value at all
in the long-run, as it just adds confusion (i.e. multiple places
to look for identity information). An ID-certificate does
typically only need to contain a CN and some unique identity tag and
an e-mail address is such an option. OID.2.5.4.5 is another.
Once upon a time the idea was that a certificate should contain
your entire personal profile but that's got totally out of style since the
advent of on-line operation, and then the Subject field continues
to be completely satisfactory as the *only* container of identity data.
PKI-Politics--
Anders
----- Original Message -----
From: "Michael Helm" <helm(_at_)fionn(_dot_)es(_dot_)net>
To: <ietf-pkix(_at_)imc(_dot_)org>; <ietf-smime(_at_)imc(_dot_)org>
Sent: Friday, November 02, 2001 17:11
Subject: EmailAddress history question
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
smime.p7s
Description: S/MIME cryptographic signature