Re: test suite certs don't follow some RFC3280 MUSTs

[Sam Roberts <sroberts@certicom.com>]

Wrote "David A. Cooper" <david.cooper@nist.gov>, on Tue, Sep 02, 2003 at 04:27:12PM -0400:
> Sam Roberts wrote:
> >When running the cert chains through our validator, we found that CA
> >certificates lack the Key Usage extension (which must be present), and
> >that Basic Constraints are not always critical.
> 
> There is at least one test in section 4.6 (Verifying Basic Constraints) 
> in which the basic constraints extension is intentionally set 
> non-critical.  While RFC 3280 requires that this extension be critical, 
> that is a generation requirement.  Clients should be able to process the 
> extension even if it is non-critical.

I agree, but I think the test suite, if it is to be an example of RFC 3280,
should follow the generational as well as processing requirements.

Its not clear what the usefulness of a generational requirement with no
matching processing requirement is, so I was assuming that we should at least
detect that the cert isn't totally conformant. In practice, there are lots of
certs that aren't conformant, whether to trust them is ultimately a
user-decision, we just report what we find to them.

> I could not find any certificates in which the key usage extension was 
> not present.  However, there are some tests in section 4.7 (Key Usage) 
> in which an intermediate certificate includes a key usage extension with 
> either the keyCertSign or cRLSign bit set to false.  In such tests, 
> however, the paths should be considered invalid as a result of this.

> Were there any examples of the problems that you mention above in which 
> the contents of the certificates did not seem in line with the 
> description of the tests that use the certificates?  If so, could you 
> give me a specific example of such a certificate?

The tests are in line with the test descriptions, but the first CA in the first
test appears to me not to have a key usage, and to have a non-critical basic
constraints:

	Using cert: Trust Anchor CP.01.01.crt
	Version: 3
	Serial number: 99999
	Signature algorithm: p1-sha1-with-rsa-encryption
	Issuer: CN=Trust Anchor,OU=Testing,OU=DoD,O=U.S. Government,C=US
	Validity period (y/m/d h:m:s) UTC:
		not before 1999/01/01 12:01:00
		not after  2048/01/01 12:01:00
	Subject: CN=Trust Anchor,OU=Testing,OU=DoD,O=U.S. Government,C=US
	Subject public key: p1-rsa-encryption
		Type: rsa
		Modulus Size: 1024
		Modulus:
				 0:  D3F3B9C1 33B73FA7 27F6411D 5C9C799D AAD29510 B784CEDA A3E5580C
				28:  3E4E8B56 BF3EAA21 2D5013FE F3192E7A CB11CFF3 D3B85F57 9F9D9780
				56:  AF1D9557 12DF34D4 BDF3AE4D E77CA620 D4044EDA 63613E3D 2A8D37CF
				84:  C53CC9F9 FAF03948 0478BDB0 DDF52446 33A1469F 179F04BB CF37940C
			 112:  1343AA90 AC91781D BAF31884 2A822B47                           
		Exponent:
				 0:  010001                                                        
	[0] pkix-ce-subject-key-id: critical=no
		 0:  AB9AEBF9 C2E7548F                                                      
	[1] pkix-ce-basic-constraints: critical=no
		ca=yes path-length=-1
	[2] pkix-ce-authority-key-id: critical=no
		Key ID:
		 0:  AB9AEBF9 C2E7548F                                                      

Am I missing something?

Thanks,
Sam

-- 
Sam Roberts <sroberts@certicom.com>