Subject: Re: 2459 disapproved by MSFT and VeriSign?

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

Olaf,

>As far as I know at least Microsoft interprets rfc822Name in
>subjectAltName if present.

They do.

>Maybe to encode both EmailAdress and
>subjectAltName in general is the right solution for this problem.

Will the REAL e-mail address solution, please stand up! please stand up! please stand up!

Pardon the joke.  Let's be serious:

The current Microsoft, VeriSign solution (email address attribute) is already widely implemented
and is spreading with the help of CertSrv.  It is accepted "everywhere" but in 2459. 
I.e. 2459 is not "de-facto" standard conformant and should be updated.

>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).

This is probably true but is this a question related to 2459?  I would say it looks
more like a bug reports for Microsoft and Netscape.

Regards
Anders

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2000 14:28:56 -0400

Anders,

This has a familiar ring. You often argue for modifying our standards 
to accommodate some vendor approach, irrespective of architectural 
merit.  That's not how the IETF pursues standards.  That's why TLS is 
not backwards compatible with SSL, for example.

Steve