Subject: RE: EmailAddress history question

From: "Tom Gindin" <[email-masked]>
Date: Mon, 5 Nov 2001 07:10:47 -0500

In this post, I will attempt to avoid personalities and offensive
characterizations of views differing from my own.  First, the case for
banning e-mail addresses from DN's is different between DN's in which at
least one personal name attribute (Surname, GivenName, or CommonName) is
present is much stronger than the case for banning them from DN's in which
no personal name attributes are present.  Second, AFAIK the usual
motivation for adding e-mail addresses to DN's is to enable directory
search by that attribute - neither obscenity nor ignorance have anything to
do with it.
     It is my opinion that rather than deprecating the use of emailAddress
in the subject name what should be deprecated is the use of emailAddress in
a subject name in which any of the personal name attributes are present.  I
am aware that this would involve a change to wording inherited from RFC
2459.

          Tom Gindin

"RAGHAVENDRAN H. (SSG) - CTD, Chennai." <[email-masked]>
@mail.imc.org on 11/05/2001 04:14:03 AM

Sent by:  [email-masked]

To:   [email-masked], [email-masked]
cc:   Anders Rundgren <[email-masked]>
Subject:  RE: EmailAddress history question

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
(snip)

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 5 Nov 2001 14:09:34 +0100

All,
I have no interests in  maintaining a debate that leads nowhere.
I have simply concluded that the *market* in the form of VeriSign
(e-mail certs), Microsoft (CertServ) and lots of more obscure players
have opted to [silently] disregard the 2459 in *this* particular case.
IMHO the weight of that should have made an impression in son-of-2459.

Case closed.  We can now all happily go back to our current
"best practices" or "favorite deprecations"!   :-)

Anders