Subject: [pkix] Integrated OCSP Responders / Key Usage bits

From: Rob Stradling <[email-masked]>
Date: Fri, 25 May 2012 10:04:55 +0100

Which Key Usage bits (if any) are required to be present in a CA 
Certificate that directly signs OCSP Responses?

RFC2560 and the expired 2560bis-04 don't mention the Key Usage extension 
at all.

RFC5280 says...
"   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
    -- Signing OCSP responses
    -- Key usage bits that may be consistent: digitalSignature
    -- and/or nonRepudiation"
...but id-kp-OCSPSigning is only applicable to Designated Responders.

The (relatively recently published) CABForum Baseline Requirements 
document says:
"Bit positions for keyCertSign and cRLSign MUST be set.  If the 
Root/Subordinate CA Private Key is used for signing OCSP responses, then 
the digitalSignature bit MUST be set."

Is this "digitalSignature bit MUST be set" requirement sensible?  Or 
unnecessary?  Or problematic?
Does any other standard explicitly state the same requirement?

IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not 
the CA Certificate can directly sign OCSP Responses, but sadly I can 
find no text to support this idea.

RFC5280 says...
"The digitalSignature bit is asserted when the subject public key
       is used for verifying digital signatures, other than signatures on
       certificates (bit 5) and CRLs (bit 6), such as those used in an
       entity authentication service, a data origin authentication
       service, and/or an integrity service."

Spot the "such as".

X.509 (2008/05) says...
"digitalSignature: for verifying digital signatures that are used with 
an entity authentication service, a data origin authentication service 
and/or an integrity service;"

Spot the absence of "such as".

Is OCSP an "entity authentication service, a data origin authentication 
service and/or an integrity service"?  If not, then surely it'd be wrong 
(according to the X.509 text) for digitalSignature to govern whether or 
not the CA Certificate can directly sign OCSP Responses?

We (Comodo) directly sign OCSP Responses using CA Certificates that do 
not have the digitalSignature bit set.  We've not encountered any 
interop problems so far.  My concern is that future relying party 
software might choose to enforce the "digitalSignature bit MUST be set" 
requirement from the Baseline Requirements and therefore reject our OCSP 
Responses.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 May 2012 11:50:41 -0400

Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 25 May 2012 12:08:47 -0400

Russ,

RFC 2560 is clear that the id-kp-OCSPSigning OID is only required if the 
certificate issuer does not sign the OCSP responses itself.

In addition, RFC 5280 says:

    If the [extended key usage] extension is present, then the 
certificate MUST
    only be used for one of the purposes indicated.

    If a certificate contains both a key usage extension and an extended
    key usage extension, then both extensions MUST be processed
    independently and the certificate MUST only be used for a purpose
    consistent with both extensions.  If there is no purpose consistent
    with both extensions, then the certificate MUST NOT be used for any
    purpose.

So, including an extended key usage extension in a CA certificate would 
be problematic, since the IETF does not specify any key purpose OIDs 
that indicate a usage of certificate or CRL signing.  One could get 
around this by including the anyExtendedKeyUsage OID, but it is better 
to simply not include an extended key usage extension in a CA certificate.

Dave

---

From: [email-masked]
Date: Fri, 25 May 2012 18:31:34 +0200

Russ,

I raised the question in my presentation on OCSP during the last PKIX 
session in Paris, 
since there is currently no answer in the PKIX documents.

I don't believe that your response is correct.

The id-kp-OCSPSigning object identifier is only for a designated OCSP 
responder. 
This is not the case we are considering in this discussion.

RFC 2560 states: "OCSP signing delegation SHALL be designated by the 
inclusion of id-kp-OCSPSigning 
in an extendedKeyUsage certificate extension included in the OCSP response 
signer's certificate".

Ideally, we should have added an OCSP signing bit in the key usage bits, 
but unfortunately 
nobody raised the point when we built RFC 2560.

Rob mentioned the (relatively recently published) CABForum Baseline 
Requirements 
document which says: "Bit positions for keyCertSign and cRLSign MUST be 
set. 
If the Root/Subordinate CA Private Key is used for signing OCSP responses, 
then 
the digitalSignature bit MUST be set."

I don't believe that this response is correct either, since in the general 
case an upper CA 
does not sign OCSP responses for a lower CA. 

Let me propose a strawman:

The keyCertSign bit and the digitalSignature bit MUST be set.
The cRLSign bit MAY be set.

A few explanations are needed. 
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set. 
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST 
be set, 
otherwise it MUST NOT be set.

Let us now suppose that a CA starts to issue CRLs and that, later on, the 
CA wants to issue OCSP responses. 
With this strawman proposal, the CA must obtain a new certificate from its 
upper CA. This makes sense since 
the Certification Policy has changed and the upper CA has the right to 
verify the practices of its child CA.

Note: Any proposal will break some eggs and make an omelet, since, without 
guidance, implementers did "something".
        What is strange is that OCSP currently works ! 
        I would guess most implementations only test the keyCertSign bit. 

Denis

De :    Russ Housley <[email-masked]>
A :     Rob Stradling <[email-masked]>
Cc :    [email-masked]
Date :  25/05/2012 17:50
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :    [email-masked]

Do you mean that the same private key is used by the CA to sign 
certificates, CRLs, and OCSP Responses?  If so, I would expect the CA 
certificate that contains the corresponding public key to include the key 
usage and the extended key usage extensions.  The key usage extension 
should have at least the keyCertSign and the cRLSign bits set.  The 
extended key usage extension should include at least the id-kp-OCSPSigning 
object identifier.

Russ

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Ryan Hurst" <[email-masked]>
Date: Fri, 25 May 2012 09:34:10 -0700

I have always assumed the logic Denis mentions, I have no clue what clients
expect though :/

Ryan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, May 25, 2012 9:32 AM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits

Russ, 

Ideally, we should have added an OCSP signing bit in the key usage bits, but
unfortunately 
nobody raised the point when we built RFC 2560. 

Rob mentioned the (relatively recently published) CABForum Baseline
Requirements 
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.

If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be
set, 

Let us now suppose that a CA starts to issue CRLs and that, later on, the CA
wants to issue OCSP responses. 
With this strawman proposal, the CA must obtain a new certificate from its
upper CA. This makes sense since 
the Certification Policy has changed and the upper CA has the right to
verify the practices of its child CA. 

Denis 

  _____  

Do you mean that the same private key is used by the CA to sign
certificates, CRLs, and OCSP Responses?  If so, I would expect the CA
certificate that contains the corresponding public key to include the key
usage and the extended key usage extensions.  The key usage extension should
have at least the keyCertSign and the cRLSign bits set.  The extended key
usage extension should include at least the id-kp-OCSPSigning object
identifier.

Russ

_______________________________________________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 May 2012 12:46:35 -0400

David:

Thanks for pointing out my mistake.

I agree that RFC 2560 does not require the id-kp-OCSPSigning OID if the CA certificate will be used to validate the OCSP response; however, RFC 2560 does not say that the CA certificate cannot also make use of the id-kp-OCSPSigning OID.

For the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses, the digitalSignature bit would also need to be set to ensure consistence between the extend key usage and the extended key usage extensions.

I do not think that the use of the anyExtendedKeyUsage OID in a CA certificate is desirable.

Russ

On May 25, 2012, at 12:08 PM, David A. Cooper wrote:

> Russ,
> 
> RFC 2560 is clear that the id-kp-OCSPSigning OID is only required if the certificate issuer does not sign the OCSP responses itself.
> 
>   If the [extended key usage] extension is present, then the certificate MUST
> So, including an extended key usage extension in a CA certificate would be problematic, since the IETF does not specify any key purpose OIDs that indicate a usage of certificate or CRL signing.  One could get around this by including the anyExtendedKeyUsage OID, but it is better to simply not include an extended key usage extension in a CA certificate.
> 
> Dave
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 May 2012 12:54:24 -0400

Denis:

I think my reply to David is consistent with your analysis.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set. 
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be present. 

I think including the id-kp-OCSOSigning OID is desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ

On May 25, 2012, at 12:31 PM, [email-masked] wrote:

> Russ, 
> 
> I raised the question in my presentation on OCSP during the last PKIX session in Paris, 
> The id-kp-OCSPSigning object identifier is only for a designated OCSP responder. 
> RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning 
> in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate". 
> 
> Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately 
> Rob mentioned the (relatively recently published) CABForum Baseline Requirements 
> If the Root/Subordinate CA Private Key is used for signing OCSP responses, then 
> I don't believe that this response is correct either, since in the general case an upper CA 
> If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set, 
> Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses. 
> With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since 
> the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA. 
> 
> Note: Any proposal will break some eggs and make an omelet, since, without guidance, implementers did "something".

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 25 May 2012 13:11:02 -0400

Russ,

You seem to providing contradictory suggestions.  If you include an 
extended key usage extension in a CA certificate that asserts 
id-kp-OCSPSigning, but not anyExtendedKeyUsage, then the subject public 
key cannot be used to verify signatures on certificates or CRLs, even if 
the keyCertSign and cRLSign bits are set in key usage.  In theory, you 
could get around this by defining a key purpose OID (or OIDs) consistent 
with certificate and CRL signing, but why bother.

Dave

On 05/25/2012 12:54 PM, Russ Housley wrote:
> Denis:
>
> I think my reply to David is consistent with your analysis.  My first 
> reply was incorrect; the digitalSignature key usage bit needs to be set.
>
> My summary:
> I think including the id-kp-OCSOSigning OID is desirable.  It 
> indicates the intention to sign OCSP responses even though it is not 
> require by RFC 2560.
>
> Russ
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 25 May 2012 19:50:07 +0200 (MEST)

Ryan Hurst wrote:
> 
> I have always assumed the logic Denis mentions,
> I have no clue what clients expect though :/

+1

Denis Pinkas wrote:
> set, otherwise it MUST NOT be set. 

This sounds right to me (about KeyUsage).

> I would guess most implementations only test the keyCertSign bit. 

I believe that implementation MUST check for digitalSignature when
verifying the signature on the OCSP response with a cert that contains
a KeyUsage extension.

The situation with the presence of an ExtendedKeyUsage in a CA cert is
less clear than desirable.

  http://tools.ietf.org/html/rfc5280#section-4.2.1.12

   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.  In general, this
   extension will appear only in end entity certificates.  This
   extension is defined as follows:

  [...]

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated. 

The unclear "in addition to or in place of" could result in RPs rejecting
CA certs with ExtendedKeyUsage in them, by being _very_ strict about
the MUST above.  The spec should have clarified, to which KeyUsage types
the "in addition to" applies, and to which "in place of" applies.

Currently, much of the installed base might be entirely ignoring
ExtendedKeyUsage except for very specific usage scenarios that
explicitly call for it (so that the check is implemented entirely
at the "application caller" level, and that ExtendedKeyUsage is
entirely ignored during certificate path validation.

-Martin

---

From: [email-masked]
Date: Fri, 25 May 2012 20:41:00 +0200

Russ,

We only agree on two points:

 - Since the CA issues certificates, the keyCertSign bit MUST be set. 
 - Since the CA signs OCSP responses, the digitalSignature bit MUST be set

However, when the CA does not issue CRLs, the cRLSign bit MUST NOT be set.

Changing the content of RFC 2560 about the meaning of id-kp-OCSPSigning 
OID is impossible. 
As you know, id-kp-OCSPSigning is defined through an OID which has a 
precise meaning. 
If you change the meaning, then you need to define a new OID.

So your proposal to include the id-kp-OCSPSigning OID in the extended key 
usage extension 
cannot be accepted.

It is also unnecessary, even with a new OID.

Denis

De :    Russ Housley <[email-masked]>
A :     [email-masked]
Cc :    IETF PKIX <[email-masked]>, Rob Stradling 
<[email-masked]>
Date :  25/05/2012 19:18
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits

Denis:

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set. 
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, 
and
    the id-kp-OCSOSigning OID MAY be present. 

I think including the id-kp-OCSOSigning OID is desirable.  It indicates 
the intention to sign OCSP responses even though it is not require by RFC 
2560.

Russ

Russ, 

Denis 

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 May 2012 15:29:06 -0400

Denis and David:

In my original message, I said: "Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?"  My response was in that context.

RFC 2560 certainly requires the id-kp-Sigining OID in certificates that are directly subordinate to the CA certificate that will be used to validate OCSP responses.  Re-reading it just now, I still do not see anything that says the id-kp-Sigining OID cannot be in the CA certificate. 

The point that David Cooper raises needs further discussion.  I'm uncomfortable with his conclusion, but there is nothing in RFC 5280 that I can point to as justification.  However, the most recent version of X.509 does offer some support.  It says: "This field indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension field."

Russ

On May 25, 2012, at 2:41 PM, [email-masked] wrote:

> Changing the content of RFC 2560 about the meaning of id-kp-OCSPSigning OID is impossible. 
> As you know, id-kp-OCSPSigning is defined through an OID which has a precise meaning. 
> So your proposal to include the id-kp-OCSPSigning OID in the extended key usage extension 
> cannot be accepted. 
> 
> Cc :        IETF PKIX <[email-masked]>, Rob Stradling <[email-masked]> 
> Date :        25/05/2012 19:18

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 25 May 2012 17:09:37 -0400

Russ,

The most recent version of X.509 that I have (11/2008) also says:

If a certificate contains both a critical key usage
field and a critical extended key usage field, then both fields
shall be processed independently and the certificate shall only be
used for a purpose consistent with both fields. If there is no
purpose consistent with both fields, then the certificate shall
not be used for any purpose.

I don't know why it says "critical" since the text says that even it
the extension is non-critical applications that can process the
extension shall only use the certificate for the purposes indicated
in the extension.

Dave

On 05/25/2012 03:29 PM, Russ Housley wrote:

Denis and David:

In my original message, I said: "Do you mean that the same
private key is used by the CA to sign certificates, CRLs, and
OCSP Responses?"  My response was in that context.

RFC 2560 certainly requires the id-kp-Sigining OID in
certificates that are directly subordinate to the CA
certificate that will be used to validate OCSP responses.
Re-reading it just now, I still do not see anything that says
the id-kp-Sigining OID cannot be in the CA certificate.

The point that David Cooper raises needs further
discussion.  I'm uncomfortable with his conclusion, but there
is nothing in RFC 5280 that I can point to as justification.
However, the most recent version of X.509 does offer some
support.  It says: "This field indicates one or more purposes
for which the certified public key may be used, in addition to
or in place of the basic purposes indicated in the key usage
extension field."

Russ

On May 25, 2012, at 2:41 PM, [email-masked]
wrote:

Russ,

- Since the CA issues
certificates,
the keyCertSign bit MUST be set.

- Since the CA signs OCSP
responses,
the digitalSignature bit MUST be set

However, when the CA does not
issue CRLs,
the cRLSign bit MUST NOT be set.

Changing the content of RFC
2560 about the
meaning of id-kp-OCSPSigning OID is impossible.

As you know, id-kp-OCSPSigning is defined through an OID
which has a precise
meaning.

If you change the meaning, then you need to define a new
OID.

So your proposal to include
the id-kp-OCSPSigning
OID in the extended key usage extension

cannot be accepted.

It is also unnecessary, even
with a new OID.

Denis

De :

Russ Housley
<[email-masked]>

A :
[email-masked]

Cc :
IETF PKIX
<[email-masked]>,
Rob Stradling <[email-masked]>

Date :

25/05/2012
19:18

Objet :

Re: [pkix]
Integrated
OCSP Responders / Key Usage bits

Denis:

I think my reply to David is consistent
with your analysis.
My first reply was incorrect; the digitalSignature key
usage bit
needs to be set.

My summary:

Since the CA issues certificates, the
keyCertSign bit
MUST be set.

Since the CA issues CRLs, the cRLSign bit
MUST be set.

Since the CA signs OCSP responses, the
digitalSignature
bit MUST be set, and

the id-kp-OCSOSigning OID MAY be
present.

I think including the id-kp-OCSOSigning OID
is desirable.
It indicates the intention to sign OCSP responses even
though it
is not require by RFC 2560.

Russ

On May 25, 2012, at 12:31 PM, [email-masked]
wrote:

Russ,

I raised the question in my presentation on OCSP during
the last PKIX session
in Paris,

since there is currently no answer in the PKIX
documents.

The id-kp-OCSPSigning object identifier is only for a
designated OCSP responder.

This is not the case we are considering in this
discussion.

RFC 2560 states: "OCSP signing delegation SHALL be
designated by the
inclusion of id-kp-OCSPSigning

in an extendedKeyUsage certificate extension included in
the OCSP response
signer's certificate".

Ideally, we should have added an OCSP signing bit in the
key usage bits,
but unfortunately

Rob mentioned the (relatively recently published)
CABForum Baseline Requirements

document which says: "Bit positions for keyCertSign and
cRLSign MUST
be set.

If the Root/Subordinate CA Private Key is used for
signing OCSP responses,
then

I don't believe that this response is correct either,
since in the general
case an upper CA

The keyCertSign bit and the digitalSignature bit MUST be
set.

Since the CA issues certificates, the keyCertSign bit
MUST be set.

Since the CA signs OCSP responses, the digitalSignature
bit MUST be set.

If the CA issues both CRLs and OCSP Responses, then the
cRLSign bit MUST
be set,

Let us now suppose that a CA starts to issue CRLs and
that, later on, the
CA wants to issue OCSP responses.

With this strawman proposal, the CA must obtain a new
certificate from
its upper CA. This makes sense since

the Certification Policy has changed and the upper CA
has the right to
verify the practices of its child CA.

Note: Any proposal will break some eggs and make an
omelet, since, without
guidance, implementers did "something".

What is strange is that OCSP currently works
!

I would guess most implementations only test
the keyCertSign bit.

Denis

De :        Russ
Housley <[email-masked]>

A :        Rob
Stradling <[email-masked]>

Cc :        [email-masked]

Date :        25/05/2012
17:50

Objet :        Re:
[pkix]
Integrated OCSP Responders / Key Usage bits

Rob:

> Which Key Usage bits (if any) are required to be
present in a CA Certificate
that directly signs OCSP Responses?

Do you mean that the same private key is used by the
CA to sign certificates,
CRLs, and OCSP Responses?  If so, I would expect the
CA certificate
that contains the corresponding public key to include
the key usage and
the extended key usage extensions.  The key usage
extension should
have at least the keyCertSign and the cRLSign bits
set.  The extended
key usage extension should include at least the
id-kp-OCSPSigning object
identifier.

Russ

pkix mailing list

[email-masked]

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 26 May 2012 09:51:44 +0200

Hi Denis,

As X.509 is the master specification the keyUsage extension, any addition to
that extension should be done in X.509. Others could then copy it.

Erik

Fra: [email-masked] [mailto:[email-masked]] På vegne af
[email-masked]
Sendt: 25. maj 2012 18:32
Til: Russ Housley
Cc: [email-masked]; [email-masked]
Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits

Russ, 

Denis 

  _____  

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 26 May 2012 09:59:22 -0400

Erik:

I think Denis meant that we should have asked for such a bit back in 1998 and 1999 when OCSP was first being defined.

Russ

On May 26, 2012, at 3:51 AM, Erik Andersen wrote:

> Hi Denis,
>  
> As X.509 is the master specification the keyUsage extension, any addition to that extension should be done in X.509. Others could then copy it.
>  
> Erik
>  
> Fra: [email-masked] [mailto:[email-masked]] På vegne af [email-masked]

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 May 2012 11:20:37 +0100

The follow-ups in this thread so far all seem to say that the 
digitalSignature bit should be set in a CA certificate whose private key 
will sign OCSP Responses directly.

The last question in my original post asked if this was actually 
consistent with X.509.  Would anyone care to comment on this question? 
Here it is again...

X.509 (2008/05) says...

Is OCSP...
1. "an entity authentication service"?
2. "a data origin authentication service"?
3. "an integrity service"?
4. More than 1 of the above?
5. None of the above?

If "None of the above", then surely it'd be wrong for digitalSignature 
to govern whether or not the CA Certificate's private key can directly 
sign OCSP Responses?

Thanks.

On 26/05/12 14:59, Russ Housley wrote:
> Erik:
>
> I think Denis meant that we should have asked for such a bit back in
> 1998 and 1999 when OCSP was first being defined.
>
> Russ
>
>
>> As X.509 is the master specification the keyUsage extension, any
>> addition to that extension should be done in X.509. Others could then
>> copy it.
>> Erik
>> *Fra:[email-masked]
>> <mailto:[email-masked]>[mailto:[email-masked]]*På vegne
>> [email-masked] <mailto:[email-masked]>
>> *Sendt:*25. maj 2012 18:32
>> *Til:*Russ Housley
>> *Cc:[email-masked] <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]>
>> *Emne:*Re: [pkix] Integrated OCSP Responders / Key Usage bits
>> Russ,
>>
>> Note: Any proposal will break some eggs and make an omelet, since,
>> without guidance, implementers did "something".
>> De : Russ Housley <[email-masked] <mailto:[email-masked]>>
>> A : Rob Stradling <[email-masked]
>> <mailto:[email-masked]>>
>> Cc : [email-masked] <mailto:[email-masked]>
>> Date : 25/05/2012 17:50
>> Envoyé par : [email-masked] <mailto:[email-masked]>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> Rob:
>>
>> certificate that contains the corresponding public key to include the
>> key usage and the extended key usage extensions. The key usage
>> extension should have at least the keyCertSign and the cRLSign bits
>> set. The extended key usage extension should include at least the
>> id-kp-OCSPSigning object identifier.
>>
>> Russ
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 May 2012 11:21:22 +0100

On 25/05/12 16:50, Russ Housley wrote:
> Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?

Yes.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 May 2012 09:25:58 +1000

> 4. More than 1 of the above?

#2. OCSP is a data origin authentication service.
The signature on an OCSP response authenticates the origin of the status data.

--
James Manger

---

From: Rob Stradling <[email-masked]>
Date: Tue, 29 May 2012 09:24:11 +0100

> Certificate that directly signs OCSP Responses?
<snip>
> find no text to support this idea.

I've unearthed some text to support this idea, so at least I'm now sure 
I didn't completely make it up myself!

RFC2459 said...
"The cRLSign bit is asserted when the subject public key is used for 
verifying a signature on revocation information (e.g., a CRL)."
"The digitalSignature bit is asserted when the subject public key is 
used with a digital signature mechanism to support security services 
other than...revocation information signing (bit 6)."

Obviously an OCSP Response's signature is "a signature on revocation 
information".

Why did RFC3280 change the required bit for signing non-CRL revocation 
information from "cRLSign" to "digitalSignature"?

Could we change it back, or at least allow either "cRLSign" or 
"digitalSignature" to be deemed acceptable for signing non-CRL 
revocation information?

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 29 May 2012 11:14:57 -0400

Russ,

I occurred to me over the weekend that there is another reason not
to include an extended key usage extension in the certificate in the
case of an integrated OCSP responder.  Consider the following
scenario of a subordinate CA that acts an an integrated OCSP
responder with the certificate issued by the root CA to the
subordinate CA containing keyUsage and extended key usage extensions
as you suggest:

+----------------+

|    Root CA     |

+----------------+

|

|  keyUsage: keyCertSign, cRLSign, digitalSignature

|  extKeyUsage: id-kp-OCSPSigning, ...

|

\/

+----------------+

| subordinate CA |

+----------------+

As you noted, RFC 2560 does not require the extended key usage
extension to be present in order for the subordinate CA to sign OCSP
responses for its own certificates.  However, according to RFC 2560,
by including the extended key usage extension with
id-kp-OCSPSigning, the root CA is indicating to relying parties that
the subordinate CA is authorized to act as a designated OCSP
responder for the root CA.  So, this would make the subordinate CA
authorized to provide status information for certificates issued by
the root CA, even though the intention was only to indicate that it
was authorized to provide status information for its own
certificates.

Dave

Denis:

I think my reply to David is consistent with your analysis.
My first reply was incorrect; the digitalSignature key usage
bit needs to be set.

My summary:

Since the CA issues certificates, the keyCertSign bit MUST
be set.

Since the CA signs OCSP responses, the
digitalSignature bit MUST be set, and

I think including the id-kp-OCSOSigning OID is desirable.  It
indicates the intention to sign OCSP responses even though it is
not require by RFC 2560.

Russ

Russ,

I raised the question in my
presentation
on OCSP during the last PKIX session in Paris,

I don't believe that your
response is correct.

The id-kp-OCSPSigning object
identifier is
only for a designated OCSP responder.

RFC 2560 states: "OCSP signing
delegation
SHALL be designated by the inclusion of id-kp-OCSPSigning

Ideally, we should have added an
OCSP signing
bit in the key usage bits, but unfortunately

Rob mentioned the (relatively
recently published)
CABForum Baseline Requirements

If the Root/Subordinate CA Private Key is used for signing
OCSP responses,
then

I don't believe that this
response is correct
either, since in the general case an upper CA

The keyCertSign bit and the
digitalSignature
bit MUST be set.

Since the CA issues
certificates, the keyCertSign
bit MUST be set.

Since the CA signs OCSP
responses, the digitalSignature
bit MUST be set.

If the CA issues both CRLs and
OCSP Responses,
then the cRLSign bit MUST be set,

Let us now suppose that a CA
starts to issue
CRLs and that, later on, the CA wants to issue OCSP
responses.

the Certification Policy has changed and the upper CA has
the right to
verify the practices of its child CA.

Note: Any proposal will break
some eggs and
make an omelet, since, without guidance, implementers did
"something".

What is strange
is that OCSP currently works !

I would guess
most implementations only test the keyCertSign bit.

Denis

De :
Russ Housley <[email-masked]>

A :
Rob Stradling

Cc :
[email-masked]

Date :

25/05/2012 17:50

Objet :
Re: [pkix]
Integrated

Envoyé par
:
[email-masked]

Do you mean that the same private key is used by the CA
to sign certificates,
CRLs, and OCSP Responses?  If so, I would expect the CA
certificate
that contains the corresponding public key to include
the key usage and
the extended key usage extensions.  The key usage
extension should
have at least the keyCertSign and the cRLSign bits set.
The extended
key usage extension should include at least the
id-kp-OCSPSigning object
identifier.

Russ

pkix mailing list

[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 May 2012 12:25:19 -0400

David:

This is a very good point.  This would authorize every subordinate CA to sign OCSP responses on behalf of the Root CA.  This indeed a serious side effect.  Thanks for sharing.

My revised summary:

Russ

On May 29, 2012, at 11:14 AM, David A. Cooper wrote:

> Russ,
> 
> I occurred to me over the weekend that there is another reason not to include an extended key usage extension in the certificate in the case of an integrated OCSP responder.  Consider the following scenario of a subordinate CA that acts an an integrated OCSP responder with the certificate issued by the root CA to the subordinate CA containing keyUsage and extended key usage extensions as you suggest:
> 
> +----------------+
> |    Root CA     |
> +----------------+
>       |
> As you noted, RFC 2560 does not require the extended key usage extension to be present in order for the subordinate CA to sign OCSP responses for its own certificates.  However, according to RFC 2560, by including the extended key usage extension with id-kp-OCSPSigning, the root CA is indicating to relying parties that the subordinate CA is authorized to act as a designated OCSP responder for the root CA.  So, this would make the subordinate CA authorized to provide status information for certificates issued by the root CA, even though the intention was only to indicate that it was authorized to provide status information for its own certificates.
> 
> Dave
>

---

From: [email-masked]
Date: Wed, 30 May 2012 08:38:24 +0200

Russ,

We are now in strong agreement. 

Denis

De :    Russ Housley <[email-masked]>
A :     "David A. Cooper" <[email-masked]>
Cc :    IETF PKIX <[email-masked]>
Date :  29/05/2012 18:25
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :    [email-masked]

David:

This is a very good point.  This would authorize every subordinate CA to 
sign OCSP responses on behalf of the Root CA.  This indeed a serious side 
effect.  Thanks for sharing.

My revised summary:

Russ

Russ,

I occurred to me over the weekend that there is another reason not to 
include an extended key usage extension in the certificate in the case of 
an integrated OCSP responder.  Consider the following scenario of a 
subordinate CA that acts an an integrated OCSP responder with the 
certificate issued by the root CA to the subordinate CA containing 
keyUsage and extended key usage extensions as you suggest:

+----------------+
|    Root CA     |
+----------------+
      |

As you noted, RFC 2560 does not require the extended key usage extension 
to be present in order for the subordinate CA to sign OCSP responses for 
its own certificates.  However, according to RFC 2560, by including the 
extended key usage extension with id-kp-OCSPSigning, the root CA is 
indicating to relying parties that the subordinate CA is authorized to act 
as a designated OCSP responder for the root CA.  So, this would make the 
subordinate CA authorized to provide status information for certificates 
issued by the root CA, even though the intention was only to indicate that 
it was authorized to provide status information for its own certificates.

Dave

My summary:

Russ

Russ, 

Denis 

Russ

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 14:45:33 +0100

> "digitalSignature" to be deemed acceptable for signing non-CRL

PHB just noted in another thread that "The point of standards is to 
achieve interoperability".  I'll restate my question with this thought 
in mind.

We (Comodo) sign OCSP Responses directly from CA Certificates that have 
the keyCertSign and cRLSign bits set but the digitalSignature bit unset. 
  This is/was fully compliant with RFC2459, but (I realized only this 
week) not compliant with 3280/5280.

Thus far, I've not encountered any client software that rejects our OCSP 
Responses.

But to "achieve interoperability", I wish to ensure that no future 
client software rejects our OCSP Responses on the basis that the 
digitalSignature bit is not set in the CA Certificates.

So, can we please reinstate the 2459 text that "The cRLSign bit is 
asserted when the subject public key is used for verifying a signature 
on revocation information" or at least say that cRLSign and/or 
digitalSignature is sufficient for this purpose?

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 31 May 2012 11:25:44 -0400

Rob,

You have three options for the ongoing operations:

1.  Recut the CA certificate with DS bit set.
2.  Issue yourself a responder certificate, i.e., certify the same key, sign it and put no check on it.  Even the life of the certificate can extend to the CA certificate life
3.  Do nothing and wait until some OCSP client barfs on it.

For new installs, it seems the safe thing to do is set the DS bit on in the CA certificate or use option 2 above. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Thursday, May 31, 2012 9:46 AM
To: [email-masked]
Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits

On 29/05/12 09:24, Rob Stradling wrote:
>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or 
>> not the CA Certificate can directly sign OCSP Responses, but sadly I 
>> can find no text to support this idea.
>
> I've unearthed some text to support this idea, so at least I'm now 
> sure I didn't completely make it up myself!
>
> RFC2459 said...

PHB just noted in another thread that "The point of standards is to achieve interoperability".  I'll restate my question with this thought in mind.

We (Comodo) sign OCSP Responses directly from CA Certificates that have the keyCertSign and cRLSign bits set but the digitalSignature bit unset. 
  This is/was fully compliant with RFC2459, but (I realized only this
week) not compliant with 3280/5280.

Thus far, I've not encountered any client software that rejects our OCSP Responses.

But to "achieve interoperability", I wish to ensure that no future client software rejects our OCSP Responses on the basis that the digitalSignature bit is not set in the CA Certificates.

So, can we please reinstate the 2459 text that "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information" or at least say that cRLSign and/or digitalSignature is sufficient for this purpose?

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 16:36:26 +0100

> For new installs, it seems the safe thing to do is set the DS bit on in the CA certificate or use option 2 above.

Hi Santosh.

Yes, I'll make sure the digitalSignature bit is set in new CA 
Certificates we issue in the future.

Recutting our existing CA certificates is not an option.  There are 
rather a lot of them and they are widely deployed.

I don't want to have to use dedicated responder certificates unless I 
really have to.

Are you saying that trying to "fix" the standards is not really an option?

What security hole would be introduced by once again allowing the 
"crlSign" bit to authorize the CA certificate as an Integrated Responder?

> Senior Research&  Development Scientist

---

From: [email-masked] (Martin Rex)
Date: Thu, 31 May 2012 17:59:48 +0200 (CEST)

> "crlSign" bit to authorize the CA certificate as an Integrated Responder?

This is _NOT_ a defect of rfc2560, it was a conscious design decision,
and a careful implementor should have seen this.

So "fixing" does not exist as an option only changing the behaviour
in a successor OCSP spec.  But should still account for implementations
based on rfc2560 alone.

What is more confusing to me is that you're PKI software did not
error on your attempt to sign OCSP responses without the
DigitalSignature bit in your CA cert.  When sensibly implemented,
a signature creation function should perform a number of plausibility
checks on signature creation (including KeyUsage and Validity),
because it does not make sense (other than in very limited debug
situations) to create digital signatures that receipients will
very probably fail verifying.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 31 May 2012 15:25:04 -0400

Rob,

I support a fix to the standards.  I do not see a need for DS bit for CA certificate.

I also do not see a security issue with what you are doing.

I proposed alternatives in case you want to comply with the current standards.

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Thursday, May 31, 2012 11:36 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits

On 31/05/12 16:25, Santosh Chokhani wrote:
> 2.  Issue yourself a responder certificate, i.e., certify the same 
> key, sign it and put no check on it.  Even the life of the certificate can extend to the CA certificate life 3.  Do nothing and wait until some OCSP client barfs on it.
>

Hi Santosh.

Yes, I'll make sure the digitalSignature bit is set in new CA Certificates we issue in the future.

Recutting our existing CA certificates is not an option.  There are rather a lot of them and they are widely deployed.

I don't want to have to use dedicated responder certificates unless I really have to.

What security hole would be introduced by once again allowing the "crlSign" bit to authorize the CA certificate as an Integrated Responder?

>> Why did RFC3280 change the required bit for signing non-CRL 
>> revocation information from "cRLSign" to "digitalSignature"?
>>
> Senior Research&  Development Scientist COMODO - Creating Trust Online

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 31 May 2012 15:27:49 -0400

I support what Rob is doing.  I see no particular need for DS bit in CA certificate.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, May 31, 2012 12:00 PM
To: Rob Stradling
Cc: Santosh Chokhani; [email-masked]
Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits

> "crlSign" bit to authorize the CA certificate as an Integrated Responder?

This is _NOT_ a defect of rfc2560, it was a conscious design decision, and a careful implementor should have seen this.

So "fixing" does not exist as an option only changing the behaviour in a successor OCSP spec.  But should still account for implementations based on rfc2560 alone.

What is more confusing to me is that you're PKI software did not error on your attempt to sign OCSP responses without the DigitalSignature bit in your CA cert.  When sensibly implemented, a signature creation function should perform a number of plausibility checks on signature creation (including KeyUsage and Validity), because it does not make sense (other than in very limited debug
situations) to create digital signatures that receipients will very probably fail verifying.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 22:39:30 +0100

> and a careful implementor should have seen this.

RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign 
bit is asserted when the subject public key is used for verifying a 
signature on revocation information (e.g., a CRL)."

So if there was "a conscious design decision" by the RFC2560 authors 
regarding which Key Usage bits should be set in the Integrated Responder 
case, then surely that decision was in agreement with what I am asking 
for and in disagreement with the altered text in RFCs 3280 and 5280!

> in a successor OCSP spec.  But should still account for implementations

And what about accounting for implementations based on RFC2459 alone?

> DigitalSignature bit in your CA cert.   When sensibly implemented,

Our PKI software was written by me, and until this week I hadn't noticed 
that RFC3280/5280 changed the rules on which Key Usage bit means what. 
Yes, I know RFC3280 was published 10 years ago.  Sorry I didn't notice 
sooner.  Call me a careless implementor if you like.

> very probably fail verifying.

Let's look at this from another angle:
What would happen today if a CA decides to implement an 
RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? 
  If they follow RFC5280's guidance, they will set keyCertSign and 
digitalSignature (but NOT cRLSign) in the CA Certificate(s).
Then, what would happen when an RFC2459-compliant client attempts to 
perform an OCSP check on an end-entity certificate from this PKI?  If 
the client enforces the RFC2459 definitions of the Key Usage bits, it 
would reject the OCSP Response because the CA Certificate does not have 
the cRLSign bit set!!

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 22:41:02 +0100

> I also do not see a security issue with what you are doing.

Thanks Santosh.

> I proposed alternatives in case you want to comply with the current standards.

Understood.

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 01 Jun 2012 08:08:22 +0200

>> information from "cRLSign" to "digitalSignature"?

That is interesting. Way back, a long time ago when we started 
development of integrated OCSP in EJBCA I had to assert digitalSignature 
in the CA certificate in order for things to work in, I think browsers. 
I had never considered that this behaviour might have changed, but it 
sounds as it has.

> achieve interoperability". I'll restate my question with this thought in
> mind.
>