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

From: [email-masked] (Peter Gutmann)
Date: Fri, 7 Mar 2003 04:56:13 +1300

[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: Tim Polk <[email-masked]>
Date: Mon, 10 Mar 2003 11:23:02 -0500

Chris,

One final point to add to Peter's excellent writeup.  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!

Thanks,

Tim Polk

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Mar 2003 14:26:36 +0100

The EU directive introduced a requirement on each CA, issuing QC (Qualified 
Certificates), to clearly indicate in these certificate that they are 
issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic signature 
directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications, 
since they don't need to recognize specific QC Policies, ETSI didn't make 
solution 1) mandatory or even consider making it critical, due to lack of 
confidence that clients would widely deploy this solution. ETSI needed to 
define a solution that could work even if no one choose to implement the 
new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with 
different QC policies and even those policies that are regarded 
standardized may be updated with change of OID as a result. It would be 
devastating if we can't update a QCP because that would force an OID update 
and that would render certificates useless because clients learned to 
recognize only the old OID. This would be to build in a new root 
certificate problem into the platforms.

My observations is that times have changed. I have seen clear indications 
that market players want, and even require for interoperability reasons, 
that use QCStatements solution is made mandatory and maybe even critical 
for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to 
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are there 
other legal systems that make use of the same declaration logic as the EU 
directive, where the RFC 3039 profile is used fully or partly as a solution 
to this issue?

- I would suggest that the QCStatement mechanism is ought to be a mandatory 
tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such as 
TS 101862)?
    3) If there could be a clear context defined where criticality could be 
allowed or even required?

I would really like feedback from practical experiences from this issue, as 
well as constructive proposals.

/Stefan

/Stefan

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
+46-706 443351