Subject: Re: basicConstraints with CA=False in EE certs

From: Tom Gindin <[email-masked]>
Date: Sun, 9 Mar 2003 09:45:28 -0500

Peter:

      The safe procedure for issuers is to issue all v3 EE certificates
with a KeyUsage extension.  It is clearly against the rules for an RP to
treat a certificate with a KeyUsage present which does not contain
keyCertSign as a CA certificate, is it not?  RFC 3280 section 6.1.4 point n
certainly suggests this ("If a key usage extension is present, verify that
the keyCertSign bit is set").  RFC 2459 only enforced this when KeyUsage
was critical.
      IMHO we should recommend that any newly written or released RP
software follow RFC 3280 rather  than RFC 2459 in this respect, because of
the security dangers of allowing a PKIX-compliant EE certificate to act as
an intermediate CA.  We probably already recommend that, but following 2459
in this case is dangerous.

            Tom Gindin

                      [email-masked]                                                                
                      nd.ac.nz (Peter          To:       [email-masked],                  
                      Gutmann)                  [email-masked]                                      
                      Sent by:                 cc:                                                     
                      owner-ietf-pkix@m        Subject:  Re: basicConstraints with CA=False in EE      
                      ail.imc.org               certs                                                  

                      03/06/2003 10:56                                                                 
                      AM                                                                               

[email-masked] 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.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 11 Mar 2003 14:28:10 +1300

Tim Polk <[email-masked]> writes:

>As Peter implies, since the certificates include the extension but omit the
>boolean "which is the right thing to do", they are compliant with both RFC
>3280 and X.690.  No conflict here!

It's actually incompatible with RFC 2459, and only marginally compatible with
3280:

RFC 2459:

  This extension SHOULD NOT appear in end entity certificates.

RFC 3280:

  This extension MAY appear as a critical or non-critical extension in end
  entity certificates.

The 2459 text excludes it, and the 3280 text makes it highly optional, when in
fact it's "this had better be there or else" ("MUST", I think, would be the
accepted term).  At the current rate of RFC progression, I calculate that
it'll have made it up to "MUST" in [lunga pausa] 2008.

Peter.

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 10 Mar 2003 17:56:31 -0800

Although MSRC02-050 makes CryptoAPI conformant to the basicConstraints
and keyCertSign elements of the RFC to accommodate for this defect in
down-level clients that have not applied the fix you can do either:

1.    make sure that the issuing CA uses path length value in the
issuing BC

2.    make sure your end-entity certificate contains a basic constraints
ca=false

For more information on this see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/secur
ity/bulletin/MS02-050.asp

Hope this helps,

Ryan M. Hurst

Program Manager

Windows Security

-----Original Message-----
From: Jean-Marc Desperrier [mailto:[email-masked]] 
Sent: Monday, March 10, 2003 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: basicConstraints with CA=False in EE certs

[email-masked] wrote:

>To complicate matters Microsoft Security Bulletin MS02-050 describes

>an exploitation whereby unpatched CSPs do not process

>basicConstraints at all leaving them vulnerable to ID spoofing attacks

>( CAN-2002-0862 ) . This problem is fixed by a patch which enforces

>a check on basicConstraints.

BTW if ever you were not fully satisfied by the solution given by Peter,

you can create certificate that are conformant to RFC2459 (no 

basicConstraint) and will be protected against this problem by making 

sure the Basic Constraint of the CA that emits them as a path length 

restriction of 0 (final CA, can only emit EE certs).

Microsoft fails to give the kind of really detailled explanation about 

the problem that would help implementers, but tests show that all 

version of the CAPI/application that will take into account the CA=false

basicConstraint, will also take into account the path length restriction

of 0.