Subject: RE: Changes to RFC2459

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Apr 1999 15:16:34 -0500

Jim & Moshe,

I admit to being confused at this point.  My reading of PKIX and X.509
suggests the folowing simple test, (coded in Kent++):

- IF BasicConstraints PRESENT AND
	IF BasicConstraints.cA PRESENT
		THEN certificate-is-ca
		ELSE certificate-is-ee
	ELSE certificate-is-ee

This is consistent with PKIX, which calls for the extension to be present
and non-NULL for a CA cert, but recommends that it be absent for an EE
cert.  It is consistent with X.509, which requires the extension to always
be present and non-null for a CA, but suggests that it be present and NULL
for an EE.  X.509 also suggests that if the extension is not present, then
a system may choose to employ other means to determine if it is an EE or a
CA cert.  But, in that case, you're back to looking at other fields ...

What's the problem?

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Mon, 05 Apr 1999 07:39:58 +0200

Steve,

The problem is that the algorithm is actually:

IF BasicConstraints PRESENT {
       IF BasicConstraints.cA is TRUE
                THEN certificate-is-ca
                ELSE certificate-is-ee
}
ELSE {
    IF issuing CA is fully PKIX compliant
        THEN certificate-is-ee
        ELSE undefind
}

We cannot eliminate the undefined decision(*) but we can create certificates
that doesn't need that by encouraging CA to put a BasicConstraints that
contains BasicConstraints.cA=FALSE (It is encoded as NULL but this is just
encoding) rule).

Moshe

(*) We can complicate the algorithm so it will use keyUsage and reduce the
number of undefined answers but not eiliminate them.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 14:00:37 -0400

Moshe,

>contains BasicConstraints.cA=FALSE (It is encoded as NULL but this is just

The test I defined applies equally well for X.509 compliant CAs as well as
PKIX compliant CAs, as I stated.  Are you suggesting that we should change
PKIX to somewhow better accommodate CAs that don't comply with it?

We can look at this from two perspectives:

	- first, we're in chanrge of PKIX standards, so of course we're
most interested in the situation where the CA is PKIX compliant.  if you
assume otherwise, then there can be many ways in which processing will be
adversely affected.
	- second, since X.509 does not require the presence of this
extension, but merely recommends its use for EE certs, your modification of
my simple test also is deficient. why not include clauses for X.509
compliant CAs who do not elect to include the extension?

If one changed both PKIX and X.509 to mandate inclusion of this extension
for both EE and CA certs, AND if all CAs were compliant with either
standard, then life would, indeed, be easier.  But, if you use as an
example, the ambiguity that may arise from CAs that comply with neither
standard, why bother?

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Tue, 06 Apr 1999 10:21:54 +0300

Steve,

Stephen Kent wrote:

> PKIX compliant CAs, as I stated.

How? X.509 compliant CA can issue a certificate without basicConstraints to end
entity. In regards to this situation it says:

 If this extension is not present or is flagged non-critical and is not
recognized by a certificate-using system, then that system should use other means
to determine if the certified public key may be used to verify certificate
signatures.

Which is the "undefined" situation in my case.

> Are you suggesting that we should change

No. We should change PKIX such that PKIX CA will issue certificates that don't
require out of bound information to know if they are CA certificates or not.

> compliant CAs who do not elect to include the extension?

Why my test includes it. It says that it can't reach a decision for those CA's.

> example, the ambiguity that may arise from CAs that comply with neither

Totally removing the ambiguity is now almost impossible. But creating a
certificate that contains no ambiguity is very easy and should be encouraged
instead of discouraged.

Moshe