Subject: Re: 2459 disapproved by MSFT and VeriSign?

From: [email-masked]
Date: Mon, 18 Sep 2000 18:10:13 +0200

As far as I know at least Microsoft interprets rfc822Name in
subjectAltName if present. Maybe to encode both EmailAdress and
subjectAltName in general is the right solution for this problem.

There is another problem with those "legacy" implementations that may be
discussed together with this issue: Microsoft and Netscape both fail to
encode/decode T61Strings correctly. They encode for example umlauts using
ISO8859-1 and expect T61String to carry this encoding, which is wrong. In
T.61 "München" has to be encoded as "MÈunchen" (hopefully these special
characters make it to everyone on this list) but Microsoft and Netscape
write and expects to get "München". Since DER require T.61 encoding for
the word "München" (I've been told), you end up with the options:

encode wrong but get the correct display of the certificate in those
applications (which may cause problems with applications that
decode/encode certs prior to signature calculation and other operations),

encode right but get an odd display,

do not use anything else then PrintableString encodable items in certs.

None of these options look very attractive. For me this problem looks
harder to resolve cleanly. (By the way, Microsoft screwed the T.61
encoding up in LDAP v2 requests as well).

--
Olaf Schlüter, Manager Trust Center Systems and Services
Giesecke & Devrient GmbH, Prinzregentenstr. 159, D-81607 München
Phone: +49 89 4119 2531, Fax: +49 89 4119 2490
http://www.gieseckedevrient.com

"Anders Rundgren" <[email-masked]>
18.09.00 18:25

        To:     "PKIX-List" <[email-masked]>
        cc:
        Subject:        2459 disapproved by MSFT and VeriSign?

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: [email-masked] (Terry Hayes)
Date: Mon, 18 Sep 2000 10:26:49 -0700

> subjectAltName in general is the right solution for this problem.

Netscape products will also recognize and use rfc822Name values in
subjectAltName in addition to the "legacy" method of embedding the value in
the subject name itself.

> do not use anything else then PrintableString encodable items in certs.

If you look at RFC 2459, you will see that it suggests interpreting T61String
as containing ISO8859-1.  This is, of course, incorrect, but is there entirely
for compatibility with these sorts of implementations.  One small correction,
Netscape products do not actually attempt to encode or decode values in
T61String beyond the set of ASCII 7-bit characters.  In recent products,
values that don't fit in PrintableString are encoded into UniversalString.
This has its own problems, since many implementations don't understand that
either.

> do not use anything else then PrintableString encodable items in certs.

RFC2459 says that by 2003 everything should use UTF8String.  This encoding can
handle the full set of Unicode characters.

Terry