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.
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.
This bug depends on 207711, which was just fixed.