Subject: Problem with PKIX part 1 basicConstraints

From: [email-masked] (Peter Gutmann)
Date: Mon, 16 Nov 1998 14:58:25 (NZDT)

Section 4.2.1.10 says
 
>This extension MUST appear as a critical extension in all CA certificates.
>This extension SHOULD NOT appear in end entity certificates.
 
This is wrong, because without the basicConstraint to say the subject isn't a
CA, a relying party doesn't know how to treat the cert - you need to have an
empty sequence there for end entities.  Looking at some other profiles, both
X.509v3 (section 14.4.2.1) and the FPKI profile (to take the top two lying on
the stack) require an empty sequence for end entities.
 
Peter.

---

From: Tim Polk <[email-masked]>
Date: Mon, 16 Nov 1998 16:56:28 -0500

Peter,

I believe that the PKIX part 1 basicConstraints text is okay.

X.509 v3 does not require that the basicConstraints extension appear in
each certificate.  It simply specifies the processing rules if it is, or
is not, present.  The "NOTES" at the end of the section state:

<excerpt>1	If this extension is not present or is flagged non-critical
and is not recognized by a certificate-using system, then that system
should use other means to determine if the certified public key may be
used to verify certificate signatures.

2	To constrain a certificate subject to being only an end entity, i.e.
not a CA, the issuer can include this extension field containing only an
empty SEQUENCE value.

</excerpt><<<<<<<<

I believe the current PKIX text is not only consistent with X.509, but
specifies the appropriate practices.  Here's my "logic":

If the basic constraints extension is not present, certificate processing
is consistent with v1 or v2 certificates.  If out-of-band information
specifies the subject is a CA, it's a CA.  If out of band information is
not available, the user of the certificate assumes the subject is NOT a
CA.

If the basic constraints extension appears and is critical, certificate
processing may *only* consider the subject as specified in the
extension.

If the basic constraints extension is present, but is not critical,
certificate processors may honor the specified value, but are not
required to.

So, a certificate's subject is an end entity by default.  Using basic
constraints to specify that the subject is not a CA is a preventive
measure.  Out-of-band information specifying the entity is not a CA is
redundant.

The basic constraints extension OR out-of-band information can specify a
subject is a CA.

Section 4.2.10 requires the extension appear in all CA certificates, and
be marked critical.  The text recommends against placing this extension
in end entity certificates.

This has a few nice properties:

<paraindent><param>left</param>1) CA certificates are explicitly
specified by PKIX compliant CAs.  As a result, out-of-band information is
restricted to the idnetity of the "trusted CA(s)".

2) End entity certificates simply default to end entities.  This means
the majority of certificates will be a little simpler.

3) If an end entity wishes to accept a certificate without a
basicConstraints extension as a CA certificate, it must rely on
out-of-band information.  In this case, the responsibility lies on the
certificate user and the source of the out-of-band information, not on
the certificate issuer.  The certificate issuer attests to the binding of
subject and key, not the subject's status as a CA.

4) If CA wishes to ensure that the certificate user doesn't use the
certificate with out-of-band information to build a longer certificate
path, it may include a critical basicContraints extension stating this.

</paraindent>

Property 3) is actually very useful.  Here's a scenario:  NIST issues
certificates to NIST employees, but not contractors.  NIST issues
certificates to NIST employees, including me, omitting the
basicConstraints extension.  I issue certificates to contractors working
in the PKI lab.  Other folks on the NIST PKI project use out-of-band
information to determine that I'm a CA, and trust those certificates. 
It's not the NIST CA's concern, since the remainder of NIST is not fooled
into trusting those certificates.

By omitting the extension, we leave lots of flexibility.  The NIST PKI
maintains revocation information for me; if my key is compromised, the
NIST CA revokes my certificate and even the NIST PKI project team rejects
the contractors' certificates.

I don't know if anyone will use this feature, but it is conceptually
quite attractive.

Property 4) is also useful.  As a commercial vendor, I might charge more
to issue certificates to CAs than end entities.  By inserting a critical
basicConstraints extension, I keep my customers from ripping me off.

All in all, I think the PKIX profile for basicConstraints works correctly
and is consistent with X.509v3.

The FPKI profile predated the PKIX profile, and is out of synch in
several areas.  Now that PKIX is stable, the editor plans to modify the
FPKI profile to be more consistent.  The group that "owns" that document
met last week, and approved the changes.  I believe this is one of the
changes he plans, but I can't find my notes.  I will try to find them and
confirm that.

Thanks,

Tim