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

Title:
Sam Roberts wrote:
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).
Sam,

As I said before, I could not find an example of a certificate that does not include a key usage extension.  Even the self-signed trust anchor certificate includes critical key usage and basic constraints extensions (at the end of this message is a printout of the trust anchor certificate that was generated using OpenSSL).

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.)
This test suite is designed to be used to determine whether an application properly validates certification paths.  The certificates and CRLs in the test suite should not be considered as example certificates.  In many cases, the certificates or CRLs intentionally include unusual or incorrect information so that certain boundary conditions can be tested.

I want to assure you, however, that when NIST generates certificates and CRLs for actual use, we do observe the generation requirements of RFC 3280.  In fact, NIST maintains a "Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL Extensions Profile" (see http://csrc.nist.gov/pki/twg/y2002/papers/twg-02-18.xls or http://csrc.nist.gov/pki/twg/y2002/papers/twg-02-18.sxc) specifying certificate and CRL generation requirements for Federal agencies and we ensure that this profile is consistent with RFC 3280.

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?
The path validation algorithms in both X.509 and RFC 3280 are both very clear that the self-signed certificates are merely convenient packages for distributing trust anchor information (name, public key, and possibly public key parameters).  The CA that issues the self-signed certificate will also be the issuer of the first certificate in any certification path (if the certification path is validated using the information in that self-signed certificate as the trust anchor information).  Any constraints that the CA wishes to impose must be specified in each certificate that the CA issues.  If the CA wishes to limit the number of intermediate certificates to 1, then it can include a path length constaint of 0 in each CA certificate that it issues.

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).
Except that RFC 3280 explicitly states that this should not be done:
When the trust anchor is provided in the form of a self-signed certificate, this self-signed
certificate is not included as part of the prospective certification path.

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.

If there is confusion in the standard, then this should be addressed in a future revision, but we should not tie generation and processing requirements together.  Specifying a profile that is restrictive in how certificates and CRLs are generated helps to enable interoperability.  There is no similar benefit in rejecting certification paths simply because they contain certificates that were not generated in accordance with that profile.  RFC 3280 is simply a profile of X.509.  Other organizations have written their own profiles of X.509 and these profiles do not necessarily conform to RFC 3280's profile.  We shouldn't be telling path validation client implementors that their applications should reject certificates simply because the certificates were generated based on a different profile.

-------------------------------------------------------------------------------------------------------------------------------
Self-signed Trust Anchor Certificate (TrustAnchorRootCertificate.crt):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Test Certificates, CN=Trust Anchor
        Validity
            Not Before: Apr 19 14:57:20 2001 GMT
            Not After : Apr 19 14:57:20 2011 GMT
        Subject: C=US, O=Test Certificates, CN=Trust Anchor
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d2:16:28:3f:96:aa:43:9b:f5:75:a4:83:9e:a5:
                    02:3d:e2:82:93:98:8f:cf:1e:d5:ae:80:5c:3f:a1:
                    65:5f:a0:35:56:03:ae:e4:4d:ed:97:d4:0c:f1:ba:
                    a7:5e:5f:52:46:e1:88:5b:2c:70:e9:72:c4:69:da:
                    74:b9:2b:6f:a7:17:57:0d:6b:70:81:b7:66:67:67:
                    73:e0:38:06:45:bd:34:31:d6:c0:b7:33:36:3c:ac:
                    19:78:4c:b7:a7:d3:39:60:20:f5:68:d9:d6:79:c6:
                    80:59:c3:f5:c5:be:e4:8a:b7:de:b2:eb:cd:f1:ad:
                    6a:41:7b:54:37:87:76:2f:45
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
            FB:6C:D4:2D:81:9E:CA:27:7A:9E:0D:B0:3C:EA:9A:BC:87:FF:49:EA
            X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
            CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
        63:4a:26:29:f2:6e:e3:bc:53:14:27:7c:8d:92:6f:61:19:71:
        5c:b0:30:52:63:c7:4e:b3:52:78:0e:18:34:65:da:79:3e:16:
        33:c8:b2:42:39:ff:2f:52:55:91:dd:fb:88:57:64:7f:e8:76:
        4b:11:5e:10:b6:f6:c3:82:e5:c8:df:6e:c4:e1:c5:18:05:c0:
        e9:1f:1c:22:05:1a:1e:14:f7:a5:e0:b9:9f:7c:4c:4b:f0:f5:
        d2:6b:9e:35:51:0d:66:62:d1:37:c9:94:ac:dd:44:dc:1a:4b:
        e2:67:ff:e7:c3:24:91:d5:43:03:4b:2b:fa:64:67:b1:fd:75:
        88:d3


Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov