Subject: RE: Question on basicConstraints from RFC 2632

From: "David P. Kemp" <[email-masked]>
Date: Mon, 11 Sep 2000 11:09:18 -0400 (EDT)

I believe a paragraph where one sentence says "does contain" and
the following sentence says "SHOULD NOT contain" the same information
would be contradictory and confusing.

However, a (very) careful reading of RFC 2632's "End-entity certificates
contain an extension that constrains the certificate from being an
issuing authority certificate." reveals that the extension in question
need not be basicConstraints.

RFC 2459 (the PKIX profile) says that BasicConstraints MUST appear in
CA certs and SHOULD NOT appear in end entity certs.  It also says that
the Key Usage extension, when used, SHOULD be marked critical.
Since nearly every end-entity cert will have a key usage extension
anyway and since that extension will preclude the EE cert from being an
issuing authority cert (if CA usage bit is not set), including
basicConstraints in EE certificates which also contain keyUsage is
superfluous.

In a typical example of a standard catering to every possible
viewpoint, son-of-RFC 2459 now says basicConstraints MAY appear, either
critical or non-critical, in end entity certificates.  I view this as
a step away from clarity; SHOULD NOT provides guidance without
prohibiting alternatives.

If son-of-RFC 2632 is going to contain MAY/SHOULD/MUST statements
concerning certificate extensions, I recommend aligning the CA
certificate requirement with PKIX and adding a clarifying sentence at
the end of section 4.4.1:

    Certificates SHOULD contain a basicConstraints extension in
    CA certificates, and SHOULD NOT contain that extension in end
    entity certificates.  End entity certificates SHOULD contain a
    key usage extension.

Section 4.4.2 could use a complete rewrite - it currently says nothing
about including keyUsage in EE certs, and also says nothing about
distinguishing between signature and encryption certificates.  It
delves deep into the details of encrypt/decrypt-only, which seems
especially bizarre given the absence of even a cursory discussion of
digitalSignature, keyEncipherment, and keyAgreement.  I'll provide some
suggested text for 4.4.2 later.

Dave

> From: "Darren Harter" <[email-masked]>
> 
> Gwangsoo Rhee,
> 
> The last paragraph states that an end-entity certificate SHOULD NOT contain
> a basic contraints extension, it doesn't say that it MUST NOT contain one.
> As a consequence, an end-entity certificate MAY contain a basic contraints
> extension, and it if it does the semantic meaning of that extension is as
> described in the first paragraph.
> 
> This is a typical example of the standard providing a discretionary
> recommendation rather than a mandatory instruction.  In this case it is
> quite right and proper, and aids interoperability.  It follows the usual aim
> of IETF standards in being precise in what you send, but flexible in what
> you receive.
> 
> Hope this helps,
> 
> Darren
> ---------------------------------------------------------------------
> Darren Harter B.Sc. (Hons) MBCS CEng
> European Professional Services Group,
> Entegrity Solutions Corp.
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gwangsoo Rhee
> Sent: 11 September 2000 06:51
> To: [email-masked]
> Subject: Question on basicConstraints from RFC 2632
> 
> 
> The material below is from RFC 2632.
> Seems to me that the statements about end-entity certificates
> in the last two paragraphs conflict with each other.
> One says that end-entity certificates contain a basicConstraints
> extension
> and another says they shouldn't.
> Maybe I misunderstood those statements.
> Could anyone please enlighten me on the subject?
> 
> Many thanks.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++
> 
> 4.4.1 Basic Constraints Certificate Extension
> 
>    The basic constraints extension serves to delimit the role and
>    position of an issuing authority or end-entity certificate plays in a
>    chain of certificates.
> 
>    For example, certificates issued to CAs and subordinate CAs contain a
>    basic constraint extension that identifies them as issuing authority
>    certificates. End-entity certificates contain an extension that
>    constrains the certificate from being an issuing authority
>    certificate.
> 
>    Certificates SHOULD contain a basicConstraints extension in CA
>    certificates, and SHOULD NOT contain that extension in end entity
>    certificates.
> 
> --

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 27 Sep 2000 02:42:27 (NZST)

Gwangsoo Rhee <[email-masked]> writes:

>The material below is from RFC 2632. Seems to me that the statements about
>end-entity certificates in the last two paragraphs conflict with each other.
>One says that end-entity certificates contain a basicConstraints extension and
>another says they shouldn't. Maybe I misunderstood those statements. Could
>anyone please enlighten me on the subject?

It's a problem with RFC 2459 which is covered, in the X.509 style guide,
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt.  Most of the certs
I've seen seem to ignore the RFC 2459 text, including a basicConstraints
extension in end entity certs, so the problems described in the guide shouldn't
occur much.

Peter.