[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-pkix
Subject:    RE: CA=True for an OCSP certficat
From:       Tom Gindin <tgindin () us ! ibm ! com>
Date:       2008-04-10 23:21:03
Message-ID: OF3B8EB2BA.B76D1714-ON85257427.0052BCCD-85257427.008045C2 () us ! ibm ! com
[Download RAW message or body]


        Santosh:

        I agree with your statement, of course.  I do NOT see anything in 
3280 or 3280-bis which requires it.  The fourth paragraph of 3280-bis 
4.2.1.9, which is unchanged from the corresponding paragraph in 3280 
4.2.1.10, does not require the presence of key usage for certificates 
"that contain key management public keys used with certificate enrollment 
protocols".  If there is still time in this cycle, I would insert a new 
sentence into the second paragraph, such as "If the cA boolean is 
asserted, the key usage extension MUST be present in the certificate."
        This is a fine point, of course.  The actual security risk this 
would block is limited to undetected compromises of those keys used with 
certificate enrollment protocols.  I still would like to know from our 
fellow members who work for CA vendors if anyone actually issues v3 
certificates with cA set but without key usage.

                Tom Gindin



"Santosh Chokhani" <SChokhani@cygnacom.com> 
04/10/2008 10:11 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"pkix" <ietf-pkix@imc.org>, "Jean-Marc Desperrier" <jmdesp@free.fr>, 
"Peter Sylvester" <Peter.Sylvester@edelweb.fr>
Subject
RE: CA=True for an OCSP certficat






When a CA is issued a certificate with basic constraints asserted to be 
true and if the key is to be used for limited purposes (e.g., only verify 
signatures on CRL or only use the key for signing and/or encrypting 
protocol data), key usage must be present with appropriate bits set. 

-----Original Message-----
From: Tom Gindin [mailto:tgindin@us.ibm.com] 
Sent: Monday, April 07, 2008 8:08 AM
To: Santosh Chokhani
Cc: pkix; Jean-Marc Desperrier; Peter Sylvester
Subject: RE: CA=True for an OCSP certficat

        What the RFC does not currently say is that for a CA issuing a 
certificate in which basicConstraints.CA is true, the keyUsage extension 
MUST (or at least SHOULD) also be present.  Such a statement should IMO be 

added to the existing second paragraph of RFC 3280 4.2.1.10.  The 
statement which currently occurs in the second paragraph of 4.2.1.3 does 
not cover certificates issued to CA's for reasons other than certificate 
and CRL signing.

                Tom Gindin

"Santosh Chokhani" <SChokhani@cygnacom.com> wrote on 04/06/2008 08:29:13 
PM:

> Tom,
> 
> The RFC already says that.  I do not quite see what needs to change.
> 
> -----Original Message-----
> From: Tom Gindin [mailto:tgindin@us.ibm.com] 
> Sent: Sunday, April 06, 2008 9:32 AM
> To: Santosh Chokhani
> Cc: pkix; Jean-Marc Desperrier; Peter Sylvester
> Subject: RE: CA=True for an OCSP certficat
> 
>         Santosh:
> 
>         The security benefit is to prevent compromised certificates 
which 
> CA's originally used for SSL or OCSP from being used to issue 
certificates 
> or CRL's.  Your point about backward compatibility is a reason not to 
> change 6.1.4(n) in the way suggested, but does not apply to requiring 
that 
> keyUsage be present in any certificate which contains a basicConstraints 


> extension with CA true.  It suggests that placing a requirement to 
include 
> keyUsage on CA's, rather than on RP's, is a better course.
> 
> Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <SChokhani@cygnacom.com> 
> 04/06/2008 04:38 AM
> 
> To
> Tom Gindin/Watson/IBM@IBMUS, "Peter Sylvester" 
> <Peter.Sylvester@edelweb.fr>
> cc
> "pkix" <ietf-pkix@imc.org>, "Jean-Marc Desperrier" <jmdesp@free.fr>
> Subject
> RE: CA=True for an OCSP certficat
> 
> 
> 
> 
> 
> 
> Tom,
> 
> The point is that for enhanced interoperability 3280 clients should be 
> able to consume certificates that are produced by CAs that do not comply 


> with 3280.
> 
> Thus, I do not favor a change to the RFC.
> 
> The change you suggest will make existing compliant clients 
non-compliant 
> with 3280.
> 
> Finally, I do not see a security benefit to this requirement.  The 
issuer 
> has already declared the subject to be a CA.  Does it have to shout at 
the 
> top of its lungs and put more extensions in to say the same thing over 
and 
> over.
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] 


> On Behalf Of Tom Gindin
> Sent: Sunday, April 06, 2008 3:26 AM
> To: Peter Sylvester
> Cc: pkix; Jean-Marc Desperrier
> Subject: Re: CA=True for an OCSP certficat
> 
> 
>         I don't think that your statement below that a v3 certificate 
with 
> 
> BC but no KeyUsage is an error is a correct reading.  However, I think 
> that it would be better than the current rule, which seems to be the 
first 
> 
> sentence of the second paragraph of 4.2.1.3, "This extension (referring 
to 
> 
> keyUsage) MUST appear in certificates that contain public keys that are 
> used to validate digital signatures on other public key certificates or 
> CRLs".  If I may summarize, in RFC 3280 a certificate with 
> BasicConstraints.CA set must contain keyUsage if keyCertSign or cRLSign 
> conditions actually apply, but need not do so if they don't.
>         I would favor either requiring that keyUsage be present in any 
> certificate which contains a basicConstraints extension with CA true, or 


> changing 6.1.4 (n) to suggest that verification reject any v3 
intermediate 
> 
> certificate without the keyCertSign bit set, rather than allowing v3 
> intermediate certificates without keyUsage present.
>         Can anyone think of any legitimate reason why a CA should issue 
a 
> certificate with CA true but no keyUsage extension present?  Does any 
> existing CA software issue v3 intermediate certificates without a 
keyUsage 
> 
> extension?
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> Peter Sylvester <Peter.Sylvester@edelweb.fr> 
> Sent by: owner-ietf-pkix@mail.imc.org
> 04/04/2008 07:04 AM
> 
> To
> Jean-Marc Desperrier <jmdesp@free.fr>
> cc
> pkix <ietf-pkix@imc.org>
> Subject
> Re: CA=True for an OCSP certficat
> 
> 
> 
> 
> 
> 
> Jean-Marc Desperrier wrote:
> > Santosh Chokhani wrote:
> >> RFC 3280 is pretty clear on what determines a CA.  It is based on 
basic 
> 
> constraints for version 3 certificates and out of band means for version 

1 
> 
> and 2.  See section 4.2.1.10 (Basic Constraints) and step k in Section 
> 6.1.4.
> >> 
> > Now we're getting to something interesting.
> >
> > So for retro-compatibility reasons, a proper implementation of RFC3280 


> should accept a certification path where one of the CA certificate has 
> Basic Contraint CA=True but has no Key Usage extension.
> >
> > I don't feel really at ease with that. 
> > 
> Indeed.  But we are hear in a different case as I initially described. 
> Since RFC 3280 makes restrictions,
> and the tool in question is determining whether the CA creates good 
> certficats, a V3 cert with BC
> and no Keyusage is an error.
> 
> I agree with Santosh that  if one allows such a cert to participate in 
> the path validation game
> (i.e. one with CA=true and no keyusage) it would be accepted as signing 
> certficat. The question
> is whether it should be allowed to play. That's a different problem.
> 
> At least one can appreciate that the path validation algorithm is a 
> concrete thing. This
> would be different for example if  two rules would be replaced by
>     'If the certficat can sign certificats ...'
> 
> > I'd be really wary when encoutering such a case and I'm not sure it 
> corresponds to a very useful need.
> > 
> It is non conformant, but at least we know what the path validation 
> algorithm is doing.
> > But so be it, and does give weight to Peter's argument that any cert 
> with BC including CA=True should be handled as a CA cert in all cases.
> > 
> In fact I said the contrary, Santosh and Steve did say that. I don't 
care
> as long as the definition can be understood by a tester and as long as
> the tool does not reject valid certificats and puts them into an 
> understandable
> category.
> 
> I have no idea what a user expects "Can this cert be used to sign other 
> certs"
> or "Does this cert belong to some (certification) authority"? Of what 
type
> is a cert of a  TSAuthority? Assume CA=true or CA=false?
> 
> > 
> >> RFC 3280 is also clear that CA certificate need not contain key usage 


> extension, let alone have key cert Sign bit.   See step n in Section 
> 6.1.4.
> >> 
> > It would be extremely dangerous to allow a certificate to act as a 
> > certificate issuer if it has a key usage extension without the key 
> > cert Sign bit set and fortunately step n does not do that, it only 
> > allows through certificates with a *missing* key usage extension. 
> Yes,
> Wasn't there a famous bug several years ago in some widely deployed 
> software
> that allowed an end-entity to become CA? :-)
> 
> -- 
> To verify the signature, see http://edelpki.edelweb.fr/ 
> Cela vous permet de charger le certificat de l'autorité; 
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 
> 
> 
> 
> 
> 
> 




[prev in list] [next in list] [prev in thread] [next in thread]