Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 220427 - Recognize OpenSSL's DN Attribute short names
: Recognize OpenSSL's DN Attribute short names
Status: NEW
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.8
: All All
: P4 enhancement (vote)
: ---
Assigned To: nobody
Depends on:
Blocks: 210709
  Show dependency treegraph
Reported: 2003-09-26 22:25 PDT by Nelson Bolyard (seldom reads bugmail)
Modified: 2006-08-28 15:53 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description Nelson Bolyard (seldom reads bugmail) 2003-09-26 22:25:56 PDT
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  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.
Comment 1 Jean-Marc Desperrier 2004-01-14 03:42:20 PST
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 :

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.
Comment 2 Nelson Bolyard (seldom reads bugmail) 2004-01-14 14:09:59 PST
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.
Comment 3 Jean-Marc Desperrier 2004-01-15 05:38:30 PST
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.
Comment 4 Nelson Bolyard (seldom reads bugmail) 2004-01-15 13:21:59 PST
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.

Note You need to log in before you can comment on or make changes to this bug.