Subject: Basic Constrains and Key Usage processing

From: Laurence Lundblade <[email-masked]>
Date: Mon, 24 Jun 2002 10:14:20 -0700

Continuing on with a cert chain processing implementation I have some 
questions about BasicConstraints and KeyUsage.

Essentially, is the following correct?

- Assume the cert being processed is not the leaf / end of the chain (i.e., 
it is trusted for out-of-band reasons or intermediate)

- If BasicConstraints is present, is critical, the CA boolean is true, AND 
KeyUsage is present, critical and does NOT assert KeyCertSign, then there 
is an error. (The issuer has erred and made the BasicConstraints and 
KeyUsage extensions inconsistent).

- If the KeyUsage extension is present, is critical and does NOT include 
KeyCertSign, then there is an error. (The issuer does not intend this cert 
to be used for signing other certs and is expressing this desire in the 
KeyUsage extension).

- If BasicConstraints is present, is critical and the CA boolean is NOT 
true, then there is an error. (The issuer does not intend this cert to be 
used for signing other certs and is expressing this desire in the 
BasicConstraints extension).

- There is no error for all other combinations of KeyUsage and 
BasicConstraints - their presence/absence, their criticality, their values.

It is important that this implementation process cert chains out in the 
world today (SSL chains in particular) correctly, and the way it seems best 
to do this is to ignore anything that isn't marked critical.

Also, I couldn't find anything in RFC 3280 that requires BasicConstraints 
to be present if KeyUsage is present. That is the issuer seems to have two 
ways to indicate that a cert should or should not be used to sign other 
certs. Is one preferred?

Thanks, and again hopefully I'm not missing obvious things.

LL

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 24 Jun 2002 14:12:02 -0400

Laurence:

>- Assume the cert being processed is not the leaf / end of the chain 
>(i.e., it is trusted for out-of-band reasons or intermediate)
>

The path you describe is not valid, but the mistake might not belong to the 
issuer.  The intermediate entity could have two certificates, one for 
validating CRL signatures and one for validating certificate signatures.

>to be used for signing other certs and is expressing this desire in the 

Correct. If the keyCertSign bit is not asserted in a critical KeyUsage 
extension, then the public key cannot be used to validate signatures on 
certificates.

>BasicConstraints extension).

Correct.  If the cA bit is not asserted in a critical BasicConstraints 
extension, then the public key cannot be used to validate signatures on 
certificates.

>world today (SSL chains in particular) correctly, and the way it seems 
>best to do this is to ignore anything that isn't marked critical.

I am not going to comment about certification paths that do not conform to 
RFC 2459 or RFC 3280.  I think that is what you mean by "out in the world 
today."

>ways to indicate that a cert should or should not be used to sign other 

In the discussion of KeyUsage, RFC 3280 says:

       ... If the
       keyCertSign bit is asserted, then the cA bit in the basic
       constraints extension (section 4.2.1.10) MUST also be asserted.

In the discussion of BasicConstraints, RFC 3280 says:

    ... If the cA boolean is not asserted, then the keyCertSign bit in
    the key usage extension MUST NOT be asserted.

Russ

---

From: Bill Middleton <[email-masked]>
Date: 25 Jun 2002 01:03:43 +0200

> questions about BasicConstraints and KeyUsage.

It  seems to me that your intent here is to assert  definition on the
critical boolean, especially when used in BasicConstraints, via defining
what it is not. Modssl (www.modssl.org) documentation warns gravely
about using the Critical option, due to the unpredictable reaction of
any given client implementation.  RFC2459 says that it can inhibit
interoperability, but still insists that all CA certificates have
BasicConstraints critical.

Perhaps Critical can be defined in this manner, but in light of the
number of V1 roots which are still "out there", not to mention some v3
CA's, it does seem to be something of an exercise in futility.  I do see
the utility of critical on some fields and extensions , but arguing
about it on BasicConstraints and KeyUsage seems overkill.  No?

Thanks,

Bill Middleton

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Jun 2002 19:18:39 -0400

>about it on BasicConstraints and KeyUsage seems overkill.  No?

Folks,

We had all these discussions a long time ago. The PKIX documents do 
not make concessions for legacy designs; they set standards for what 
should be done going forward.

Steve

---

From: Bill Middleton <[email-masked]>
Date: 25 Jun 2002 01:40:09 +0200

> should be done going forward.

I understand.  I'll refer to the archives.  Just to clarify, my
reference should have been to openssl, not modssl. Further, I did not
intend to open a can of worms, neither slight your efforts.  I look
forward to a review of the discussion via the archive.

Thanks again,

Bill
PS - I would be glad to have URL's in private email to what any of you
consider to be good discussion related to the topic.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Jun 2002 09:32:41 -0700

At 07:18 PM 6/24/2002 -0400, Stephen Kent wrote:

>We had all these discussions a long time ago. The PKIX documents do not 
>make concessions for legacy designs; they set standards for what should be 
>done going forward.

My goal is to build a cert chaining engine that works with real world 
SSL/TLS cert chains and is also modern, going forward and standards 
compliant. In particular I'd like it to be reusable with other applications.

My vague impression is that PKIX related to this and TLS, hence my 
questions here. Now, I've just done a look around to see if there was some 
other ID or RFC that was specific to X.509 and TLS and have found nothing.

So I'm guess I'm unclear what the intent of PKIX is for TLS/SSL in the 
past, present and future.

Thanks, LL

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jun 2002 12:56:06 -0400

At 9:32 AM -0700 6/25/02, Laurence Lundblade wrote:
>>not make concessions for legacy designs; they set standards for 
>>what should be done going forward.
>
>My goal is to build a cert chaining engine that works with real 
>world SSL/TLS cert chains and is also modern, going forward and 
>standards compliant. In particular I'd like it to be reusable with 
>other applications.
>
>questions here. Now, I've just done a look around to see if there 
>was some other ID or RFC that was specific to X.509 and TLS and have 
>found nothing.
>
>So I'm guess I'm unclear what the intent of PKIX is for TLS/SSL in 
>the past, present and future.

PKIX provides a set of standards intended to support a wide range of 
Internet protocols that are PKI-enabled. However, it is up to each 
protocol to specify the extent to which it makes use of the PKIX 
standards.

For example, S/MIME has been very good about this, but SSL/TLS and 
IPsec have not, although an ID was just released 
(draft-ietf-ipsec-pki-profile-00.txt) that is an attempt at this for 
IPsec (more properly IKE).

SSL/TLS is especially problematic. SSL was not developed in the IETF 
and the specification for what SSL does with certs is not part of SSL 
(or TLS), but is the domain of HTTPS.  HTTPS is not an IETF standard, 
and the only IETF publication I recall on HTTPS is an expired ID from 
1999! HTTPS behavior is essentially whatever is implemented in 
browsers, and because there is essentially a duopoly for browsers, 
this is an especially bad area to try to relate to PKIX standards.

So, it is quite likely that if you build an engine that mimics what 
browsers do re cert processing, it will not be PKIX complaint. If you 
then use this engine for other PKI-enavbled applications, you will be 
imposing on them the idiosyncrasies of a largely undocumented 
protocol that was not the subject of an open standards process.

Does that answer your question?

Steve

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Jun 2002 10:56:40 -0700

At 12:56 PM 6/25/2002 -0400, Stephen Kent wrote:
>>....
>protocol to specify the extent to which it makes use of the PKIX standards.
>
>For example, S/MIME has been very good about this, but SSL/TLS and IPsec 
>have not, although an ID was just released 
>(draft-ietf-ipsec-pki-profile-00.txt) that is an attempt at this for IPsec 
>(more properly IKE).
>
>...
>

It is very clear. Thanks very much for that explanation.

It does seem possible and useful to build a cert chainer that can be 
configured to work either in SSL mode or in PKIX mode so I won't give up 
entirely.

LL