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

From: [email-masked]
Date: Fri, 1 Jun 2012 09:48:50 +0200

Rob,

I do not "buy" your argumentation, since it is based on RFC 2459 which is 
now obsolete and had two successors.
Also, your argumentation is defeated, simply because RFC 2459 was issued 
before RFC 2560, which means 
before OCSP ever existed.

As I already said on the list , at the time RFC 2560 was issued, we should 
have asked to ITU-T to add a OCSPsign key usage bit.
Nobody raised the point at the proper time. It seems too late now. So 
asserting instead the DS bit is not the perfect solution, 
but it is the most acceptable.

Denis 

De :    Rob Stradling <[email-masked]>
A :     [email-masked]
Cc :    "[email-masked]" <[email-masked]>
Date :  31/05/2012 23:39
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :    [email-masked]

On 31/05/12 16:59, Martin Rex wrote:
> Rob Stradling wrote:
>>
>> 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?
>
> This is _NOT_ a defect of rfc2560, it was a conscious design decision,
> 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!

> 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.

And what about accounting for implementations based on RFC2459 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,

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.

>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.

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!!

> -Martin

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

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 1 Jun 2012 10:55:19 +0200

I am not arguing for a OCSPsign bit. However, if it is seen useful, the time
is now if we want it to be in the next edition of X.509, which is almost
finalised. Otherwise, it would be delayed probably another four years.

Implementers will have to judge whether introducing such a bit at this late
state will cause interworking problems.

Erik 

Fra: [email-masked] [mailto:[email-masked]] På vegne af
[email-masked]
Sendt: 1. juni 2012 09:49
Til: Rob Stradling
Cc: [email-masked]
Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits

Rob, 

Denis 

  _____  

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

 <https://www.ietf.org/mailman/listinfo/pkix>

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 11:50:14 +0200 (CEST)

> signature on revocation information (e.g., a CRL)."

Hmmmm.  I think you have a point here.  This definition still applies
to rfc3280 and rfc5280, actually:

http://tools.ietf.org/html/rfc3280#page-29

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on certificate revocation list (e.g., a
      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
      certificates that are used to verify signatures on CRLs.

http://tools.ietf.org/html/rfc5280#page-31

      The cRLSign bit is asserted when the subject public key is used
      for verifying signatures on certificate revocation lists (e.g.,
      CRLs, delta CRLs, or ARLs).

Although 2459/3280/5280 are "profiles of X.509", it seems sensible
to have it apply to technologies that were born/defined in the IETF
and not part of X.509 itself.

> sooner.  Call me a careless implementor if you like.

I'm sorry, I misexplained myself.  In order to make something enforcable
on the RP, it first of all will have to be enforced on the component
that creates that structure/element (=applies the signature).

Our OEM PKI software originally refused to sign a PKCS#10 request
(request for renewal) when the current certificate was already expired,
and I had to employ a special API feature (do not check Validity when
signing) in order to obtain the signature.

When writing PKI software, it would not be sensible to add a check to
the RP part of the software prior to ensuring that the signature
creation part enforced that feature to be correct.

> RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? 

This is actually something that I consider a defect in rfc5280.

Support of OCSP is purely optional (even less that MAY), so support of
CRLs being optional would imply that support of revocation is optional
-- which might be the reason why nobody hard-fails...

http://tools.ietf.org/html/rfc3280#page-49   Last paragraph of Section 5.0

   Conforming CAs are not required to issue CRLs if other revocation or
   certificate status mechanisms are provided. 

                                         Conforming applications are NOT
   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Fri, 01 Jun 2012 12:21:05 +0100

On 01/06/12 08:48, [email-masked] wrote:
> Rob,
>
> I do not "buy" your argumentation, since it is based on RFC 2459 which
> is now obsolete and had two successors.
> before RFC 2560, which means before OCSP ever existed.

2459 section 3.3 describes CRLs as just "one method of certificate 
revocation" and then says "Message formats and protocols supporting 
on-line revocation notification may be defined in other PKIX 
specifications."

So I think it's pretty clear that the authors of 2459 anticipated that 
new certificate revocation methods to be invented.

> As I already said on the list , at the time RFC 2560 was issued, we
> should have asked to ITU-T to add a OCSPsign key usage bit.

At the time 2560 was issued, 2459 was in force.  And 2459 says:
"The cRLSign bit is asserted when the subject public key is used for 
verifying a signature on revocation information (e.g., a CRL)."

OCSP Responses are "revocation information".  "e.g., a CRL" doesn't mean 
"MUST be a CRL".

So presumably the authors of 2560 believed "cRLSign" to be the 
applicable Key Usage bit for Integrated Responder OCSP, but didn't feel 
the need to express this in 2560 because 2459 already expressed it clearly.

> Nobody raised the point at the proper time.

It seems to me that there was no point to raise back then.  2459 was 
clear that "cRLSign" was the appropriate bit to set.

Then 3280 came along and (it seems) changed the rules without clearly 
expressing (IMHO) what the new rules were.

> It seems too late now. So asserting instead the DS bit is not the
 > perfect solution, but it is the most acceptable.
>
> Denis
>
>
>
>
> ------------------------------------------------------------------------
>
>
>

---

From: Rob Stradling <[email-masked]>
Date: Fri, 01 Jun 2012 12:55:05 +0100

> to rfc3280 and rfc5280, actually:

If we can say that OCSP Responses are a form of "certificate revocation 
list", then yes, the definition still applies.

"(e.g., CRLs, delta CRLs, or ARLs)" certainly implies that CRLs, delta 
CRLs and ARLs are not necessarily the only data structures that may 
legitimately be called "certificate revocation lists".

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 14:26:33 +0200 (CEST)

> legitimately be called "certificate revocation lists".

I agree.  The use of "e.g." rather than "i.e." means that the bit is
not limited to those explicitly listed.

Actually, X.509 08/2005 (the one reference by rfc5280) supports this
interpretationn:

X.509-08/2005, Section 8.2.2.3  KeyUsage Extension (page 24)

  g) cRLSign: for verifying an authority's signature on CRLs.

     Since CRL signing is considered to be commitment to the content of
     the CRL by the CRL issuer, neither the digitalSignature bit nor the
     contentCommitment bit need be set in the certificate. If either
     (or both) is set, it does not affect the level of commitment the
     signer has endowed in the signed CRL;

     [...]

  Application specifications should indicate which of the digitalSignature
  or contentCommitment bits are appropriate for their use. If a signing
  application has no knowledge of the signer's intent regarding commitment
  to content, the application shall sign and support that signing with a
  certificate that has the digitalSignature bit set in that certificate's
  keyUsage extension.

The latter paragraph could be interpreted to say, that when OCSP (2560)
had intended to require "digitalSignature", is should have said so.
But it doesn't.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 14:50:32 +0200 (CEST)

> finalised. Otherwise, it would be delayed probably another four years.

Talking about X.509 rev.  when searching through X.509 for references to
OCSP, I was significantly confused by the following paragraph in
X.509 11/2008 Section 7.3 Certificate Validity:

  Only a CA that is authorized to issue CRLs may choose to delegate
  that authority to another entity. If this delegation is done,
  it shall be verifiable at the time of certificate/CRL verification.
  The cRLDistributionPoints extension can be used for this purpose.
  The cRLIssuer field of this extension would be populated with the
  name(s) of any entities, other than the certificate issuer itself,
  that have been authorized to issue CRLs concerning the revocation
  status of the certificate in question.

To me, that paragraph looks non-sensical.  I do not see of a concept
"CA that is authorized to issue CRLs" within X.509.  The KeyUsage
extension has a completely different purpose (usage restrictions
for the accompanying key, but *NO* limits to keys further down
the cert chain).

-Martin

---

From: [email-masked]
Date: Fri, 1 Jun 2012 16:32:24 +0200

X.509-08/2005 states: This Specification defines a Certificate Revocation 
List (CRL) mechanism but does  not preclude the use of alternative 
mechanisms. One such alternative mechanism is the Online Certificate 
Status Protocol (OCSP) specified in IETF RFC 2560.
.
Since OCSP was invented and defined by PKIX, there is no detailed 
discussion in X.509-08/2005.

So you will not find support for your claims in X.509-08/2005, even by 
twisting its words.

Denis

De :    [email-masked] (Martin Rex)
A :     Rob Stradling <[email-masked]>
Cc :    "[email-masked]" <[email-masked]>
Date :  01/06/2012 15:11
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :    [email-masked]

     [...]

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 16:42:23 +0200 (CEST)

> So you will not find support for your claims in X.509-08/2005, even by 

I fail to understand what your reply refers to.

X.509-08/2005 clearly states that an application should state wether
it needs the DigitalSignature KeyUsage attribute asserted.  The way
it is worded, there is no automatic prerequisite of this KeyUsage
in X.509 (different to what the name of the KeyUsage might suggest).

OCSP is both, an extension to X.509 and an application based on X.509.
If OCSP had a requirement for the DigitalSignature KeyUsage, it should
have stated so in rfc2560.

-Martin

---

From: [email-masked]
Date: Fri, 1 Jun 2012 17:05:18 +0200

Martin,

Please refer to the previous emails and my presentation at the last PKIX 
meeting: RFC 2560 is wrong and ambiguous.

In a perfect world, we should have defined an OCSPsign key usage bit. We 
failed to do it, or simply we did'nt.

Do you believe we should define it now ?
If yes, what kind of migration path would you suggest ?
 
If your answer to the first question is no, then the most reasonable 
solution is to request the assertion of  bit 0 
(data origin authentication) in the key usage extension when a CA directly 
signs OCSP responses.

Denis

De :    [email-masked] (Martin Rex)
A :     [email-masked]
Cc :    [email-masked], "[email-masked]" <[email-masked]>, 
[email-masked], Rob Stradling <[email-masked]>
Date :  01/06/2012 16:42
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 17:13:41 +0200 (CEST)

> (data origin authentication) in the key usage extension when a CA directly 

After re-reading the existing specification (X.509 and PKIX) I have
*NOT* found a rationale why an RP could reject an OCSP response signed
by a CA cert that does not have DigitalSignature asserted.

Retrofitting an additional requirement for issuing CAs about certs
that should be permitted to sign OCSP responses in conjunction with
an additional requiremnt for RPs to check, does not make any sense
at this point in time for implementations based on rfc2560.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Fri, 01 Jun 2012 20:49:18 +0100

> by a CA cert that does not have DigitalSignature asserted.

Thanks Martin.  Maybe I should just stop worrying about this issue then.

---

From: [email-masked]
Date: Mon, 4 Jun 2012 09:39:46 +0200

Martin,

I could say as well: After re-reading the existing specification (X.509 
and PKIX) I have
*NOT* found a rationale why an RP could reject an WXYZ response signed
by a CA cert that does not have DigitalSignature asserted.

So this is not a valid argument.

Denis

De :    [email-masked] (Martin Rex)
A :     [email-masked]
Cc :    [email-masked], "[email-masked]" <[email-masked]>
Date :  01/06/2012 17:13
Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 04 Jun 2012 12:50:09 +0200

On 06/04/2012 09:39 AM, [email-masked] wrote:
> Martin,
>
> I could say as well: After re-reading the existing specification 
> (X.509 and PKIX) I have
OCSP is related to these documents and OCSP is revocation
information to set digitalSignature is not required.
Martin only confirms that nothing in these docs requires
rejecting an OCSP response when digitalSignature is not
set.

If WXYZ == TSP you find ...

> Denis
As already pointed out by Santosh, there is IMO no
technical security reason to add a requirement to
have digitalSignature on a CA cert in order to be able
to sign an OCSP  response.

If ever some hypothetical rp doesn't like a CA cert
without digitalSignature, the CA can even create
an OCSP cert for its own key, it still matches the responderID.

leaving alone the problem having responderId and the
same subjectkeyinformation in two certs may
create some problems elsewhere in certficate lookups.

---

From: [email-masked] (Martin Rex)
Date: Mon, 4 Jun 2012 13:08:40 +0200 (CEST)

[email-masked] wrote:
> and PKIX) I have *NOT* found a rationale why an RP could reject an WXYZ
> response signed by a CA cert that does not have DigitalSignature asserted.
 
If the specification that standardizes WXYZ does not indiciate which
particular KeyUsage attributes are required.  Even more so, when that
signed CA response falls into existing cagegories (cert issuance
or cert revocation).  

The IMHO relevant snippets from X.509:

X.509 08/2005  excerpts from 8.2.2.3 Key usage extension   

  Setting a specific value of KeyUsage in a certificate does not in
  itself signal for an instance of communication that the communicating
  parties are acting in accordance with this setting, e.g., when signing
  a document. Definition of methods by which parties may signal their
  intent for a specific instance of communication (e.g., commitment to
  content for that specific instance) is outside the scope of this
  Directory Specification, but it is anticipated that multiple methods
  will exist.

    Since CRL signing is considered to be commitment to the content
    of the CRL by the CRL issuer, neither the digitalSignature bit
    nor the contentCommitment bit need be set in the certificate.
    If either (or both) is set, it does not affect the level of
    commitment the signer has endowed in the signed CRL;

plus the IMHO relevant snippet from rfc5280:

   If the keyUsage extension is present, then the subject public key
   MUST NOT be used to verify signatures on certificates or CRLs unless
   the corresponding keyCertSign or cRLSign bit is set.  If the subject
   public key is only to be used for verifying signatures on
   certificates and/or CRLs, then the digitalSignature and
   nonRepudiation bits SHOULD NOT be set.  However, the digitalSignature
   and/or nonRepudiation bits MAY be set in addition to the keyCertSign
   and/or cRLSign bits if the subject public key is to be used to verify
   signatures on certificates and/or CRLs as well as other objects.

Since OCSP (rfc2560) is completely silent on the KeyUsage attribute
digitalSignature, only the general rules of X.509 and rfc5280 apply.

And rfc5280 has a mere *MAY* for the presence of digitalSignature,
which can *NOT* be interpreted as a "MUST be present" when RP's check
those signatures.

And the "Path validation algorithm" defined in rfc5280 Section 6.x
requires only two checks on KeyUsage:  6.1.4 (n) keyCertSign (page 87)
and 6.3.3 (f) cRLSign (page 94), so as far as rfc5280 is concerned,
only this applies:

  the digitalSignature and/or nonRepudiation bits MAY be set in addition
  to the keyCertSign and/or cRLSign bits if the subject public key
  is to be used to verify signatures on certificates and/or CRLs as well
  as other objects.

So an implementation of rfc5280 that fails because a CA cert that signed
an OCSP response does not have digitalSignature is neither compliant
with rfc2560+rfc5280 nor is it compliant with rfc2560+X.509-08/2005.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Jun 2012 16:05:35 -0400

At 12:55 PM +0100 6/1/12, Rob Stradling wrote:
>If we can say that OCSP Responses are a form of "certificate 
>revocation list", then yes, the definition still applies.

OCSP responses are not a form of CRL. They are a form of cert revocation
status info.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Jun 2012 15:16:28 -0400

OCSP services were operational long before RFC 2459 was issued.

They are not mentioned in RFC 2549 because that would have required
that spec to be delayed until the OCSP spec was complete and it was
already very late.

I am really not sure why we did not get into signature bit settings in
the OCSP spec. I suspect it had something to do with the way that the
spec was changed from being a way that a CA publishes authoritative
certificate status to being a way for anyone to assert certificate
status.

What is done is done, what matters is how we are going to operate
going forward and what practical steps we can take to secure the
Internet as best we can against the best efforts of foreign
governments and parts of our own.

On Fri, Jun 1, 2012 at 7:21 AM, Rob Stradling <[email-masked]> wrote:
> revocation" and then says "Message formats and protocols supporting on-line
> revocation notification may be defined in other PKIX specifications."
>
> So I think it's pretty clear that the authors of 2459 anticipated that new
> certificate revocation methods to be invented.
>
>
> So presumably the authors of 2560 believed "cRLSign" to be the applicable
> Key Usage bit for Integrated Responder OCSP, but didn't feel the need to
> express this in 2560 because 2459 already expressed it clearly.
>
>
> It seems to me that there was no point to raise back then.  2459 was clear
> that "cRLSign" was the appropriate bit to set.
>
>>  > Rob Stradling wrote:
>>  >>
>>  >> 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?
>>  >
>>  > 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
>>  >
> 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.

-- 
Website: http://hallambaker.com/