ietf-smime
[Top] [All Lists]

RE: EmailAddress history question

2001-11-05 02:32:44

Hi List:

My view on this is subjectAltName is a good thing. I know this has been an
issue for quite some time, but as a programmer I find the concept of putting
an email in the DN "obscene". I tend to agree with Steve's posting on this.
Email addresses are now being used to uniquely identify persons. In future,
it may be IPv6 addresses and still further in the future... who knows.
subjectAltName provides a convenient, future-proof way of implementing this
instead of "cluttering" your DN.

My 2 cents..

Regards,
Raghav

-----Original Message-----
From: Anders Rundgren [mailto:anders(_dot_)rundgren(_at_)telia(_dot_)com]
Sent: Saturday, November 03, 2001 12:37 AM
To: helm(_at_)fionn(_dot_)es(_dot_)net; ietf-pkix(_at_)imc(_dot_)org; 
ietf-smime(_at_)imc(_dot_)org
Subject: Re: EmailAddress history question


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


***********************************************************************
Disclaimer: 
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.
***********************************************************************



<Prev in Thread] Current Thread [Next in Thread>