I'm looking at NSS 3.9 and one difference I noticed with previous version NSS 3.8:
The cert object I get back from PK11_FindCertFromNickname() is a struct of type CERTCertificate. When I get the cert subject name using cert->subjectName, I noticed that, with NSS 3.9, the DN string does NOT have spaces between the DN sub-components (eg, "CN=joetester,OU=Testing,O=testCorp,C=US").
The DN returned in NSS3.8 did however have spaces (eg, "CN=joetester, OU=Testing, O=testCorp, C=US").
THere were a number of bugs with the cert name strings produced by NSS prior to 3.9. The strings produced by older versions of NSS did not always fully conform to the relevant RFCs.
For example, when a name contains multiple attributes in a single RDN, those attributes are supposed to be separated by "+", rather than ",". A comma should separate RDNs, and a plus should separate attributes within an RDN. But older NSS used comma to separate all attributes, making it impssible to determine when an RDN contained multiple attributes. The presence of the spaces between attributes was another aspect that did not strictly conform. This lack of conformance was causing interoperability issues with other implementations of cert code.
The strings produced by NSS 3.9 are much more conformant. But in order to achieve that conformance, it was necessary for the code to produce different strings than it did before.
This is casuing me a little bit of a headache with my NSS app when trying to identify a certificate by comparing the cert subject name with a fixed know string...
Understood. Perhaps that's why NSS never uses that method to compare two cert names. :)
NSS compares the DER-encoded names using SECITEM_ItemsAreEqual. The DER form is also in the CERTCertificate struct.
Has there been a know change with spacing in the cert strings returned
by functions like PK11_FindCertFromNickname()? (I have a feeling that
the CERTCertificate struct is private
If we ever produce an NSS 4.0, its cert struct will be private, but the CERTCertificate in NSS 3.x is public. We go do some pains to preserve binary compatibiltiy of this structure from release to release, because we know that code outside of NSS uses it (although it could be argued that we did not succeed with respect to these strings). Code outside of NSS shared libraries should treat it as "const" (read only).
> and I should not rely on strings like cert->subjectName...)
Yes, that's true. Here's another aspect of that issue for consideration. The standard says that two attributes should compare as equal if they only differ in whitespace. For example, CN="Fred Flintstone" and CN="Fred Flintstone" and CN=" Fred Flinstone " should all match, if they are encoded as printable strings (as they typically are, at least historically). So, one way for you to approach this problemis to write a much more involved comparison function that ignores whitespace.
I'm intentionally glossing over some details here. If you want the full story, read RFC 2253 and 3280.
-- POC
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
