RE: CA=True for an OCSP certficat

[Tom Gindin <tgindin@xxxxxxxxxx>]

        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@xxxxxxxxxxxx> 
04/06/2008 04:38 AM

To
Tom Gindin/Watson/IBM@IBMUS, "Peter Sylvester" 
<Peter.Sylvester@xxxxxxxxxx>
cc
"pkix" <ietf-pkix@xxxxxxx>, "Jean-Marc Desperrier" <jmdesp@xxxxxxx>
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@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 
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@xxxxxxxxxx> 
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
04/04/2008 07:04 AM

To
Jean-Marc Desperrier <jmdesp@xxxxxxx>
cc
pkix <ietf-pkix@xxxxxxx>
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.