This RFE is similar to bug 207711. NSS needs to understand ASCII encoded cert names generated by OpenSSL. OpenSSL has its own set of "short names" for DN atribute types. NSS needs to recognize those short names to interoperate. An example is EMAILemail@example.com. Today, NSS does not recognize the short name "EMAIL". NSS recognizes "E" and "MAIL" but not "EMAIL". I do not yet have the complete list of OpenSSL's short names. This is primarily an issue for XML Dsig and XML encryption, I think. XML tends to pass cert DNs in ASCII form rather than in DER form.
And how hard is it supposed to be to get the complete list of OpenSSL's short names ? The file that defines the "OID value => name" correspondance of openssl is here : http://cvs.openssl.org/getfile?f=openssl/crypto/objects/objects.txt First colon is OID, second is short name, last is long name. The first colon uses already defined short name as a shortcuts. Most of the interesting identifiers should be around the place where you'll find the "X509 3" string. Note that recent version of openssl make more of an effort to use LDAP standardized ASCII representation, so you might still need a bit more info than just this, I'll try to add it.
With regard to "short names", we are committed to using STANDARD short names, and NOT using other implementations' non-standard short names. It is true that the IETF has been exceeding slow to adopt a standard for short names, but the solution is NOT to adopt non-standard names.
Well, it sounds then than the best thing is to close this bug as "WONTFIX" as the commitment you descrive seems incompatible with implementing it. In fact, what I saw about the evolution in the identifiers between openssl 0.9.6 and 0.9.7, 0.9.7 trying to use IETF defined identifiers, already makes me doubtful it is really possible beyond one or two simple cases.
My last comment appears to contradict the request, and I am the requestor! Here's the issue. NSS has one table that it uses to recognize incoming short names, and also to generate short names to send out. I am concerned that if we accept OpenSSL's non-standard names, but do not send them, then people will find that it's a one-way street. Mozilla will accept stuff from openSSL, but not vice versa. That's unacceptable. But so is sending out non-standard names. Perhaps the right solution is for software vendors (such as mozilla, openSSL, and others) to come to some defacto "industry standard" agreement among themselves concerning short names. But until this happens, I don't see a good solution to this problem.
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.