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

[Tim Polk <tim.polk@nist.gov>]

Sam,

My comments in-line...

At 12:08 PM 9/3/2003 -0400, Sam Roberts wrote:

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

X.509 is extremely flexible; while it defines numerous extensions none of 
them are mandatory to implement.  The IETF PKIX work was intended to 
promote interoperability by focusing vendors efforts on support for the 
most important certificate extensions.  If the generation requirements are 
followed, all the certificates contain information to assist in path 
building and discovery and the CRLs are posted in well-defined 
locations.  Name forms common to the Internet are (relatively) well-defined 
and reasonable limitations are specified for length of names, sizes of 
integers, etc... to help vendors focus efforts on the important 
aspects.  All of these generation requirements should contribute to 
interperability.

However, RFC 3280 certainly does not require implementations to reject 
valid X.509 paths because the certificates don't conform to our generation 
requirements!  We were extremely careful when we wrote Section 6 to ensure 
that our path validation algorithm accepted valid X.509 paths, and rejected 
invalid paths.

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

The generation requirements reduce the likeliehood of encountering an 
unknown critical extension.  Where redundant options exist (e.g., the email 
address in the subject DN vs. the rfc822Name in subjectAltName) generation 
requirements promote consistent usage.  They also let a vendor winnow the 
list of features to support (e.g., which X.520 attributes should be built in?)

Anyway, I believe the generation requirements have value on their own.

> > 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?

First, you seem to have found the certificates and CRLs from the previous 
version of the test suite.  V1.07 (from 2000)... the current tests are the 
PKITS test suite described at the top of 
http://csrc.nist.gov/pki/testing/x509paths.html

Second, the only information that is required from a Trust Anchor 
certificate is the subject name, the public key, and the parameters.  Other 
information is sometimes included, but the 3280 path validation algorithm 
does not make use of it.

I re-checked 3280 and you are correct that the text of 3280 requires 
inclusion of these extensions, even in a trust anchor certificate.  I am 
trying to remember why; I believe that many implementations reject trust 
anchor certificates that do not contain these extensions.  I guess we 
included them for interoperability with common implementations.

>Thanks,
>Sam
>
>--
>Sam Roberts <sroberts@certicom.com>

Hope that helps,

Tim