Subject: Re: Problem with PKIX part 1 basicConstraints

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Nov 1998 14:54:11 (NZDT)

I've just been forwarded the following message from the MS CryptoAPI list, 
taken from the thread on NT SP4 fixes:
 
>Does your end-entity cert have a basicConstraints extension in it?  When we
>have to pick a default certificate store for a particular cert we first try
>to figure out whether we're looking at an EE or a CA cert.  If there's no
>basicConstraints extension present then the cert could be either and we
>default to treating the cert as a CA cert in this case.
 
I'll repeat again my assertion that omitting basicConstraints from a cert is a 
very dangerous practice because it leaves the interpretation of the certs CA 
status entirely to chance.  Users will use whatever the default for the 
software is, and the default for a lot of software is exactly the opposite of 
what is intended by PKIX.
 
[BTW the claim that leaving it out lets you use the cert as a CA cert if you 
 like is incorrect, since PKIX requires that CA certs have a critical 
 basicConstraints extension present if the cert is a CA cert, which should 
 exclude a cert without basicConstraints from acting as a CA if you follow the 
 PKIX interpretation.  I guess the user could always override this (meaning 
 that interpretation of the cert is at the whim of the user), and who knows 
 how the various pieces of software out there at the moment will handle it].
 
To comment on the claim that users must have out-of-band verification of CA's, 
a few months ago a group of people ran a test using an ISP's web pages to see 
how many people, when given an unknown CA cert, would accept it without 
question.  As far as they could tell, *everyone* accepted it (some may have 
accepted rejected it but connected to the following SSL'd page anyway despite 
the warning about a bad signature on the server cert).  This means that using 
the PKIX interpretation, any end entity can pass themselves off as a CA, and 
it'll work close to 100% of the time.
 
When it comes to cert fingerprints, there are German banks who have gone so 
far as to refuse to publish fingerprints because "it'll confuse the users" 
(which for about 99.99% of users is probably correct).  This upset some 
computer security types because it wouldn't allow out-of-band verification so 
they took it up with the banks, who after escalating it up several levels said 
they wouldn't publish the fingerprints, end of story.  Again, this doesn't 
bode well for PKIX's "take a guess at the CA status" interpretation.

I guess I've now said my bit on this topic... I still think doing this is a 
serious mistake, and reserve the right to dance around singing "I told you so" 
six months down the track :-).
 
Peter.

---

From: Brian Korver <[email-masked]>
Date: Wed, 18 Nov 1998 22:57:44 -0800

>it'll work close to 100% of the time.

Don't forget about the KeyUsage extention.  When this extention is present,
the BasicConstraints extension is redundant in EE certifications.

>six months down the track :-).

-brian
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Nov 1998 17:27:00 -0500

Peter:

You are being inconsistent.  You said: " ... PKIX requires that CA certs
have a critical  basicConstraints extension present if the cert is a CA
cert ...". I agree.  So, where is PKIX's "take a guess at the CA status"?
If there is not a basicConstraints extension with the cA bit set to TRUE,
then the certificate belongs to a CA, otherwise it belongs to an EE.  No
guessing.

Russ