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

[Sam Roberts <sroberts@certicom.com>]

Wrote Tim Polk <tim.polk@nist.gov>, on Thu, Sep 04, 2003 at 05:50:10PM -0400:
> My comments in-line...

Thaks for taking the time to comment in such detail, I appreciate the
background information.

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

You are correct. I thought I redownloaded these tests just a few weeks
ago to get the most recent, but I obviously didn't.

Even in the most recent certs, basic constraints isn't critical, and
key usage is missing, so the certs don't serve as an example of a cert
that follows the RFC3280 generation requirements (even though that
doesn't affect the cert path processing).

I'm probably just being annoyingly pedantic, but its also a little
annoying to have a bunch of MUSTs in RFC 3280 and have NIST publish
a test suite that ignores them, even if the test suites purpose is to
test validation, not generation. If NIST doesn't have to follow the
generation MUSTs, why should I have to follow the processing MUSTs?

(Answer: because my implementation MUST, really, interoperate with
commercial PKIs, no matter what they do.)

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

Of course, you are right.

However, it leaves me confused.

Almost every self-signed root cert that is used as a Trust Anchor
includes extensions. Some of these extensions (such as Basic
Constraints), would seem to affect the validity of paths built from the
root. I.e., you could have a Trust Anchor with a Basic Constraints
limiting the number of intermediate certs to 1.

But, according to the 3280 path validation algorithm, the extensions
of the trust anchor are not an input to the validation algorithm. Does
that mean that these extensions should be deliberately ignored by
me while doing validation?

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

OK, so that would be somebody misreading RFC3280, seeing that the Basic
Constraints was required in all CA certs, and not noticing that even
though that means a Trust Anchor cert must have a Basic Constraints,
that Basic Constraints should be ignored from the point of view of path
processing?

> I guess we included them for interoperability with common
> implementations.

As an implementor, I have to say that the obvious way to do validation
would be to treat the trust anchor's cert like any other CA cert in the
path, and process its extensions like any other CA's extensions,
including things like Basic Constraints and Key Usage, if present (and
technically, they MUST be).

Would you consider my implementation, that would reject a path
containing intermediate certs when the trust anchor's cert has a basic
constraints with a path-length of zero, to be a misreading of 3280?

What about if the path-length (in the Trust Anchor cert or in any other
CA cert in the path) was zero, but there is no Key Usage extension?
4.2.1.10 says the path-length constraint isn't valid if the KeyUsage
doesn't have the keyCertSign bit asserted...

That its a little hard to figure out all these corner cases is both good
and bad, I feel. It's bad, because its difficult to figure out exactly
what a perfectly "correct" implementation is, but its good because
implementations end up just having to be aproximately right - and the
NIST test suite ends up being a great way of testing whether my choices
roughly match up with other people's, so we get rough consensus and
running code.


Cheers,
Sam

-- 
Sam Roberts <sroberts@certicom.com>