Subject: Basic constraints processing for SSL

From: Laurence Lundblade <[email-masked]>
Date: Mon, 12 Aug 2002 11:16:29 -0700

I'd like to check my understanding of basic constraints processing for SSL 
to be sure our implementation is right in light of the recent IE problems. 
This group seems the best one to me, but send me off somewhere else if you 
think there's a better place. I know there's no document or standard and 
2459 doesn't necessarily apply to SSL.

RFC 2459 4.2.1.10 says that CA's must set CA to TRUE and end entities 
should not have the extension present. That is the client software would 
give an error when any cert without BasicConstraints and CA=TRUE is used 
verify another cert.  That certainly will defend against the recently 
published IE attack.

However, if you examine the root / CA certs distributed with IE, a number 
of them do NOT have the BasicConstraints extension. I believe the yields 
section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change in 2459, 
just making the point that it doesn't seem to work for SSL).

I think there are two possible implementations that might work for SSL:

1) Require BasicConstraints and CA=TRUE for intermediate certs only, not 
roots. This will defend against the attack. The (admittedly few) 
intermediate certs I've seen to have BasicConstraints and CA=TRUE.

2) If a cert is being used to verify another and BasicConstraints is 
present, make sure it is false. This goes against 4.2.1.10 because it says 
that end entities should not include BasicConstraints, but for SSL the 
majority of the certs have it present and when present it it false.

Comments?

Further, I did an analysis of 50 or so random SSL server certs and found 
the following:
     15 VeriSign issued certs had BasicConstraints present, not critical, 
CA=FALSE
     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, not 
critical, CA=FALSE
     9 Thawte issued certs has BasicConstraints present, CRITICAL, CA=FALSE
     7 RSA SSCA (VeriSign) issued certs had no BasicConstraints present.
     2 others had no BasicConstraints present.

Clearly the majority have BasicConstraints present, CA=FALSE and I can 
understand why a CA would do that. It helps defend against this attack and 
has no down side. That it seems no SSL implementation would be so strict 
that it would error out if BasicConstraints is present on an end entity. I 
can also imagine that Thawte is trying to be extra cautious  by making it 
critical, but what is confusing is why some RSA SSCA certs have it present 
and some don't. Any ideas?

Also, I did an analysis of the root / CA certs bundled with IE and go the 
following:
    34 had BasicConstraints present and critical
    28 had BasicConstraints present and NOT critical
    40 do not have BasicConstraints present

The last number is the most troubling to me because it goes against RFC 
2459, and because I can't imagine why a CA would do it. It would seem 
either the CA operators aren't aware of this attack, or there's enough bad 
software out there that chokes BasicConstraints being present, or it 
doesn't matter because the check is never done on the root, just 
intermediates as I suggest above.  Some of the CA's with no 
BasicConstraints present are:
    VeriSign Class 1
    VeriSign Individual Software Publishers
    ... many other VeriSign roots
    C&W HKT SecureNet CA root
    Japan Certification Services
    RSA SSCA
    Microsoft

Thanks, LL

,

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 12 Aug 2002 16:58:48 -0400

Laurence:

Please take a look at RFC 3280.  I think it provides a more complete 
description.

A self-signed root certificate is a mechanism for distributing trust 
anchors.  As such, they need not contain any certificate extensions to 
provide the information necessary for the algorithm to function 
properly.  Intermediate CA certificates MUST contain the basic constraints 
extension with the cA bit set to conform to either RFC 2459 or RFC 3280.

Russ

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 12 Aug 2002 15:04:32 -0700

Oops, should have looked at 3280.

So now it's OK to have BasicConstraints in end entities. That helps a lot 
with SSL compatibility.

I understand that an intermediate cert MUST have BasicConstraints for RFC 
2459 / 3280 compliance, but is that a good thing for SSL? I assume that is 
what Netscape and Mozilla due to avoid the problem that IE has, but I 
haven't tested it yet. I also assume they only apply the requirement to 
intermediate certs and not roots due to the number of roots without the 
extension.

So now a few wording comments:

It makes sense to me that trusted anchor roots are implicitly used to 
verify other certs and thus don't need BasicConstraints, however the first 
sentence of the 4th paragraph of 4.2.1.10 says they must have the 
extension, doesn't it?

Seems like the first paragraph of 4.2.1.10 could be improved. It says "The 
basic constraints extension identifies whether the subject of the 
certificate is a CA....". Is what is meant that the subject *names* a CA? 
In that case we have a problem with intermediate certs which don't 
necessarily name a CA in the subject but include BasicConstraints. If what 
is meant is that the cert can be used to verify other certs, then that's 
different and it's not very clear.

In general I have trouble with the term "CA certificate" because I don't 
know if it means a trusted root certificate or a certificate used to verify 
other certificates. For example see 6.1.4 (k).

LL

At 04:58 PM 8/12/2002 -0400, Housley, Russ wrote:
>>I'd like to check my understanding of basic constraints processing for 
>>SSL to be sure our implementation is right in light of the recent IE 
>>problems. This group seems the best one to me, but send me off somewhere 
>>else if you think there's a better place. I know there's no document or 
>>standard and 2459 doesn't necessarily apply to SSL.
>>
>>
>>section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change in 
>>2459, just making the point that it doesn't seem to work for SSL).
>>
>>present, make sure it is false. This goes against 4.2.1.10 because it 
>>says that end entities should not include BasicConstraints, but for SSL 
>>the majority of the certs have it present and when present it it false.
>>
>>Comments?
>>
>>
>>     10 RSA SSCA (VeriSign) issued certs had BasicConstraints present, 
>> not critical, CA=FALSE
>>understand why a CA would do that. It helps defend against this attack 
>>and has no down side. That it seems no SSL implementation would be so 
>>strict that it would error out if BasicConstraints is present on an end 
>>entity. I can also imagine that Thawte is trying to be extra cautious  by 
>>making it critical, but what is confusing is why some RSA SSCA certs have 
>>it present and some don't. Any ideas?
>>
>>either the CA operators aren't aware of this attack, or there's enough 
>>bad software out there that chokes BasicConstraints being present, or it

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 13 Aug 2002 09:49:55 -0400

Laurence:

Self-signed root certificates are a mechanism for distributing information 
about trust anchors.  Note that they are not actually processed as CA 
certificates by the certification path validation algorithm.

Russ

At 03:04 PM 8/12/2002 -0700, Laurence Lundblade wrote:
>know if it means a trusted root certificate or a certificate used to 
>verify other certificates. For example see 6.1.4 (k).
>
>LL
>
>
>
>
>>properly.  Intermediate CA certificates MUST contain the basic 
>>constraints extension with the cA bit set to conform to either RFC 2459 
>>or RFC 3280.
>>
>>Russ
>>
>>
>>>However, if you examine the root / CA certs distributed with IE, a 
>>>number of them do NOT have the BasicConstraints extension. I believe the 
>>>yields section 4.2.1.10 unworkable for SSL. (I'm not suggesting a change 
>>>in 2459, just making the point that it doesn't seem to work for SSL).
>>>
>>>     15 VeriSign issued certs had BasicConstraints present, not 
>>> critical, CA=FALSE
>>>entity. I can also imagine that Thawte is trying to be extra 
>>>cautious  by making it critical, but what is confusing is why some RSA 
>>>SSCA certs have it present and some don't. Any ideas?
>>>
>>>Also, I did an analysis of the root / CA certs bundled with IE and go 
>>>the following:

---

From: Steve Hanna <[email-masked]>
Date: Tue, 13 Aug 2002 16:53:40 -0400

One more bit of clarification is in order. 

Laurence Lundblade wrote:
> I understand that an intermediate cert MUST have BasicConstraints
> for RFC 2459 / 3280 compliance, but is that a good thing for SSL?
> I assume that is what Netscape and Mozilla due to avoid the problem
> that IE has, but I haven't tested it yet. I also assume they only
> apply the requirement to intermediate certs and not roots due to
> the number of roots without the extension.

Extensions in trusted certificates are not processed during path
validation, according to RFC 3280. See section 6.1, which says
"When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path."

> It makes sense to me that trusted anchor roots are implicitly
> used to verify other certs and thus don't need BasicConstraints,
> however the first sentence of the 4th paragraph of 4.2.1.10 says
> they must have the extension, doesn't it?

No, since trusted certificates aren't processed during path
validation.

> Seems like the first paragraph of 4.2.1.10 could be improved.
> It says "The basic constraints extension identifies whether
> the subject of the certificate is a CA....". Is what is meant
> that the subject *names* a CA? In that case we have a problem
> with intermediate certs which don't necessarily name a CA in
> the subject but include BasicConstraints. If what is meant is
> that the cert can be used to verify other certs, then that's

That sentence simply means that the basic constraints extension
identifies whether the subject is a CA. As the next sentence
indicates, if the cA boolean is false it indicates that the
subject is not a CA.

> In general I have trouble with the term "CA certificate"
> because I don't know if it means a trusted root certificate
> or a certificate used to verify other certificates. For
> example see 6.1.4 (k).

Section 6.1.4 only applies to certificates in the path, so
it clearly doesn't apply to trust anchors.

Steve

---

From: Dean Povey <[email-masked]>
Date: Wed, 14 Aug 2002 09:17:59 +1000

>certificates by the certification path validation algorithm.

This is true for trust anchors, however a closer inspection of RFC3280 
shows that it is understandable why this error was made in IE/Konqueror.

The path validation algorithm from RFC3280 says:

    (k)  Verify that the certificate is a CA certificate (as specified
      in a basicConstraints extension or as verified out-of-band).

Which means that if basic constraints is not present the user should check.
Note that the text in RFC3280 is clear and unambiguous that basic
constraints MUST be included in certificates, but it is vague about what to
do when they are not.  It could be argued that the IE implementation is
conforming with RFC3280 (although from Sharon's comments, not with X.509
where the determination of isCA is much more explicit). I think you can
make the reasonable requirement, that in this case the implementation
should at least ask, but since the semantics of out-of-band checking are
never specified then this leaves too much wiggle room for the 
implementation.

So I think this is also a defect in the PKIX spec.  It also highlights the
problem with using BasicConstraints only for CAs.  I think that the
approach of putting a critical BasicConstraints extension with isCA=FALSE
in EE certs is more compatible with the path validation algorithm, and
gives a clear and unambiguous indication of what the application should do.

-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3864 1282   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures