Subject: 2459 disapproved by MSFT and VeriSign?

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 18 Sep 2000 18:25:01 +0200

Hi,

From RFC2459

"In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[email-masked]" is the same as
   "[email-masked]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (see sec. 4.2.1.7) to describe such
   identities.  "

Now, the problem (correct me if I am wrong) is that s.c. legacy is what is actually
sold, shipped and marketed by two really major vendors, Microsoft in their
latest Certificate Server and VeriSign through their class #1 e-mail certificates.

IMO these guys have a higher weight than 2459 and son-of-2459 should be updated
accordingly.  I can hardly see that the others will ever change their stuff.  Particularly
as just about every system out there already is compatible with "legacy".

Regards
Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 19 Sep 2000 16:18:05 -0400 (EDT)

> From: "Anders Rundgren" <[email-masked]>
> 
> The E= in Subject *IS* a standard way of putting e-mail addresses in 
certificates! 
> By far the most common solution also... 
> 
> To "criminalize" that is far too late.
> 
> The recommendation in 2459 has no important architectural merit. If it had, 
people 
> would follow it. Quite simple logic there IMO. It is just a result of 
> "historical" problems and 2459 should also say that. I.e. there are *two* 
EQUALLY
> conformant solutions which is admittedly unfortunate but nothing to do about 
except accepting. 

The merit of putting alternative names in the SubjectAltName extension
is that distinguished names and rfc822 names are from different
namespaces.

Yes, you can use the syntax of RDNSequence to contain an rfc822name,
just as you can use it to contain a copyright and limitation of
liability statement.  But the fact that it is both syntactically
possible and "VeriSign/Microsoft standard" to stuff absolutely anything
into the subject Name field does not imply that mixing RDN attributes
from different namespaces (or no namespace at all) has architectural
merit.  Nor does the fact that large numbers of people use what they
get for free imply that what they use is architecturally sound.

---

From: Peter Williams <[email-masked]>
Date: Wed, 27 Sep 2000 14:41:14 -0700

Anders,
 
http://www.microsoft.com/WINDOWS2000/guide/server/solutions/EIM.asp
for some forward thinking to dwell on. It bridges the early
Netscape-vision
of https and PKIX, and goes beyond PKIX author's apparently
somewhat limited  infrastructure vision to make PKI useful for 
relationship-oriented security.

Peter.

>Steve, now this deviation between a (rather late) standard-2-be and 
>its likely implementation is very close to be happening
>once again (right in front of thousands of PKIX-list users):
>
>The s.c. "Permanent Identifiers" that is in draft format is IMO a 
>real candidate for similar deficiencies and ambiguities due
>to this rather rigid view of what a DN is and must be.  How come?
>
>1.  Permanent Identifiers have been in active use for quite some 
>time (5y+).  There are even commercially available products from
>TTPs like VeriSign/eccellerate (organization certificates with DUNS 
>numbers) and from the Swedish Post Office (ID-certificates
>with citizen registration numbers).  And AFAIK these products use 
>the subject DN as the place to put the PI info
>(The use of Subject Alt Name except *maybe* for e-mail is still 
>considered "exotic" and its value is not fully understood).

<edit out>

>2. The PI-draft will give a new "home" for these permanent 
>identifiers.  Problem solved? Well, not really.
>Due to the already existing use of PIs in DNs, and an increasing use 
>of mapping software, the "old" scheme will (MUST)
>continue to live FOREVER.  I.e. the new "standardized" PI home will 
>contain duplicate (=REDUNDANT) information.
>
>Solution: IMO The PI-draft should have specified a non-critical 
>extension that points out what components of
>a DN that constitutes the PI.  I.e. a DN "filter" formula that the 
>RP may understand or not.  Such that a CA can
>introduce it at any time without breaking any code or changing 
>existing (by a minority perceived as bad) habits.

Thanks for your opinion.  I'll leave it to Denis to address details 
of your comments during last call.

Steve