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 EMAILfirstname.lastname@example.org. 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
The file that defines the "OID value => name" correspondance of openssl is here :
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.