NSS fails the NIST tests for Name Chaining Whitespace and Name Chaining Capitalization. RFC 3280 says on page 21 that cert users MUST perform name chaining for cert path validation according to certain rules. These rules state that PrintableString components are not case sensitive for comparison purposes, and that leading and trailing space is to be stripped, and multiple consecutive white spaces are to be collapsed into a single white space when comparing PrintableStrings. According to these rules, an issuer name with a CN component such as CN="Good CA" or CN=" Good CA" or CN=GOOD CA should all match an issuer name with a CN component such as CN=Good CA NSS uses these rules for name constraints testing, but not for simple comparison of cert subject names to issuer names (that is, not for name chaining). For name chaining, NSS requires the entire DER encoded issuer name to exactly match the issuer's entire DER encoded subject name. Consequently, NSS fails the NIST tests for Name Chaining Whitespace and Name Chaining Capitalization. AFAIK, we have never seen this problem except in this test suite. This raises the question: Is NSS's present comparison rule good enough for the real world, and how long will it remain so? If we must change NSS in this way, this implies a change to the cert DB format as well. The "issuer and serial number" index will have to be changed to a canonical format in which all printable string components have been downshifted, all leading and trailing space has been removed and all redundant whitespace has been removed. Terry, do you think this is an ungent issue?
One other related issue. Name "rollover". This is described very briefly on page 19 of RFC 3280. Despite the statement on page 21 that "attribute values encoded in different types [...] MAY be assumed to represent different values", apparently UTF8 names should be able to match PrintableString names. The NIST test suite has test cases for this, and NSS fails them. It's unclear to me whether and how the rules about case insensitivity and redundant space elimination apply to comparisons between UTF8 and PrintableString.
Summary: NSS fails to find cert issuer due to name matching issues → NSS fails NIST name chaining tests
The vfychain commands to test these chains were: for test3: vfychain -d $PKITSdb ValidNameChainingWhitespaceTest3EE.crt GoodCACert.crt TrustAnchorRootCertificate.crt for test 4: vfychain -d $PKITSdb ValidNameChainingWhitespaceTest4EE.crt GoodCACert.crt TrustAnchorRootCertificate.crt for test 5: vfychain -d $PKITSdb ValidNameChainingCapitalizationTest5EE.crt GoodCACert.crt TrustAnchorRootCertificate.crt Note that the tests required TrustAnchorRootCRL.crl and GoodCACRL.crl to be in the db, test results were the same with them in the db, and without.
Summary: NSS fails NIST name chaining tests → NIST PKITS name chaining whitespace and capitalization tests fail
Summary: NIST PKITS name chaining whitespace and capitalization tests fail → NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail
Nelson, Bob, This issue is becoming important now as part of the libpkix project. Let's discuss the possible cert db / softoken change. a) Doesn't PKCS#11 specify that the search is based on the exact attribute value match when doing a C_FindObjects with a particular subject ? In which case, even if the softoken did a smart X500 compliant CN match, this would break PKCS#11 spec. b) Is there another attribute for the canonicalized subject CN that we would be able to search on that would be what we want ? To do efficient queries, the database would have to be index by canonicalized CN, so that would indeed require a DB change. However, that's unlikely to be something that's implemented in other PKCS#11 modules. And NSS needs to be able to work with all PKCS#11 modules. The simpler, but much less efficient possibility, is to query all the certs in all PKCS#11 modules / tokens, canonicalize their subject, and then filter the results. This would be an extremely inefficient thing to do repeatedly. It occurs to me that we have a cert cache, and it's probably the right place to do the canonicalizing, and we should add the ability to search the cached based on that attribute. The trick is to avoid falling back to the full token search. Bob, do you have any input on that approach ?
You are quite right. There is not searching in pkcs #11 except on exact strings, and there is not 'cannonicalized Subject' value. In theory, these attributes were all set the by application (though some PKCS #11 modules derive them from the certificate itself). As you surmize, we could extend softoken to either 1) do cannonical matches when searching subjects, or 2) store special attributes to do cannonical searches. This, of course, will not work with other PKCS #11 modules. One option might be to set a threshold. If the token has less than N certs (10, 20, 50?) then we would just cache those certs locally and keep our own indexes to them. If the token has more certs, then it must have this special attribute (which we should also try to get through the PKCS #11 working group) which stores the cannonicalized SUBJECT. When creating a certificate we will always set this value (PKCS #11 modules are not expected to know how to cannonicalize). The spec should specify how to cannonicalize so applications can interoperate. One question, isn't printable strings supposed to be depricated soon in favor of UTF8 strings (in which case this issue goes away?). Wait nelson's UTF8 comment means that this just get worse (sigh).
Summary: NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail → NSS does not support X500 name chaining [NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail]
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
The world is going UTF8 as expected in comment 1 with bouncy castle v1.34 by default now using UTF8String instead of PrintableString. A recent TB unfortunately is neither able to handle this nor does it give any clues why it will not import a cert as per bug 310446 comment 33
RFC 3280 has been updated by RFC 4630, which changes the rules (AGAIN) about choice of character sets for encoding and about comparing name attributes with different character set encodings. It's very short and worth a read. Notable among its changes are these: [...] CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with one exception. When CAs have previously issued certificates with issuer fields with attributes encoded using the TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings of the DirectoryString to preserve the backward compatibility. and Since name comparison assumes that attribute values encoded in different types (e.g., PrintableString and UTF8String) *are assumed* *to represent different strings*, any name components that appear in both the subject field and the issuer field SHOULD use the same encoding throughout the certification path. IMO, these changes obviate matching of UTF8 and PrintableString encodings. However, the rules for matching PrintableString attributes (ignore case, ignore leading and trailing spaces, collapse multiple internal spaces) remain as before. :-/ See also bug 386871.
Removing pkix from whiteboard. This bug is not specifically about libpkix. It may be implemented as an enhancement to libpkix.
Severity: normal → enhancement
Summary: NSS does not support X500 name chaining [NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail] → support X500 name chaining [NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail]
Slavo, I think you just have to ignore the failures for these test cases. The X500 name chaining is now outside of the Internet RFCs (RFC 4630). So, i don't think we are going to attempt to make this work in NSS.
You need to log in before you can comment on or make changes to this bug.