Subject: OCSP Delegation Clarification

From: Patrick Patterson <[email-masked]>
Date: Tue, 21 Oct 2008 04:35:51 -0400

Hello there,

In RFC2560, there is the following text in section 2.6:

The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

I'm trying to figure out how this is supposed to work. For CRL
delegation, this is very clear - there exists a CRLIssuers field within
CRLDP, and if that value is in the end-entity certificate, then the
designated entity in the CRLIssuers field may issue valid CRL
information for that end-entity certificate.

For OCSP, I fail to see how to build the path for determining the
validity of an OCSP response based on the above.

Can someone clarify?

Thanks.

---
Patrick Patterson
PKI Architect,
Carillon Information Security Inc.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 21 Oct 2008 13:18:04 +0100

> validity of an OCSP response based on the above.

It means that the CA key that signs the certificates covered by the
responder either signs the OCSP response directly or it issues a special
OCSP responder certificate whose key is used to sign responses.

I.e.

CA->OCSP response
CA->OCSP responder certificate->OCSP response

To prevent an end entity certificate masquerading as a responder the
responder certificate must include the id-kp-OCSPSigning
extendedKeyUsage OID.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Patrick Patterson <[email-masked]>
Date: Tue, 21 Oct 2008 08:30:02 -0400

Hi Steve:

> responder certificate must include the id-kp-OCSPSigning
Ok - serves me right for complicating things - I am aware of the

scenario - I guess I was thinking of how the above would be applied to
the scenario where the CA delegates the OCSP response to some other CA,
and I failed to see how this was possible. The answer, of course, is
that it doesn't.

Thanks.

Patrick.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 21 Oct 2008 13:46:48 +0100

"and that the OCSP responder cert contains an EKU marked for OCSP signing"

Yes, that's correct...when OCSP signing delegation is used.

However, when non-delegated OCSP response signing is used, the "OCSP Signing" 
EKU will most likely *not* be present in the certificate that signs the OCSP 
Responses (because that signing certificate will be the CA Certificate that 
issued the certificate for which status information is being requested).
And it is perfectly valid for it to not be present.

This may seem like an obvious point, but at least 1 major OCSP client 
application was broken in this regard for a number of years!  It *only* 
supported OCSP signing delegation!

On Tuesday 21 October 2008 13:13:48 Liaquat Khan wrote:
> In our OCSP client applications we check that the issuer of the OCSP
> responder cert and the issuer of the target certificate is the same; and
> that the OCSP responder cert contains an EKU marked for OCSP signing.
>
> There are some PKI environments where an OCSP responder provides a service
> on behalf of one CA but is actually certified by a different CA (e.g. a
> Root CA within that environment), so you cannot always enforce this check.
>
> Hope this answers your question.
>
> Regards,
> LK
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Patrick Patterson
> Sent: 21 October 2008 12:36
> To: [email-masked]
> Subject: OCSP Delegation Clarification
>
>
> Hello there,
>

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +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: Julien Stern <[email-masked]>
Date: Tue, 21 Oct 2008 14:55:06 +0200

> and I failed to see how this was possible. The answer, of course, is

Well, check the RFC section 4.2.2.2 :
you can also verify that the certificate:

    1. Matches a local configuration of OCSP signing authority for the
    certificate in question; or

in other words: "whatever you feel like".
So you have the option to verify the certificate when delegated to some 
other CA, of even to verify that the number of certificates in the chain 
is an even number ;)

However, the most sensible interpretation (in my humble opinion) is a 
"direct trust" in an OCSP responder certificate...

--
Julien

---

From: "Liaquat Khan" <[email-masked]>
Date: Tue, 21 Oct 2008 16:13:48 +0400

There are some PKI environments where an OCSP responder provides a service
on behalf of one CA but is actually certified by a different CA (e.g. a Root
CA within that environment), so you cannot always enforce this check. 

Regards,
LK 

-----Original Message-----

Hello there,

Can someone clarify?

Thanks.

---
Patrick Patterson
PKI Architect,

---

From: Suomela Tero <[email-masked]>
Date: Tue, 21 Oct 2008 16:07:24 +0300

Hi All,

> > responder either signs the OCSP response directly or it issues a
> > special OCSP responder certificate whose key is used to
> sign responses.
> >
> > I.e.
> >
> > CA->OCSP response

This is how I also would interpret the RFC. However, I just read about this from the book "Understanding PKI" by Carlisle Adams and Steve Lloyd, and their interpretation was that the responder certificate may be signed by some other CA also as long as the client can trust it (the responder or the other CA).

Regards,
Tero

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 21 Oct 2008 08:20:25 -0500

> and I failed to see how this was possible. The answer, of course, is

"""
4.2.2.2  Authorized Responders

    The key that signs a certificate's status information need not be the
    same key that signed the certificate. It is necessary however to
    ensure that the entity signing this information is authorized to do
    so.  Therefore, a certificate's issuer MUST either sign the OCSP
    responses itself or it MUST explicitly designate this authority to
    another entity.  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.  This
    certificate MUST be issued directly by the CA that issued the
    certificate in question.

    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

    Systems or applications that rely on OCSP responses MUST be capable
    of detecting and enforcing use of the id-ad-ocspSigning value as
    described above. They MAY provide a means of locally configuring one
    or more OCSP signing authorities, and specifying the set of CAs for
    which each signing authority is trusted. They MUST reject the
    response if the certificate required to validate the signature on the
    response fails to meet at least one of the following criteria:

    2. Is the certificate of the CA that issued the certificate in
    question; or

    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
    extension and is issued by the CA that issued the certificate in
    question."

    Additional acceptance or rejection criteria may apply to either the
    response itself or to the certificate used to validate the signature
    on the response.
"""

In short per (1), you can specify at the client side direct trust for a 
response signer certificate.  The DoD OCSP infrastructure does this 
currentlym using a self-signed responder cert, and this mode is 
supported in at least two major OCSP client vendors I know of (plus 
OpenSSL and Firefox/Thunderbird).

-- Tim

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Tue, 21 Oct 2008 11:06:54 -0400

> This is how I also would interpret the RFC. However, I just 
> read about this from the book "Understanding PKI" by Carlisle 
> Adams and Steve Lloyd, and their interpretation was that the 
> responder certificate may be signed by some other CA also as 
> long as the client can trust it (the responder or the other CA).
> 

The ability for the acceptance of the OCSP response if it "matches a
local configuration of OCSP signing authority for the certificate in
question" appears to be open to interpretation. The following link
(search for OCSP) shows that IE 7 SP1 is at least allowing some kind of
local configuration:
http://technet.microsoft.com/en-us/library/cc709618.aspx. 

But it also seems that local configuration could be simply interpreted
to mean the client trusts multiple CA's. If CA1 issues a certificate and
CA2 issues an OCSP response for the certificate, and the client trusts
both CA's, it might be a completely valid interpretation that the OCSP
response should be accepted despite no trust relationship between CA1
and CA2. Both CA's are "locally configured" to be trusted.

It also seems that there are some cases where this may be desirable
behavior from a CA's perspective. By having the OCSP signer be in a
separate trust chain from the issuing CA, it could make some migrations
easier when planning for issuer expiration and so forth. 

Regards.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Oct 2008 08:37:57 -0700

>This is how I also would interpret the RFC. However, I just read about this from the book "Understanding PKI" by Carlisle Adams and Steve Lloyd, and their interpretation was that the responder certi…

I no longer have a copy of their book, but you have to take a very limited view of the text in RFC 2560 to come to that conclusion.

If you look at only the first sentence, their conclusion makes sense. If you look at the whole paragraph, it doesn't make sense at all.

--Paul Hoffman, Director
--VPN Consortium

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 21 Oct 2008 18:04:18 +0200

> and CA2. Both CA's are "locally configured" to be trusted.

This shows that the local configuration of trusted OCSP responder certificates without assignment to certain CAs is 
error-prone.

A mechanism similar to the CRLIssuers for CRLs would be desirable.

Johannes

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 21 Oct 2008 11:13:01 -0500

> http://technet.microsoft.com/en-us/library/cc709618.aspx. 

That's in Vista SP1 at DoD behest to support our current OCSP service. 
That others benefit from it is a bonus.  :)

> easier when planning for issuer expiration and so forth. 

Actually, it's a royal pain in the rear, especially with distributed 
OCSP services and client configuration management added to the mix.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 21 Oct 2008 11:33:52 -0500

> If you look at only the first sentence, their conclusion makes sense. If you look at the whole paragraph, it doesn't make sense at all.

I'm not sure I understand the extended discussion.  4.2.2.2 seems 
explicit enough to me:  If the queried certificate's CA doesn't sign the 
response id-kp-OCSPSigning must be in the responder cert; also, clients 
are free to explicitly trust any responder certificate they choose with 
no caveats.

-- Tim

---

From: "Seth Hitchings" <[email-masked]>
Date: Tue, 21 Oct 2008 12:28:55 -0400

I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Tue, 21 Oct 2008 12:49:40 -0400

Tim,

> That others benefit from it is a bonus.  :)

Unfortunately that behavior is unlikely to be universal across clients. When
something works for 70% of clients, that still leaves 30% miffed that
something isn't working for them.

> Actually, it's a royal pain in the rear, especially with 
> distributed OCSP services and client configuration management 
> added to the mix.

I assume you mean it's a pain to allow OCSP responses to be signed by a
separate CA. I'll agree it's undesirable to be ambiguous in the client
behavior, but I can certainly think of cases where this might be useful to
an issuing CA. I was thinking of cases where a CA is migrating from one
trust chain to another, say to plan for expiration of the roots in the chain
being migrated from. Being able to sign all OCSP responses from the chain
being migrated to, rather than keeping track of which end-entity certs had
been migrated and which had not, could make the OCSP infrastructure actually
simpler.

Best regards,

Mike

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Tue, 21 Oct 2008 13:04:47 -0400

Paul,

> I no longer have a copy of their book, but you have to take a 
> very limited view of the text in RFC 2560 to come to that conclusion.
> 
> If you look at only the first sentence, their conclusion 
> makes sense. If you look at the whole paragraph, it doesn't 
> make sense at all.

In looking through the text of the RFC, it looks like section 2.6, which
you cite above, is only part of the discussion on this. Section 4.2.2.2
leaves open the optional client behavior for local configuration.

Regards,

Mike

---

From: Pérez Herrero, David Antonio <[email-masked]>
Date: Tue, 21 Oct 2008 19:23:40 +0200

Hello All.

Then I understand that signing OCSP responder certificate by a root CA (in a multilevel PKI) IS A VALID CASE, and it belongs to first type ("matches a local configuration of OCSP signing authority..."). Is that true?

David.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Seth

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 21 Oct 2008 12:29:59 -0500

> specific delegated trust rules for their communities.

Actually, my experience is that support for explicit OCSP trust is the 
exception, rather than the norm.

-- Tim

---

From: "Seth Hitchings" <[email-masked]>
Date: Tue, 21 Oct 2008 13:47:32 -0400

David,

I would say that anything is a valid case as long as your client supports it; the problem is that you'll either have to find a client that supports delegated (automatic) trust when the OCSP responder certificates are issued by the root CA, or you'll have to manually configure your OCSP client to explicitly trust each and every OCSP client issued by the root CA, which rapidly becomes difficult to manage.

Seth

-----Original Message-----
From: Pérez Herrero, David Antonio [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

David.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Seth

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 21 Oct 2008 13:01:57 -0500

> Then I understand that signing OCSP responder certificate by a root CA (in a multilevel PKI) IS A VALID CASE, and it belongs to first type ("matches a local configuration of OCSP signing authority.…

I would concur.  At one point I had considered adding root-signed OCSP 
responder certificates as a special case, but then I realized it was 
already covered.

-- Tim

---

From: "Seth Hitchings" <[email-masked]>
Date: Tue, 21 Oct 2008 13:59:15 -0400

Sorry, that should have read "trust each and every OCSP responder certificate issued by the root CA".

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seth Hitchings
Sent: Tuesday, October 21, 2008 1:48 PM
To: Pérez Herrero, David Antonio; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

David,

Seth

-----Original Message-----
From: Pérez Herrero, David Antonio [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

David.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Seth

---

From: Pérez Herrero, David Antonio <[email-masked]>
Date: Tue, 21 Oct 2008 20:22:07 +0200

Seth, I agree with you. But in the case of delegation, signing the OCSP responder certificate with a CA different from that issued the certificate, could be a special issue if we go into archiving long term signature world.

If end-entity status information is in ocsp responses form, it would be still necessary to store status information for OCSP responder certificates (now in CRL form). Considering size issue, it's better to store a CRL issued by the CA root (not a ARL in this case) that a CRL issued by an end-entity CA (bigger).

David.

-----Mensaje original-----
De: Seth Hitchings [mailto:[email-masked]] 
Enviado el: martes, 21 de octubre de 2008 19:59
Para: Pérez Herrero, David Antonio; Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Seth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seth Hitchings
Sent: Tuesday, October 21, 2008 1:48 PM
To: Pérez Herrero, David Antonio; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

David,

Seth

-----Original Message-----
From: Pérez Herrero, David Antonio [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

David.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Seth

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 22 Oct 2008 16:40:03 +0100

Responding to the initial question.

> validity of an OCSP response based on the above.

What I think has been stated repeatedly here is that authority to provide OCSP services for the target certificate is either specified in the target certificate itself or a matter of local configuration by the relying party.

The mechanism how to specify this in the target certificate is defined in Section 3.1 of RFC 2560.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Patrick Patterson
> Sent: den 21 oktober 2008 10:36
> To: [email-masked]

---

From: Michael Myers <[email-masked]>
Date: Wed, 22 Oct 2008 14:34:23 -0700

That's pretty much what I intended.

Mike

On Oct 22, 2008, at 8:40 AM, Stefan Santesson wrote (in part):

>
> . . . authority to provide OCSP services for the target certificate  
> is either
> specified in the target certificate itself or a matter of local  
> configuration
> by the relying party.