Subject: basicConstraints with CA=False in EE certs

From: [email-masked]
Date: Thu, 6 Mar 2003 15:08:08 +0000

Apologies if this has been discussed recently. I had a look through
the archive and couldn't find a recent record of it.

There is presently a conflict in the exclusion of basicConstraints with
CA=False in EE certs.

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. It is currently common practice, however, for CAs (some,
not all) to encode CA=False in the EE cert.

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.

The net result is that not only is it desirable to have basicConstraints
encoded but also many already deployed certificate have this encoding
in them anyway despite the ITU recommendation. UA software that
is up-to-date with the recommendation stands to reject a significant
proportion of the deployed user community EE certs.

<pauses for breath>

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 ?

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

Chris

This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 11 Mar 2003 00:34:09 +0100

>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.