Subject: RE: Problem with PKIX part 1 basicConstraints

From: Sharon Boeyen <[email-masked]>
Date: Tue, 17 Nov 1998 11:47:38 -0500

I believe the PKIX text is correct the way it is. It is consistent with
X.509 and takes it one step further. I don't think any change is
warranted here.

> ----------
> From: 	Tim Polk[SMTP:[email-masked]]
> Sent: 	November 17, 1998 9:49 AM
> To: 	[email-masked]; [email-masked]
> Subject: 	Re: Problem with PKIX part 1 basicConstraints
> 
> Peter,
> 
> Both MSIE and Netscape are relying on the user's judgement: the user
> *must*
> have out-of-band information that the subject is a trustworthy CA, or
> they
> wouldn't install it as a site certificate, would they??? (If I could
> remember how to make a smiley face, I'd insert it here!)
> 
> The basicConstraints extension does not fix this problem, though.  If
> NIST
> used that extension (and marked it critical) in end entity
> certificates,
> that prevents me from using my NIST certificate to claim CA status.  I
> don't really need that for the browser scenario.  If I can generate
> new
> certs, I can generate my own.  When I generate my self-signed
> certificate I
> might as well include the basicConstraints extension. If I could get
> folks
> to accept it without that extension, they'll certainly accept with
> that
> extension.
> 
> Clearly, the safest choice would be to select a single trusted CA (or
> a
> very small number) as the beginning (end?) of all valid paths and only
> accept a subject as a CA if the basicConstraints extension is present.
> (That is, never accept a subject as CA based on out-of-band
> information.)
> User selected trust points are always fraught with danger.  The
> solutions
> are to improve the client software and educate the users, in my
> opinion.
> 
> How?  Now that's a tough question!
> 
> Tim
> 
> 
> At 01:08 PM 11/17/98, Peter Gutmann wrote:
> >Tim Polk <[email-masked]> wrote:
> >
> >>If the basic constraints extension is not present, certificate
> processing
> >>is consistent with v1 or v2 certificates.  If out-of-band
> information
> >>specifies the subject is a CA, it's a CA.  If out of band
> information is
> >>not available, the user of the certificate assumes the subject is
> NOT a
> >>CA.
> >
> >Assertion: If basicConstraints is not present, current software
> typically
> >           assumes the subject is a CA.
> >Proof: Create a self-signed certificate without basicConstraints,
> load it
> >       into MSIE or Netscape, and see what happens.
> >
> >>3) If an end entity wishes to accept a certificate without a
> >>basicConstraints extension as a CA certificate, it must rely on
> >>out-of-band information.  In this case, the responsibility lies on
> the
> >>certificate user and the source of the out-of-band information, not
> on
> >>the certificate issuer.  The certificate issuer attests to the
> binding of
> >>subject and key, not the subject's status as a CA.
> >
> >Both MSIE and Netscape treat self-signed certs without
> basicConstraits as 
> >CA's by default (in fact I don't know of any way to get them to *not*
> 
> >treat the cert owners as CA's).
> >
> >MSIE: "You have been offered a new site certificate to place in your
> list
> >       of trusted issuers..."
> >Netscape: "You are about to go through the process of accepting a
> >           certificate authority..."
> >
> >Leaving out the basicConstraints makes the assumption that relying
> parties
> >are using PKIX-compliant software, and that the software will DTRT
> when it
> >finds one of these certs.  I think this is leaving what could be a
> critical
> >security issue more or less to chance - all I need to do is find some
> >software which happens to not follow PKIX's implied behaviour and I
> can go
> >ahead and issue my own certs and let the entire world in the door.
> >
> >Peter.
> >
> >
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Nov 1998 11:28:00 -0500

I believe the PKIX text is correct.  Many implementations need to make
modification to align with PKIX Part 1.

Russ

---

From: Andrew Probert <[email-masked]>
Date: Thu, 19 Nov 1998 09:37:36 +1100

As I recall, Verisign rolled out a new set of certs about 6 months ago
to superseed older certs from the IE3 era.

Rotek's TrustedNet Smart Card Enabled S/MIME Secure Email

WINS

"INTERACT 98  BEST INTERNET, INTRANET & EXTRANET SOLUTION"

See our Web Site for details

Rotek Consulting 
Melbourne, Australia 
+61-3-9690-8877 
+61-3-9690-8171 (Fax) 
www.rotek.com.au 

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
+61 3 9690 8877

> -----Original Message-----
> From:	Aram Perez [SMTP:[email-masked]]
> Sent:	Thursday, November 19, 1998 3:58 AM
> To:	Alex Deacon
> Cc:	Tim Polk; [email-masked]; [email-masked]
> Hi Alex,
> Thanks for the URL. I had previously found it, but like I said it was
> "very
> hard". My questions to Verisign are:
> 
> 1) Why isn't there a link to the URL on your home page?
> 2) There are only 4 certificates listed on the page but IE lists 8
> Verisign
> certificates and Navigotor lists 6 Verisign certificates. Where are
> the
> fingerprints for those "extra" certificates?
> 
> Regards,
> Aram
> 
> P.S. Please say hello to Hoa Ly (I believe she still works for
> Verisign).
> 
> 
> >> I also find it ironic that it is
> >> very hard to find out Verisign's fingerprints from their Web site. 
> >
> >See https://www.verisign.com/repository/root.html fingerprints of
> >VeriSign's root certificates.
> >
> >Alex

---

From: Brian LaMacchia <[email-masked]>
Date: Fri, 20 Nov 1998 14:44:10 -0800

Peter Gutmann wrote:
>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'm the author of the CryptoAPI-L message Peter's quoting here, so let me
give you my perspective on the basicConstraints question.  I agree with
Peter that the PKIX-1 position that BC SHOULD NOT be included in EE certs is
wrong.  If anything, I would expect PKIX to say BC SHOULD be included
(cA=FALSE, no pathLen of course) but not mandate it.  

For our products, the issue is primarily one of backward compatibility with
the universe of CA certificates in existence that do not contain a BC
extension (and there are plenty out there that do not.)  Since PKIX-1
mandates the presence of a critical BC extension in all CA certs, it's
certainly the case that in a world consisting of only PKIX-compliant CAs and
EEs I can distinguish between the two types of certs and not consider EE
certs during the path discovery process.  But that's not a reasonable
position for a product to take because there *are* certs in use that don't
meet this spec.  Lack of a BC extension in a cert cannot preclude that cert
from potentially being a CA cert.  It's the same situation as that we faced
with the introduction of extended key usage (EKU); lack of an EKU extension
implies "all" not "none".

My comment to the CryptoAPI list mixed together two specific instances when
determining whether a cert is an EE or a CA cert is important, which I
should explicitly separate.  First, of course, is path development and chain
validation policy, where I care about the universe of possible parent
certificates as I walk through the cert graph and overall pathLen
constraints in found paths.  Second, from a product perspective I may want
to be able to distinguish between EE and CA certs in the user interface when
presenting collections of certs to users.  Products may make distinctions in
how they store and present EE certs vs. CA certs.  Since I have to assume
that a cert w/o BC is a potential CA cert, I have to treat it that way in
the UI as well or I'll have inconsistent behavior.

I'm afraid I don't understand Tim's arguments (dealing with out-of-band
designation of an EE cert as acceptable as a cert issuer) as justification
for the current text.  Certainly any user can build his own trust policies
and designate any cert (self-signed root, intermediate CA or EE) as a
trusted root of cert paths.   But since that's a client-based policy
decision, I can do that anyway, even if the cert contains a basicConstraints
extension.  (I probably won't have any recourse against the issuer should
something go wrong, but that's my choice.)

As for our current/upcoming crop of products, we always include a BC
extension in certs we issue, EE or CA.  If a BC extension is present in a
cert we use and respect that information, whether or not it's marked
critical.  Lack of a BC extension implies the possibility that the cert
could be an old CA cert, and we therefore must consider that possibility.

Bottom line: we seem to be going out of our way here to break old CA certs.
That doesn't seem reasonable, especially when we jump through hoops in other
areas of the draft to explicitly grandfather old certs forward.

					--Brian LaMacchia
					  [email-masked]