210707 - CERT_NameToAscii produces incorrect strings for some names

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

CERT_NameToAscii needs to produce strings that conform to at least one of 
RFCs 2253, 1779 or 1485.  Today, it produces strings that do not conform to
any of those RFCs for some cert names.

In particular, it does not use "+" to separate AVAs in the same RDN.  

Also, it should escape and quote according to RFC 2253, and does not.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Upon further investigation, I find that bug 39494 was not actually fixed.
There were several problems.
1. unrecognized tags are supposed to be displayed in the form
   OID.<dotted.decimal.oid>
   but NSS was displaying only the dotted.decimal.oid, and not the leading "OID."

2. Hex strings that begin with an "octothorpe" ('#") are not supposed to be 
   quoted, but NSS was quoting them.

I have a patch that fixes all these things.  I'm working out a few more details.
RFC 2254 says that multi-valued RDNs may display the Attribute types and values
in any order.  That does not facilitate recreation of DER binary DNs.  I have
to determine what is the proper order in which to display the ATAVs in a
multi-valued RDN.  Presently, we display RDNs in reverse order, but we display
the ATAVs in each RDN in forward order.  I suspect that's wrong, but RFC 2253
doesn't help.  Need to find out what other implementations do.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I see another issue here.  

Sometimes, CERT_NameToAscii is used to create names for the purpose of
displaying to a user.  In that case, we want the names to be as user friendly as
possible, not displaying values in hex unless absolutely nececssary,and not
displaying OIDs in decimal when we are able to express the type with a string.

At other times, CERT_NameToAscii is used to create a name that can be passed to
another system (e.g. XML) where hopefully the cert's DER subject DN can be
correctly reconstructed from it.  In that case, we want to use dotted decimal
OIDs for every type not declared in RFC 2253, and we want to use the hex value
for for EVERY value, including values for attributes with types defined in RFC
2253.  This is user unfriendly in the extreme.  

If I change CERT_NameToAscii to strictly adhere to RFC 2253, the results will be
much less user friendly than they are now.  So, I suspect the thing to do is to
create a new NSS function, perhaps named CERT_NameToAsciiInvertable or
CERT_NameToAsciiRFC2253 or some such.  

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I have learned today that mozilla (and its derivatives) has its own copy of
the function CERT_NameToAscii which is used by the certificate manager to
build the strings of attribute types and values displayed in the cert details.

Consequently, fixing NSS's function will have neither positive nor negative
impact on the cert manager displays in those programs.  :-( 

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: test cert, issuer name has multi-valued RDN and unknown type OID

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Fixed by rev  1.13 of nss/lib/certdb/alg1485.c

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Fixed by rev 1.13 of nss/lib/certdb/alg1485.c

Comment 7

[Kai Engert (:KaiE:)]

Nelson, do you know which particular function in PSM should be changed to do
what you did in this bug?

Should a PSM bug get filed?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Kaie,  The mozilla function that duplicates much of CERT_NameToAscii is
"ProcessName" in
http://lxr.mozilla.org/security/source/security/manager/ssl/src/nsNSSCertificate.cpp#1225

Recently, CERT_NameToAscii (and the functions it calls) were enhanced/fixed 
in a number of ways including:
- providing readable strings for many more name attribute types than before,
- using a different delimiter for RDN boundaries than for AVA boundaries within
an RDN, so that the RDN structure is not lost in the output
- properly displaying unrecognized OIDs in dotted-decimal, and 
- properly displaying attribute values in unrecognized encodings, or values for
unrecognized OIDs.

Perhaps not all these enhancements are applicable to PSM.  I would encourage
PSM to use as much of NSS as it can (as opposed to duplicating NSS functions),
and to try to track NSS closely on enhancements to NSS functions whose
functionality has been essentially duplicated in PSM.