216123 - support X500 name chaining [NIST PKITS tests 4.3.3 4.3.4 4.3.5 4.3.10 4.3.11 fail]

Status: NEW

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 2

[Bishakha Banerjee]

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.

Comment 3

[Julien Pierre]

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 ?

Comment 4

[Robert Relyea]

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).

Comment 5

[Ralf Hauser]

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

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Removing pkix from whiteboard.
This bug is not specifically about libpkix.  
It may be implemented as an enhancement to libpkix.

Comment 8

[Julien Pierre]

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.