Subject: Re: Basic constraints processing for SSL

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 Aug 2002 10:08:20 +1200 (NZST)

Laurence Lundblade <[email-masked]> writes:

>However, if you examine the root / CA certs distributed with IE, a number of
>them do NOT have the BasicConstraints extension.

Yup.  There are also a number of CAs which do this which aren't hardcoded into
IE.  What's scary about this is that nothing seems to notice this problem
(I've had at least two CAs claim that the practice is OK because no software
objects to it).

Peter.

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 13 Aug 2002 11:11:07 -0400

Just to add the X.509 voice to this discussion. With respect to the self
signed certificates, the statement made by Russ below was reinforced some
time ago through the processing of a defect report (DR) against the base
X.509 standard. As a result of that DR, the following sentence was added to
12.4.3 of X.509:

"Self-signed certificates, if encountered in the path, are ignored."

As for the intermediate CA certificates, X.509 is also very clear. Clause
8.4.2.1 Basic constraints extension states :

"If this extension is not present, or is flagged non-critical and is not
recognized by a certificate-using system, then the certificate is to be
considered an end-entity certificate and cannot be used to verify
certificate signatures."

and 
"If this extension is present and is flagged critical, or is flagged
non-critical but is recognized by the certificate-using system, then: 
 - if the value of cA is not set to true then the certifified public key
shall 
not be used to verify a certificate signature....."

as for EE certs, it also says:
"To constrain a certificate subject to being only an end entity, i.e. not a
CA, the issue can include this extension field containing only an empty
SEQUENCE value."

If you don't have a copy of X.509 and would like me to send you the complete
text for clause 8.4.2.1, let me know.

Sharon 

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 9:50 AM
To: Laurence Lundblade
Cc: [email-masked]
Subject: Re: Basic constraints processing for SSL

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:
>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:
>>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
>>
>>
>>At 11:16 AM 8/12/2002 -0700, Laurence Lundblade 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.
>>>
>>>
>>>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: "Tom Gindin" <[email-masked]>
Date: Tue, 13 Aug 2002 21:45:31 -0400

The descriptions of the problem I have seen don't mention KeyUsage at
all.  RFC 2459 (which was probably in force when this code was written)
insists that critical KeyUsage without KeyCertSign is invalid for CA
certificates, and RFC 3280 removes the dependence on criticality - any
KeyUsage without KeyCertSign is invalid for CA certificates.
      Are the IE/Konqueror implementations conforming to those requirements
as well?  They would seem to provide an extra level of protection above the
ones on basicConstraints.

            Tom Gindin

Dean Povey <[email-masked]>@mail.imc.org on 08/13/2002 07:17:59 PM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    Laurence Lundblade <[email-masked]>, [email-masked]
Subject:    Re: Basic constraints processing for SSL

>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

---

From: Peter Williams <[email-masked]>
Date: Wed, 14 Aug 2002 05:06:47 -0700

There are several areas of implementation
assumptions that will lead to many more debacles, 
in my view. I think we are in the situation
of the famous picture of the little Dutch
boy with his finger in the dyke.
 
a) PKIX compliance covers both v1 and v3 certs. When handling
a v1 CA cert in compliance with PKIX, obviously
one cannot use a basicConstraints control to enforce
the check of the subject as a CA.

b) I could poke several holes in several common S/MIME
implementations on v1 grounds, also - given how v1 certs are 
rarely "correctly handled" by UAs - usually  because of implementor 
assumptions about v3 controls. There are various "impropriety" 
holes in the commodity S/MIME emailers, when only one party is 
using the PEM 1422 cert management requirements for scanning the
local cache of certificate when handling a queried CRL,
(rather than path processing certs communicated within the 
message).

c) Its very unclear how many implementations handle the 3280
obligations to "parse" the unique identifier of v2/v3
certs, also, when CA communities override the recommendation
on their absence.

Peter.

-----Original Message-----
From: Tom Gindin
To: Dean Povey
Cc: Housley, Russ; Laurence Lundblade; [email-masked]
Sent: 8/13/02 6:45 PM
Subject: Re: Basic constraints processing for SSL

      The descriptions of the problem I have seen don't mention KeyUsage
at
all.  RFC 2459 (which was probably in force when this code was written)
insists that critical KeyUsage without KeyCertSign is invalid for CA
certificates, and RFC 3280 removes the dependence on criticality - any
KeyUsage without KeyCertSign is invalid for CA certificates.
      Are the IE/Konqueror implementations conforming to those
requirements
as well?  They would seem to provide an extra level of protection above
the
ones on basicConstraints.

            Tom Gindin

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.

---

From: Peter Williams <[email-masked]>
Date: Fri, 16 Aug 2002 07:22:42 -0700

Laurence:

The contents and handling of certificate paths are an 
application protocol (e.g. https, ftps, frontpage/s, pops, pptp/s) 
matter,  not an X.509/PKIX   matter. The only thing X.509 is 
saying is that during the std procedure called "path processing" the
contents are processed according to the rules. This doesnt
mean other rules dont use the contents of paths, in parallel.
We all know how https has extra rules, concerning wild-cards
in cn name-forms, for example, that link association establishment
to a purported network identifer. We know some apps
should properly override the path processing results, when 
appropriate. ("sorry, FBI agent, you cant decrypt the 
terror notification, cos the user cert's been revoked" says
a bad civilian UA!)
 
Path processing is only one of the things we all do to
establish a security service. Scanning a list
of certs to enforce https rules or ensure "no obscene names",
is an application issue, for a kid-safe PKI tool perhaps; those 
rules are not something X.509 or PKIX should get involved in. 

Similarly, enabling an application cert path to
send arbitary certs in a path to pre-float a recipients
cache is quite a normal practice, from PEM days. Distributing 
well-known trust anchors via self-signed certs, is a similar 
acceptable practice. https praxis is what it is, and 
its simple mechanism for trust-anchor discovery and distriubtion
is remarkably effective, world wide today (thx to Microsoft 
CTL controls, mainly)

About the only time I can think that one might aim to deviates from
these https/PEM path principles is when the signed object has been
objectively notarized ; in which case the particular cert path that
the notary relies upon is a part of the acknowlegment that 
the notary agent performs  - to form the complete record of 
authentication. Cert paths and signatures are part 
of the "transmission data" of a message, legally; part of its 
"form" merely. A notary need not maintain in the record such data as 
received, when issuing an acknowledgement of identity,
based on verying the digital signature. The notary 
need only retain the sig and cert path (and trust anchor, and CTL) 
that was actually relied upon, discarding any other
superfluous tranmission data.

-----Original Message-----
From: Laurence Lundblade
To: Sharon Boeyen; 'Housley, Russ'
Cc: [email-masked]
Sent: 8/15/02 4:54 PM
Subject: RE: Basic constraints processing for SSL

At 11:11 AM 8/13/2002 -0400, Sharon Boeyen wrote:

Just to add the X.509 voice to this discussion. With respect to the self
signed certificates, the statement made by Russ below was reinforced
some time ago through the processing of a defect report (DR) against the
base X.509 standard. As a result of that DR, the following sentence was
added to 12.4.3 of X.509:

So does this mean that the validity dates in trusted roots and/or
self-signed certs are to be ignored, or is this part of a distinct trust
anchor validation process? It seems like a bad thing to ignore the
validity dates in trust anchors.

Similarly, does that mean the pathLen part of BasicConstraints should be
ignored during path validation? The 3rd paragraph of section 6 in RFC
3280 sort of implies that trusted roots aren't entirely ignored when it
says "The algorithm requires the public key of the CA, the CA's name and
any **constraints upon the set of paths** which may be validated using
this key". 21 of the root certs in IE have pathLen. The value varies
from 1 to 10.

I'm still having trouble with the term "CA certificate". Sort of seems
like everyone knows what it is but me :-).  So if I pretend I have a "CA
certificate" in my pocket, what do I have?
a) A trust anchor (but not necessarily self-signed)
b) A self signed cert
c) A cert that's NOT an end entity
d) An intermediate/branch cert (which obviously can't be self signed)
e) One with the CA=TRUE in BasicConstraints (if so can a cert without
BasicConstraints ever be a "CA certificate") 
f) Some combination of the above

Dean made the comment that it doesn't say what to do when
BasicConstraints aren't present. This was generally (not just
BasicConstraings) the difficult part - when the certs you get diverge
from the standards and you know you have to process them. Adding that
sort of text to the document (or a BCP document) would certainly be
valuable. 

LL