Re: basicConstraints with CA=False in EE certs

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

chris.gilbert@xxxxxxxxxxxxx writes:

>ITU-T Rec. X.690 specifies that the default values for an extension should
>not be encoded. Thus, in EE certs where basicConstraints with CA=False is the
>default, the extension should be omitted at encoding. 

You don't omit the extension, you omit the BOOLEAN containing the CA flag,
resulting in a zero-length SEQUENCE, viz:

 543 30    9:         SEQUENCE {
 545 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
 550 04    2:           OCTET STRING, encapsulates {
 552 30    0:               SEQUENCE {}
            :               }
            :           }

>It is currently common practice, however, for CAs (some, not all) to encode
>CA=False in the EE cert.

They encode a zero-length SEQUENCE, which is the right thing to do.  From the
style guide:

  PKIX requires that end entity certificates not have a basicConstraints
  extension, which leaves the handling of the CA status of the certificate to
  chance.  Several popular applications treat these certificates as CA
  certificates for backwards-compatibility with X.509v1 CA certificates which
  didn't include basicConstraints, but in practice it's not really possible to
  determine how these certificates will be treated.  Because of this, it's not
  possible to issue a PKIX-compliant end entity certificate and know how it'll
  be treated once it's in circulation.

  The theory behind this usage is that applications should know that a v3
  certificate without basicConstraints defaults to being a non-CA certificate,
  however (even assuming that applications implemented this), if
  basicConstraints would have been the only extension in the certificate then
  defaulting to leaving it out would make it a v1 certificate as required by
  PKIX, so the v1 rules would apply.  To get the required processing, the
  certificate would have to be marked as v3 even though it's v1 (and the
  application processing it would have to know about the expected behaviour).
  In any case it's a somewhat peculiar use of the certificate version number
  field to convey certificate constraint information.

  One use for this feature is that it may be used as a cryptographically strong
  random number generator.  For each crypto key an application would issue 128
  basicConstraint-less certificates, hand them out to different
  implementations/users, and use their CA/non-CA interpretation as one bit of a
  session key.  This should yield close to 128 bits of pure entropy in each
  key.

>So, is anyone dealing with this conflict ? ie, at some point in the near
>future are we going to get an update to X.690 which says you *should* encode
>basicConstraints with CA=False in EE certs or are ITU waiting for i)
>Microsoft to fix their CSP and ii) V*risign to reissue all of their EE certs
>which contain this encoding ?

There are certain things in standards where the implementors know that you
ignore the standard and do what works instead.  This is one of them (the Style
Guide exists to document this implementation folklore, although it really
needs updating).

>Your thoughts are appreciated. The most up-to-date status of this problem
>would be of use to us.

See above.  That's been in the Style Guide for, I guess, about 5 years or so,
things haven't changed since then (I doubt the standards are going to change
to reflect reality, and reality certainly isn't going to change to reflect the
standards).

Peter.