210709 - CERT_FindCertByNameString doesn't find matching certs

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

CERT_FindCertByNameString should take a name string in the format specified 
by any of RFC 2253, RFC 1779 or RFC 1485 and, if any of the local tokens or 
temp cert caches contain one or more certs that match that string, it should
return at least one of them.  Today it often fails to find any.

Today, it does these two steps:

1. Calls CERT_AsciiToName to turn the name string into a DER-encoded 
Distinguished name, and then 

2. Calls CERT_FindCertByName to find the "best" cert by that name.

There are many problems with this approach.

1. CERT_AsciiToName doesn't properly handle all ASCII name strings that 
conform to the above cited RFCs, (see bug 210584 ).  So CERT_AsciiToName
may fail and return an error when the input string was perfectly good. and 

2. Because the ASCII form of cert names contains no information about the
DER encoding used for the values (e.g. printable string, universal string, 
etc.) when a cert name is converted to ASCII according to one of the above
cited RFCs, and then converted back to DER, the result may have different
encodings of the values, and therefore may not be identical to the original.
Therefore, trying to find a cert with a DER subject identical to the DER
name constructed from the ASCII string will fail for some names.  

Consequently, this function probably needs to be able to traverse the list
of known certs in tokens and caches, and compare each cert's subject name 
to the input name string using some comparison algoirithm that ignores the
encoding of the values (e.g. by converting them all to UTF-8 and comparing
those UTF-8 values).  

3. CERT_FindCertByNameString looks for the "best match" among certs with 
matching subject names.  The "best match" algorithm seems to be to find the
most recently issued cert with that name.  There are at least two problems 
with this approach.

a) it ignores the target date.  Perhaps we are looking for a cert that was
valid on some date in the past, on which a signature was made.  This function
should take an argument telling it a date on which the cert needs to be valid.

b) it ignores the usage.  Is the caller looining for a signing cert?  
an encryption cert?  An email cert?  an SSL cert?  None of that information
is supplied.  This function should take an argument that specifies the usage.

Another related problem (bug 210707 ) is that CERT_NameToAscii doesn't 
correctly translate cert names to ASCII strings.  Since that function 
will be the source of the ASCII strings input to CERT_FindCertByNameString, 
that bug blocks this one.

THIS BUG is primarily about the algorithm by which CERT_FindCertByNameString 
looks for a matching cert.  I think it is likely that we'll need to create
a new function with a new signature (new arguments) to properly implement 
this.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

There's more to this bug.
Today, it does 3 steps:
1. calls CERT_AsciiToName, which produces a CERTName which is a tree of 
structures that contain RDNs and AVAs.
2. calls SEC_ASN1EncodeItem to encode that into a DN, and then
3. calls CERT_FindCertByName to find a cert with that DN.

In addition to the problems reported above, there is another.  
SEC_ASN1EncodeItem doesn't properly encode SET OF.  
It doesn't sort the components in the SET after encoding them.
I will file a separate bug about that.  This bug will depend on that one.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This bug depends on 207711, which was just fixed.