Subject: [pkix] non critical basicConstraints and keyUsage extensions

From: "Andris Berzins" <[email-masked]>
Date: Thu, 31 Jan 2013 12:17:49 +0200

Hello,
 
Lets assume there is certificate issued by CA where basicConstraints CA:FALSE
and keyUsage extension does not include certSign, but the extensions
are not marked as critical.

Is it allowed for relying party to use this certificate as CA certificate?
I know that openssl would not allow that even if extensions are not critical,
but is this a loophole and should it be very much advisable for CA to set
these extensions as critical?

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 31 Jan 2013 11:50:19 +0100

PKIX states that for a certificate to be usable for certificate
verification, it MUST have both a (MUST be critical)
BasicConstraints:CA=true and a (SHOULD be critical) keyUsage with
keyCertSign.
This is written in sections 4.2.1.3 and 4.2.1.9 for certificate issuers.
This is also repeated in section 6.1 (the validation algorithm) for
certificate consumers.

X.509 says things differently, the criticality is reversed, but that
doesn't really change the result.

A non compliant application (certificate consumer) could effectively ignore
non critical extensions and consider that any certificate is potentially a
CA one usable for certificate verification. But such a non compliant
application could also be so non compliant that it ignores the critical
bit. It could even only return "true" (or whatever suits a "all checks
passed, this certificate chain is OK" response).

PKIX can't do much more against non compliant applications.

2013/1/31 Andris Berzins <[email-masked]>

-- 
Erwann.

---

From: Bruce Stephens <[email-masked]>
Date: Thu, 31 Jan 2013 10:51:58 +0000

> Is it allowed for relying party to use this certificate as CA certificate?

No. See <http://tools.ietf.org/html/rfc5280#section-4.2.1.9>:

   If the basic constraints extension is not present in a version 3
   certificate, or the extension is present but the cA boolean is not
   asserted, then the certified public key MUST NOT be used to verify
   certificate signatures.

[...]

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 31 Jan 2013 09:54:14 -0500

It's not really a loophole.  RFC 5280, similar to X.509, already says:

    A non-critical extension MAY be ignored if it is not
    recognized, but MUST be processed if it is recognized.

Since it would be difficult to find path validation software that does 
not recognize these extensions, it would be difficult to find path 
validation software that could comply with this aspect of the standard 
and still not process the contents of these extensions, even if they 
were marked as non-critical.  Furthermore, Section 4.2 of RFC 5280 
requires conforming applications to recognize these extensions.

In addition, RFC 5280 already says that conforming CAs SHOULD mark the 
keyUsage extension as critical.

Finally, as noted before, the basicConstraints extension is somewhat 
"special" in that the path processing rules state for a version 3 
intermediate certificate, the application must "verify that the 
basicConstraints extension is present and that cA is set to TRUE."  If 
an application couldn't recognize the basicConstraints extension then it 
couldn't verify that it is present.

On 01/31/2013 05:17 AM, Andris Berzins wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: [email-masked] (Martin Rex)
Date: Thu, 31 Jan 2013 16:21:56 +0100 (CET)

Bruce Stephens wrote:
> > Lets assume there is certificate issued by CA where basicConstraints
> > CA:FALSE and keyUsage extension does not include certSign, but the
> > extensions are not marked as critical.
> >

Technically, the _above_ pointer into rfc5280 is wrong.  ;-)

rfc5280  is very explicit and RECOMMENDs __against__ including conformance
checks to the requirements listed in Section 4 and 5 of rfc5280!

  rfc5280, Section 6.1 Basic Path Validation (3rd paragraph):

  http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
*> profile.  While the algorithm could be extended to include checks for
*> conformance to the profiles in Sections 4 and 5, this profile
*> RECOMMENDS against including such checks.

Therefore the appropriate pointers would be either

  rfc5280, Section 6.1 Basic Path Processing

     6.1.4  Preparation for Certificate i+1

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

or

  ITU T-REC X.509 08/2005  Section 10.5 Certificate processing

   10.5.1 Basic certificate checks

   The following checks are applied to a certificate. Self-signed
   certificates, if encountered in the path, are ignored.

      b) For an intermediate version 3 certificate, check that
         basicConstraints is present and that the cA component
         in the basicConstraints extension is TRUE. If the
         pathLenConstraint component is present, check that the
         current certification path does not violate that constraint
         (ignoring intermediate self-issued certificates).

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 Jan 2013 07:32:24 -0800

> Is it allowed for relying party to use this certificate as CA certificate?

Allow me to throw a wrench in here. Did you mean "use this certificate as a CA certificate" or "use the key in this certificate as a trust anchor"? Those are two different questions that are often confused in practice.

--Paul Hoffman