Subject: Re: [pkix] Revising OCSP

From: koichi sugimoto <[email-masked]>
Date: Wed, 7 Jul 2010 10:31:27 +0900

Dear Cooper,

Let me comment.

P4
> 1.2.  OCSP Responder Architectures

I think we cannot ignore Microsoft's certificate status check logic
described:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=361c
4644-9b1b-41fd-aaf9-370717edcbbc
I think "Designated OCSP Responders" must include this case.

P9
>   [Editor's note: I don't understand how this extension works.  Is the
>   client telling the OCSP server where to route the request?  Can a
>   single request include multiple certificates, each with a different
>   value for the service locator field?  If so, which responder signs
>   the response?  Is the response always signed by the server that
>   directly received the request from the client, even though that
>   server is just routing the request to the authoritative server(s)?
>   Can anyone provide text for this section that provides more clarity
>   on the semantics of this extension?]

OCSP service locator is used the case of OCSP proxy.
For example, identrus 4 corner model adopted this extension.
In this case, a OCSP client have a "Locally Trusted OCSP Responder" that may
not know the status of status of the requested certificate.
The OCSP client generates OCSP request with OCSP service locator taken from
the certificate's AIA extension.
If the "Locally Trusted OCSP Responder" does not have the status of the
certificate, that proxies this request to the other OCSP responder described as
the service locator that knows the status of the certificate.

P13
>2.3.1.  Certificate Revocation Status
Certain product responds "unknown" in case of the requested certificate
had not been published when the corresponding CRL was created.
I think this response is wrong, it must be "good".
Removing this ambiguous, I propose to add this case to "good".

P14
>   [Editor's note: RFC 5019 says that "Clients that do not include a
>   nonce in the request MUST ignore any nonce that may be present in the
>   response."  Is it permissible for a server to include a nonce in the
>   response if there was no nonce in the request?  If the request
>   included a nonce, may the server send a response that includes a
>   different nonce?]

I think the possible combinations are:
	Req	Resp
1)	 o	 o
2)	 o	 -
3)	 -	 -

Where, "o" means exist nonce and "-" means absent.
In the case 1), the responder must include the same nonce to the request.
If the responder caches the response, nonce should not be included in it.
I think the server must not generate the case "4) - o" but in this case,
client should ignore the nonce.

Regards,
Koichi Sugimoto.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 08 Jul 2010 12:13:15 -0400

On 07/06/2010 09:31 PM, koichi sugimoto wrote:
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=361c4644-9b1b-41fd-aaf9-370717edcbbc

Could you be specific about what from this document you believe needs to 
be included in the update to RFC 2560.  I have only skimmed through the 
Microsoft document, but it says that it is based on RFC 5019, which is a 
profile of RFC 2560, and it is not our intention to incorporate RFC 5019 
into the update to RFC 2560.  RFC 5019 will continue to be a useful 
document for implementors to read after the update to RFC 2560 is published.

> the service locator that knows the status of the certificate.

So, is it expected that when the client sends a request to the "locally 
trusted OCSP responder" that contains a service locator extension that 
the response sent to the client is always signed by the "locally trusted 
OCSP responder" or could the "locally trusted OCSP responder" simply 
relay the response from the authoritative OCSP responder back to the 
client?

RFC 2560 begins the "Extensions" section by saying that "[f]or each 
extension, the definition indicates its syntax, processing performed by 
the OCSP Responder, and any extensions which are included in the 
corresponding response."  For the service locator extension did RFC 2560 
intentionally not provide any information about the "processing 
performed by the OCSP Responder"?

> Removing this ambiguous, I propose to add this case to "good".

I think it is already clear from the text that "good" is a valid 
response in this case ("this positive response ... does not necessarily 
mean that the certificate was ever issued").  However, it is not clear 
to me that it is invalid to return an "unknown" response if the 
responder knows that the certificate was not issued ('The "unknown" 
status indicates that the responder doesn't know about the certificate 
being requested').  One could certainly argue that a responder "doesn't 
know about" a certificate that was never issued.  Personally, I don't 
see a problem with a responder returning either response.  It would only 
be a problem if a client mistakenly assumed that a response of "good" 
meant more than it does (e.g., that the certificate was issued and is 
valid).

> client should ignore the nonce.

This matches what I wrote in Section 2.3.3 of the draft.  I just want to 
ensure that I am not changing the protocol.

Dave

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 08 Jul 2010 17:35:56 +0100

> client should ignore the nonce.

This was discussed a while ago. As I recall this point was made:

In the case where the client sends a nonce it can either get back a matching
nonce (if the responder is willing to include a nonce) or no nonce (if it is not).

Suppose a particular responder supports nonces.

An attacker sends a request to a responder without a nonce and gets a nonceless
response back which is case #3 above.

A client could later make a request with a nonce and the attacker could replay
the older request without a nonce. The client might then just think the
responder doesn't support nonces and accept the replayed response.

If instead you disallow #3 and instead have the case:

4) - 	o

where the responder generates a random nonce, this is avoided because the
attacker can never get a nonceless response from the nonce supporting responder.

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: "David A. Cooper" <[email-masked]>
Date: Thu, 08 Jul 2010 13:50:28 -0400

Steve,

Thanks for the explanation of the text in RFC 5019.  How about this for 
Section 2.3.3 (Nonce Response Extension) of my draft?

    This document defines one standard extension that may appear in the
    responseExtensions field of OCSP response messages.  The nonce
    cryptographically binds a request and a response to prevent replay
    attacks.  The nonce extension in the response is identified using the
    same object identifier as is used in the request, id-pkix-ocsp-nonce.

    If the request included a nonce extension (Section 2.1.1.1) then the
    response MUST either omit the nonce extension or include a nonce
    extension that has the same value as the nonce extension in the request.

    An OCSP responder MAY include a nonce extension in a response even
    if no nonce extension was included in the corresponding request.  
Clients
    that do not include a nonce in the request MUST ignore any nonce that
    may be present in the response.

A new paragraph could then be added to the Security Considerations 
section that says something like:

    If an OCSP responder that provides fresh responses to every request that
    includes a nonce only includes nonces in responses corresponding to
    requests that include a nonce then an attacker could obtain a response
    without a nonce and then later replay it to a client that included a 
nonce
    in its request.  The client may be unable to distinguish this replayed
    response from a response received directly from a responder that does
    not support nonces.  A responder that supports nonces may protect
    against this by including a randomly generated nonce in any response
    that corresponds to a request that did not include a nonce extension.

Dave

---

From: Simon Tardell <[email-masked]>
Date: Thu, 8 Jul 2010 21:05:45 +0200

On Thu, Jul 8, 2010 at 18:13, David A. Cooper <[email-masked]> wrote:

> I think it is already clear from the text that "good" is a valid response
> in this case ("this positive response ... does not necessarily mean that the
> certificate was ever issued").  However, it is not clear to me that it is
> invalid to return an "unknown" response if the responder knows that the
> certificate was not issued ('The "unknown" status indicates that the
> responder doesn't know about the certificate being requested').  One could
> certainly argue that a responder "doesn't know about" a certificate that was
> never issued.  Personally, I don't see a problem with a responder returning
> either response.  It would only be a problem if a client mistakenly assumed
> that a response of "good" meant more than it does (e.g., that the
> certificate was issued and is valid).

I agree with Koichi here. There are only three reasonably answers to the
question "is this certificate" revoked: yes, no, and "I don't know, go ask
someone else". If the answer is yes, the certificate can be used, if no not.
"Go ask someone else" is obviously useful. A responder may be temporarily
out of fresh data, but another may be online.

If you let "unknown" be an assertion that the certificate is not issued at
all, then you effectively have two bad answers. What use is that?

/Simon Tardell,
Technology Nexus.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 09 Jul 2010 11:32:46 -0400

I read through the section in the document on Page 9 entitled 
"Independent OCSP Signing Certificate", but I can't understand what it 
is saying.  If I had to guess, however, I would guess that it is 
describing something related to "Locally Trusted OCSP Responders", not 
"Designated OCSP Responders".  Perhaps someone at Microsoft who is 
familiar with this OCSP implementation can clarify the meaning of this 
section in that document.

However, the scope of the current effort to update RFC 2560 is very 
limited, and any changes to the protocol would be considered out of 
scope (except changes that have already been approved in RFC 5019 or 
that are part of draft-ietf-pkix-ocspagility).  So, if the Microsoft 
document is describing something that is not permitted by RFC 2560 or 
RFC 5019, then it cannot be included in the update to RFC 2560.

Dave

On 07/09/2010 11:01 AM, koichi sugimoto wrote:
>> Could you be specific about what from this document you believe needs
>> to be included in the update to RFC 2560.  I have only skimmed through
>> the Microsoft document, but it says that it is based on RFC 5019,
>> which is a profile of RFC 2560, and it is not our intention to
>> incorporate RFC 5019 into the update to RFC 2560.  RFC 5019 will
>> continue to be a useful document for implementors to read after the
>> update to RFC 2560 is published.
>>      
> Please refer "Independent OCSP Signing Certificate" part, on page 9.
> They do not restrict the issuer of OCSP signing certificate to the CA
> that revokes the issued certifcates.
>
> Sugi
>

---

From: koichi sugimoto <[email-masked]>
Date: Sat, 10 Jul 2010 00:42:22 +0900

If the CA can not generate instant CRL and the OCSP responder
generetes response using the CRL, then, the response may be "unknown"
for long time.
To avoid this case, the respoonse should be "good" I think.

Sugi

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 9 Jul 2010 11:57:49 -0400

Maybe it would better capture what's intended if we changed response to "undefined" rather than "unknown".  I've never liked "unknown".

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>koichi sugimoto
>Sent: Friday, July 09, 2010 10:42 AM
>To: [email-masked]
>Subject: Re: [pkix] Revising OCSP
>
>response
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 09 Jul 2010 12:06:26 -0400

I guess I don't understand the implementation model that you are 
considering.  A CRL only lists the certificates that have been revoked.  
I understand that in some cases when a CA issues certificates with 
consecutive serial numbers that an OCSP responder may use the list of 
revoked certificates as the basis for guessing what certificates have 
been issued.  It thought, however, that this was done by OCSP responders 
that only served pre-generated responses.  The OCSP responder would 
pre-generated responses for serial numbers that were likely to 
correspond to certificates that were already issued.  But why would it 
generate signed responses with a response of "unknown" for other 
certificates.  I thought that these OCSP responders just created a batch 
of pre-generated responses with response values of either "good" or 
"revoked", and if a request arrived for a certificate for which no 
pre-generated response had been created it would just send an unsigned 
"unauthorized" response.

But, I can certainly see the problem.  An integrated OCSP responder may 
know that no certificate matching the request was ever issued.  A 
designated or locally trusted OCSP responder whose only source of 
information is CRLs issued by the CA can only guess whether a 
certificate that is not listed as revoked was ever issued.

Aside from that, if you believe that there is a problem with the current 
language, could you please suggest some alternative language?  It would 
then be up to the working group to review the text and decide whether 
the text you proposed is clarifying the protocol or changing it.

Dave

On 07/09/2010 11:42 AM, koichi sugimoto wrote:
> 2010/7/9 Simon Tardell<[email-masked]>:
>    
>>
>> On Thu, Jul 8, 2010 at 18:13, David A. Cooper<[email-masked]>  wrote:
>>      
>>>        
>>>> P13
>>>>
>>>>

---

From: koichi sugimoto <[email-masked]>
Date: Mon, 12 Jul 2010 17:06:24 +0900

Hello Dave,

I apologize my inexperienced in english.
I want to explain as service provider of certificate issuer.
Recently, EV certificates are gradually used as SSL certificates.
For EV certificates, OCSP service is mandatory, therefore, this
discussion is very important for us.
Threre are several method to get revocation information from CA.
Direct reference to certificate table with CA data base is one of the
best solutions if we want to provice the fact of revoked instantly.
But for any reason (CA fault managemant or something), not a few
vendors use CRLs in order to get revocation information from CA.
It is common for us to decide the cycle of CRL publish to once a day
or a few times a day at most.
If a OCSP responder generates response "unknown" or "unauthorized" for
the reason it does not get CRL of its thisUpdate is after published
the referenced certificate, browsers handling this OCSP response does
not produce authorized view for a day at the maximum.
IMO, OCSP responders should not provide the status of valid, but the
fact of revoked.
In other words, "good" contains revoked status implicitly.
OCSP responders which get revocation status from CRL must produce
"good" if the CRL do not contain the serial number of certificate,
even if the certificate is revoked after published the CRL.
Showing the proper policy of OCSP response yields good implemantation, I think.

> But, I can certainly see the problem.  An integrated OCSP responder may know
> that no certificate matching the request was ever issued.  A designated or
> locally trusted OCSP responder whose only source of information is CRLs
> issued by the CA can only guess whether a certificate that is not listed as
> revoked was ever issued.
Yes, that's right!

Regards,
Koichi Sugimoto

2010/7/10 David A. Cooper <[email-masked]>:
> considering.  A CRL only lists the certificates that have been revoked.  I
> understand that in some cases when a CA issues certificates with consecutive
> serial numbers that an OCSP responder may use the list of revoked
> certificates as the basis for guessing what certificates have been issued.
>  It thought, however, that this was done by OCSP responders that only served
> pre-generated responses.  The OCSP responder would pre-generated responses
> for serial numbers that were likely to correspond to certificates that were
> already issued.  But why would it generate signed responses with a response
> of "unknown" for other certificates.  I thought that these OCSP responders
> just created a batch of pre-generated responses with response values of
> either "good" or "revoked", and if a request arrived for a certificate for
> which no pre-generated response had been created it would just send an
> unsigned "unauthorized" response.
>
> But, I can certainly see the problem.  An integrated OCSP responder may know
> that no certificate matching the request was ever issued.  A designated or
> locally trusted OCSP responder whose only source of information is CRLs
> issued by the CA can only guess whether a certificate that is not listed as
> revoked was ever issued.
>
> language, could you please suggest some alternative language?  It would then
> be up to the working group to review the text and decide whether the text
> you proposed is clarifying the protocol or changing it.
>
> Dave
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 12 Jul 2010 09:29:51 -0400

>not produce authorized view for a day at the maximum.

Technically, CRLs never go bad.  If a CRL-initialized OCSP responder fails to obtain a CRL before the last nextUpdate time, there's no reason it can't continue to issue valid responses off that CRL.  DoD's OCSP service does this.

There is a risk that an active attacker could deny the OCSP service's ability to fetch new CRLs in order to exploit this opportunity, but IMHO that's a very low-risk scenario.  I.e., the risk to all relying parties for total PKI shutdown because of normal failures to produce and distribute CRLs far outweighs the risk of a targeted exploit of this window for a small number of certificates.

This could be addressed in the protocol (e.g., a new return code "valid-but-out-of-date" could be introduced), but I really don't think it's worth complicating the protocol over.

-- Tim

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 12 Jul 2010 19:48:32 +0200

Miller, Timothy J. wrote:
> Technically, CRLs never go bad.  If a CRL-initialized OCSP responder
> fails to obtain a CRL before the last nextUpdate time, there's no
> reason it can't continue to issue valid responses off that CRL.
> DoD's OCSP service does this.

Another solution could be based on the nextUpdate field :

4.2.2.1  Time

    The thisUpdate and nextUpdate fields define a recommended validity
    interval. This interval corresponds to the {thisUpdate, nextUpdate}
    interval in CRLs. Responses whose nextUpdate value is earlier than
    the local system time value SHOULD be considered unreliable.

I think it'd make a lot of sense for a CRL based OCSP responder to just 
base the value of the thisUpdate and nextUpdate fields inside his 
response on the thisUpdate and nextUpdate fields of the CRL he's using.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 12 Jul 2010 13:53:12 -0400

>response on the thisUpdate and nextUpdate fields of the CRL he's using.

That's a good catch, but I have to wonder what servers generate and what clients actually do with such responses.

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 00:39:19 +0200

David,

The text discussed is:

"Independent OCSP Signing Certificate:

Windows Vista SP1 and Windows Server 2008 enable the OCSP signing
certificate implemented by the OCSP responder to use a certificate that
terminates in a different root CA than the CA whose revocation information
is reported in the OCSP responses. This feature enables an organization with
a diverse PKI to limit sources of revocation information and the CAs that
can issue OCSP signing certificates."

This just states that the CA issuing certificates that are being checked for
revocation and the OCSP responder providing revocation status information
for these certificates, may be verified under different root certificates.

That is, the CA certificate and the OCSP certificate are validated under
different roots.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 00:43:18 +0200

David,

On 10-07-08 7:50 PM, "David A. Cooper" <[email-masked]> wrote:

>     without a nonce and then later replay it to a client that included a nonce

Wouldn't it be easier to include a requirement that servers MUST either
never provide a nonce, or MUST always provide a nonce? That is, it is not
allowed to sometimes provide nonce.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 12 Jul 2010 20:44:54 -0400

Stefan,

This appears to be a bad idea.  It breaks crypto binding.

I do not think IETF OCSP Standard should support this trust model.

It seems that Microsoft has taken a step backwards.  They require the
same CA key to sign the CRL as the certificate in question.  I thought
this was simplest and most secure way of binding certificate issuer and
revocation status provider.  I think 5280 and X.509 both could benefit
from such constraint.

Now, this model leaves revocation information provider to be anyone.

> Stefan Santesson
> Sent: Monday, July 12, 2010 6:39 PM
> To: David A. Cooper; koichi sugimoto
> Cc: [email-masked]
> is reported in the OCSP responses. This feature enables an
organization
> with

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 13 Jul 2010 09:49:29 -0400

>This appears to be a bad idea.  It breaks crypto binding.

I disagree.  It's a binding established out of band.  It's just not obvious from inspecting *only* the request/response pair; you have to inspect the request/response in the context of the client configuration.

>revocation status provider.  I think 5280 and X.509 both could benefit

Simplest doesn't always equate to operationally useful.  Large PKIs may not have the computational capacity to issue certs, generate CRLs *and* service OCSP all at the same time.  Sizing CAs and HSMs for the combinations requires overbuilding and increases cost.  CA signed makes building a robust and globally distributed OCSP service much more difficult--or even impossible, when we start talking about austere and/or intermittent network environments (e.g., when one lives at the end of a 9600baud satellite relay). The CA signed model also encourages implementers to increase the attack surface on issuing CAs.

>Now, this model leaves revocation information provider to be anyone.

What, like the OCSP direct trust model didn't do this already?

-- Tim

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 13 Jul 2010 10:48:07 -0400

Stefan,

I found a little more information on this on Page 13 of the document in 
the "OCSP Specific Information" section:

       For Windows Vista with Service Pack 1 and
       Windows Server 2008, the OCSP signing
       certificate may chain up to any trusted root CA
       as long as the certificate chain includes the
       OCSP Signing EKU extension.

Whether this is a good or bad trust model, I still think it falls under 
the category of "Locally Trusted OCSP Responder" rather than "Designated 
OCSP Responder", and I would not be inclined to add any text to the RFC 
2560 update to specifically address this trust model.

Dave

On 07/12/2010 06:39 PM, Stefan Santesson wrote:
> On 10-07-09 5:32 PM, "David A. Cooper"<[email-masked]>  wrote:
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 16:57:51 +0200

David,

I agree with your conclusion.

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 13 Jul 2010 11:55:00 -0400

Stefan,

While I agree that it would be easier to state your proposed 
requirement, I think it would be a change to OCSP rather than a 
clarification of what was required by RFC 2560.  So, I would be hesitant 
to make such a change unless there was evidence that every OCSP 
responder implementation already does this.

It may be OK, however, to state this as a "should" in the Security 
Considerations section.  Rather than the text that I proposed below, the 
Security Considerations section could say:

    The OCSP protocol does not provide a way for the client to know whether
    the server supports nonces.  Therefore, if a client includes a nonce 
in a
    request and receives a response that does not include a nonce, it 
may not
    be able to determine whether the response was sent by a server that
    does not support nonces or the response was sent by an attacker that
    replayed an old response from the server.  In order to protect clients
    from these replay attacks, servers should either include a nonce in
    every response that they sign or omit the nonce extension from every
    response that they sign.  Servers that support nonces should include a
    randomly generated nonce in responses to requests that do not include
    nonces.

On 07/12/2010 06:43 PM, Stefan Santesson wrote:
> David,
>
>
> On 10-07-08 7:50 PM, "David A. Cooper"<[email-masked]>  wrote:
>
>

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 13 Jul 2010 10:28:06 -0700

Let me make sure I understand what everyone here is agreeing on.. Unless I've the wrong idea, assuming I've the appropriate trust anchors installed, you guys agree that:
 
- Every commercial CA should be trusted to publish revocation data for their competitor's CAs
- Every CA in my trust store should be trusted to publish revocation data for the Federal Government
- PKI X, cross certified with a Bridge, is trusted to publish revocation data for cross certified PKI Y
 
Essentially, you agree that every CA we trust is fully trusted to issue OCSP responders that will be trusted to provide revocation data for every other CA we trust irrespective of the fact they have zero affiliation with one another. And that's the intended behavior?
 
I must say I think that sounds like a bad plan. Did I miss something in this thread?

________________________________

From: [email-masked] on behalf of Stefan Santesson
Sent: Tue 7/13/2010 10:57 AM
To: David A. Cooper
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

David,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 20:41:03 +0200

Hi Matt,

Well, I don¹t think you read David¹s conclusion
I only agreed that trusting a different root is a matter of local
configuration.
That is not the same as agreeing with all the stuff you list.

/Stefan

On 10-07-13 7:28 PM, "Matt Cooper" <[email-masked]> wrote:

> Let me make sure I understand what everyone here is agreeing on.. Unless I've
> the wrong idea, assuming I've the appropriate trust anchors installed, you
> guys agree that:
>  
> Essentially, you agree that every CA we trust is fully trusted to issue OCSP
> responders that will be trusted to provide revocation data for every other CA
> we trust irrespective of the fact they have zero affiliation with one another.
> And that's the intended behavior?
>

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 13 Jul 2010 12:45:54 -0700

Hi Stefan,
 
I was responding specifically to the quoted text which I found rather alarming -
 
>        OCSP Signing EKU extension.
 
There is no caveat in that statement about the ability to locally configure, constrain, or explicitly identify which of the trusted root CAs that can be used in this fashion - it simply says "any." If that is in fact the behavior, doesn't that make the stuff I listed true?
 
Arguably unjustified, but I took the lack of any statement to the contrary and a discussion regarding whether we needed to change 2560 to keep that behavior as an implied agreement with it.
 
-Matt

From: Stefan Santesson [mailto:[email-masked]]
Sent: Tue 7/13/2010 2:41 PM
To: Matt Cooper; David A. Cooper
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

Hi Matt,

Well, I don't think you read David's conclusion
I only agreed that trusting a different root is a matter of local configuration.
That is not the same as agreeing with all the stuff you list.

/Stefan

	

	
	David,

	/Stefan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 13 Jul 2010 17:40:23 -0400

How does a client that doesn't support nonces tell the difference between a response with a random nonce from a replayed response with someone else's nonce?

I think it better fits the bill to require clients that *send* a nonce to reject responses that don't contain it, or suggest that that all clients be more sensitive to producedAt timestamps.

-- Tim

>David A. Cooper
>Sent: Tuesday, July 13, 2010 10:55 AM
>To: Stefan Santesson
>Cc: [email-masked]
>Subject: Re: [pkix] Revising OCSP (nonces)
>
>Stefan,
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 13 Jul 2010 17:42:44 -0400

> Did I miss something in this thread?

Yes.  The decision to trust or not trust any signature authority on any OCSP response is *entirely* in the hands of the requestor.  Always has been, always will be, and nothing in the standard can change that.

-- Tim

>Matt Cooper
>Sent: Tuesday, July 13, 2010 12:28 PM
>To: Stefan Santesson; David A. Cooper
>Cc: [email-masked]
>Let me make sure I understand what everyone here is agreeing on.. Unless
>I've the wrong idea, assuming I've the appropriate trust anchors
>installed, you guys agree that:
>
>Essentially, you agree that every CA we trust is fully trusted to issue
>OCSP responders that will be trusted to provide revocation data for
>every other CA we trust irrespective of the fact they have zero
>affiliation with one another. And that's the intended behavior?
>
>organization with

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Jul 2010 18:01:08 -0400

At 5:42 PM -0400 7/13/10, Miller, Timothy J. wrote:
>Yes.  The decision to trust or not trust any signature authority on 
>any OCSP response is *entirely* in the hands of the requestor. 
>Always has been, always will be, and nothing in the standard can 
>change that.
>
>-- Tim

Tim,

I think your answer is a bit too glib.

I agree that the RP always gets to decide who to trust for what. 
However, when we write a standard we have the opportunity to make 
precise statements about what forms of behavior (e.g., due to local 
configuration) MUST. SHOULD, or MAy be supported. We also have an 
obligation to alert users and developers to adverse security 
implications associated with some choices.

So, if a CA issues a cert to an OCSP responder (with the appropriate 
EKU) we should note what the expected scope is for that responder.

If an administrative entity configures a cert (EE or CA) for a local 
OCSP responder  (or set thereof, it is telling its RPs that ALL certs 
are to be checked via this responder, period.

What Matt cited as a bad idea is allowing any TA configured for an RP 
to be acceptable as a source of cert revocation status info for ALL 
CAs, via an OCSP responder that happens to have a cert that chains to 
any TA.  I agree with Matt that we ought not include language in this 
document that encourages implementations to support this "feature" 
and that we ought to consider a warning in the secruity 
considerations section about the adverse implications of such.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 13 Jul 2010 19:10:41 -0400

Tim,

See responses below.

> From: Miller, Timothy J. [mailto:[email-masked]]
> Sent: Tuesday, July 13, 2010 9:49 AM
> To: Santosh Chokhani; Stefan Santesson; David A. Cooper; koichi
> sugimoto
> Cc: [email-masked]
> Subject: RE: [pkix] Revising OCSP
> 
> I disagree.  It's a binding established out of band.  It's just not
> obvious from inspecting *only* the request/response pair; you have to
> inspect the request/response in the context of the client
> configuration.
I do not see anything in 2560 in terms of rules to do the authorization
check securely.

> Simplest doesn't always equate to operationally useful.  Large PKIs
may
> not have the computational capacity to issue certs, generate CRLs
*and*
> service OCSP all at the same time.  Sizing CAs and HSMs for the
> combinations requires overbuilding and increases cost.  CA signed
makes
> building a robust and globally distributed OCSP service much more
> difficult--or even impossible, when we start talking about austere
> and/or intermittent network environments (e.g., when one lives at the
> end of a 9600baud satellite relay). The CA signed model also
encourages
> implementers to increase the attack surface on issuing CAs.
Well if this a large PKI, a few OCSP delegated certificates by the CA
should not add much to the workload.

> What, like the OCSP direct trust model didn't do this already?
Direct trust model says that I install a trust anchor and trust it to
sign OCSP for all certificates.  That is a far cry from any trust anchor
or any certificate rooted at any trust anchor can provide revocation
status of any certificate rooted at any of the trust anchors.

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 13 Jul 2010 17:39:24 -0700

Thanks Steve,
 
To reflect off of Tim's comment, I think it's an important observation that this "feature" not only erodes trust but it also effectively takes away the RPs ability to control trust in real world scenarios. PKI standards are designed to provide the RP the ability to reliably control trust determinations and, as you noted, they are generally prescriptive about how this must be accomplished using inputs and configuration. Given this, I think it would be worth considering a clarification to the following wording:
 
   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.
 
To my eye, the intent of that wording is exactly what we think the behavior should be. Although the sentence starts with "MAY", the second half of the sentence must not be considered optional or implied behavior if you implement the first half. Perhaps clarifying it along the lines of the following: (subject to further edit obviously)
 
   They MAY provide a means of locally configuring one
   or more OCSP signing authorities. If such means is provided, the system or application MUST require explicit configuration to specify the set of CAs for
   which each locally configured signing authority is trusted.
 
Recognizing that the "set of CAs" could be a single CA, a list of CAs, or a wildcard if desired, I think this is the intended and reasonable behavior.
 
-Matt

From: Stephen Kent [mailto:[email-masked]]
Sent: Tue 7/13/2010 6:01 PM
To: Miller, Timothy J.
Cc: Matt Cooper; Stefan Santesson; David A. Cooper; [email-masked]
Subject: Re: [pkix] Revising OCSP

Tim,

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Jul 2010 15:33:44 +1200

>for cross certified PKI Y

Given the universal implicit cross-certification that's used in the majority
of RP software today, this is already the case, and has been so for years and
years.  So while it may sound scary if you put it like you do above, it's
really not much different from current practice.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Jul 2010 07:27:46 +0200

More so,

Just because an OCSP responder is trusted, does not mean that it is given
the power to revoke anything at will.

It still need to be asked by the RP to provide status information for the
certificate in question.

/Stefan

---

From: "Matt Cooper" <[email-masked]>
Date: Wed, 14 Jul 2010 03:32:22 -0700

Stefan,
 
> the power to revoke anything at will.

If you trust every trusted CA to create OCSP responders to give status for every other CA, then every OCSP responder clearly has the power to revoke or "unrevoke" anything and everything at will from a trust standpoint. 
 
> It still need to be asked by the RP to provide status information for the
 
I don't think the assurance provided by OCSP should change based on the insecurity of your local network, DNS source, and all network links between you and the OCSP responder. We should not design security around an assumption that communications using an unsecured protocol on an unsecured network are 100% safe and secure.
 
-Matt

From: Stefan Santesson [mailto:[email-masked]]
Sent: Wed 7/14/2010 1:27 AM
To: Peter Gutmann; [email-masked]; Matt Cooper
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

More so,

/Stefan

---

From: "Matt Cooper" <[email-masked]>
Date: Wed, 14 Jul 2010 03:55:51 -0700

Hi Peter,
 
I'm not seeing what you're getting at here. This is essentially about trusting untrusted networks to tell you what revocation data you should use. Analogy:
 
I want to check a cert issued by XYZ so my software goes out into the untrusted Internet waters to download http://xyzca.com/crl.crl 
 
However, a malevolent DNS server gives me the IP address for http://someotherca.com/crl.crl which I download instead. 
 
Seeing that I also trust someotherca, I figure it's fine to use that CRL instead of the one issued by XYZ because my DNS server told me so?
 
As far as I know, that's not how software works today - but that's what we're talking about doing with OCSP. Simply substitute OCSP for CRL in the example. Much like this doesn't fly for CRLs, I don't believe this behavior should be permitted by 2560. There must be cryptographic binding, or, explicit RP configuration to tie the CAs to the responders.
 
-Matt

From: Peter Gutmann [mailto:[email-masked]]
Sent: Tue 7/13/2010 11:33 PM
To: [email-masked]; Matt Cooper; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 14 Jul 2010 17:44:19 -0400

> How does a client that doesn't support nonces tell the difference between a response with a random nonce from a replayed response with someone else's nonce?

As RFC 5019 says, such a client must ignore any nonces that appear in 
the response.  So, a client that does not support nonces would not be 
using the presence/absence or value of a nonce extension in a response 
in determining whether to accept the response.

> I think it better fits the bill to require clients that *send* a nonce to reject responses that don't contain it, or suggest that that all clients be more sensitive to producedAt timestamps.

The working group tasked me to update RFC 2560 to clarify the text 
without making any changes to the protocol.  Requiring clients that 
include a nonce in their requests to reject responses that don't contain 
a nonce would be a change in the protocol.

Certainly if a client receives a response from a server that does not 
include a nonce, then it needs to make use of other information (e.g., 
producedAt, thisUpdate, nextUpate) to determine whether to accept the 
response.  However, RFC 5019 says that a client that does not include a 
nonce in a request may receive a response that includes a nonce.  
Stephen N. Henson explained the reason that this is allowed 
(http://www.ietf.org/mail-archive/web/pkix/current/msg27971.html).  If a 
server that supports nonces includes a nonce in every response, then 
clients that include nonces in their requests cannot be tricked into 
accepting an old replayed response.

The section that describes nonces needs to say that a server may include 
a nonce in a response even if the corresponding request did not include 
one, since that is permitted by the protocol.  In order to avoid 
confusion, it would seem appropriate to include some rationale for the 
reason that this is permitted, and the Security Considerations section 
seems to be an appropriate place to include that rationale.

Of course, even if every server that supports nonces follows the advice 
to include a nonce in every request, clients still need to be able to 
properly handle responses that do not include nonces by relying on other 
information in the response.

Dave

>>     the server supports nonces.  Therefore, if a client includes a nonce in a
>>     request and receives a response that does not include a nonce, it may not

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Jul 2010 02:14:04 +0200

Matt,

On 10-07-14 12:32 PM, "Matt Cooper" <[email-masked]> wrote:

> If you trust every trusted CA to create OCSP responders to give status for
> every other CA, then every OCSP responder clearly has the power to revoke or
> "unrevoke" anything and everything at will from a trust standpoint.
>  

Now, I don't argue that you should make such trust configuration, but what
you say is not necessarily true.

Just because I trust an OCSP responder, does not mean that this OCSP
responder can revoke any certificate.

How would the OCSP responder initiate such revocation action without being
asked by the RP to provide status information?

It's not like the OCSP responder can get on the phone and convince the RP to
not trust a cert.  

> I don't think the assurance provided by OCSP should change based on the
> insecurity of your local network, DNS source, and all network links between
> you and the OCSP responder. We should not design security around an assumption
> that communications using an unsecured protocol on an unsecured network are
> 100% safe and secure.
>  

I think you read the spec the wrong way. First of all, the DNS and routing
stuff is irrelevant since the identity of the OCSP responder is provided by
a certificate.

The RP have a certificate to be checked and it will, based on the
certificate and on local configuration decide which OCSP responder to ask
for status.

OCSP allows the RP to locally configure an OCSP responder that is not
certified directly under the CA issuing the cert.

We do however agree that it would be a bad local configuration to randomly
ask any OCSP responder and trust it to provide accurate status information.

I do not see any problems however if an organization sets up their own OCSP
responder (which for example pulls down CRLs from all relevant CAs) to act
as a local OCSP responder for that local organization under it's own root.

A client in that organization could the local OCSP responder first, before
it tries any external responder/CRL identified in the certificate.

This is how I read the Microsoft approach and it seems sensible to me if
configured right.

/Stefan

---

From: koichi sugimoto <[email-masked]>
Date: Thu, 15 Jul 2010 15:18:03 +0900

Hello Dave,

> 2560 update to specifically address this trust model.

As you noted before, there must be some crypto binding between the
issuer of the certificate that may be revoked and the issuer of
corresponding OCSP resoponse, I think.
But I guess Microsoft adopted this implementation for any unavoidable
interoperability problems.
They must have some out-of-bound mechanism for the crypto binding problem.
If the goal of this discussion is to remove ambiguity of RFC2560 and
clarify the trust model of OCSP responder, then, Microsoft's
implementation should be stated somewere.
Note that their implementation seems to contain not only the case with
OCSP responses chained up to different root but also the case with
OCSP responses chained up to the same root (but not directry certified
by the CA that revoke certificates) implicitly.
On the other hand, as for the crypto binding, similar case exists in
indirectCRL described in RFC 5280.
"4.2.1.13.  CRL Distribution Points" and "5.3.3.  Certificate Issuer"
are the binding between the CRL issuer and the certificate issuer.

"4.2.1.13.  CRL Distribution Points" states:

>   The cRLIssuer identifies the entity that signs and issues the CRL.
>   If present, the cRLIssuer MUST only contain the distinguished name
>   (DN) from the issuer field of the CRL to which the DistributionPoint
>   is pointing.

"5.3.3.  Certificate Issuer" states:

>   This CRL entry extension identifies the certificate issuer associated
>   with an entry in an indirect CRL, that is, a CRL that has the
>   indirectCRL indicator set in its issuing distribution point
>   extension.  When present, the certificate issuer CRL entry extension
>   includes one or more names from the issuer field and/or issuer
>   alternative name extension of the certificate that corresponds to the
>   CRL entry.  If this extension is not present on the first entry in an
>   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
>   subsequent entries in an indirect CRL, if this extension is not
>   present, the certificate issuer for the entry is the same as that for
>   the preceding entry.  This field is defined as follows:
>
>   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }
>
>   CertificateIssuer ::=     GeneralNames
>
>   Conforming CRL issuers MUST include in this extension the
>   distinguished name (DN) from the issuer field of the certificate that
>   corresponds to this CRL entry.  The encoding of the DN MUST be
>   identical to the encoding used in the certificate.

Even though described above, I think this binding is not sufficient
from cryptographic point of view, because the binding is based on
names, not based on keys.
Therefore, in this model, there must be some out-of-bound mechanism
like Microsoft's.
It may be reqired certificate extension for OCSP responder's DN like CRLDP.

Regards,
Koichi Sugimoto.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Jul 2010 08:58:57 -0400

We got it wrong on the CRL and indirect CRL in terms of crypto binding.

Let us not get it wrong with the OCSP and take a step backwards.

> Sent: Thursday, July 15, 2010 2:18 AM
> To: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Jul 2010 13:43:23 -0400

Stefan,

My apologies for jumping in here.

On the issue of a Responder being able to arbitrarily determine the
revocation status of a certificate, some of the commonly used Responders
do offer the capability to change the revocation status of a
certificate.

On the issue of a RP client being configured to trust a responder, that
is already covered by one of the RFC 2560 models -- locally trusted OCSP
Responder.

On the issue of Microsoft approach, are you sure about that.  From your
words and some testing indicate that any CA in the chain of any root can
act as an authoritative OCSP Responder for any certificate.  The only
requirement may be the CAPI Store property of OCSP Signing.

What is worse is that as we get more and more connected (trustwise) via
cross certification, root constraint means less and less and this MSFT
CAPI Store property is too thin a branch to hang a hat, let alone build
a nest or PKI on.  Imagine, I have one trust anchor and rest of the
trust comes via cross certification and any CA in this trust graph can
create an OCSP Responder for any other CA.

A real bad security model.

> Sent: Wednesday, July 14, 2010 8:14 PM
> To: Matt Cooper; Peter Gutmann; [email-masked]
> Cc: [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Jul 2010 20:24:32 +0200

Hi Santosh,

On 10-07-15 7:43 PM, "Santosh Chokhani" <[email-masked]> wrote:

> On the issue of Microsoft approach, are you sure about that.

No, that is how I read what was sated earlier in this discussion.

>  From your

But that is only one of many aspects that determine if an OCSP responder is
used and trusted.

The property and root store only determines if the responder chains to a
root that is approved for validating OCSP responder certificates. It does
not say that any OCSP responder under this root must be trusted for
everything. And it still need to be asked to provide a response.

> A real bad security model.

I still think you miss a fundamental aspect. Just because an OCSP responder
is trusted as OCSP responder does not mean that it will be trusted to
provide responses for any certificate. The RP still need to decide which
OCSP responder is the appropriate one to ask for status.

I don't se the problem. Maybe I'm missing something.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Jul 2010 15:11:23 -0400

Stefan,

How does the client side logic determine which OCSP Responder is
authoritative for which certificate?

> Sent: Thursday, July 15, 2010 2:25 PM
> To: Santosh Chokhani; Matt Cooper; Peter Gutmann;
[email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >>>> Just because an OCSP responder is trusted, does not mean that it
> is
> >> given
> >> Now, I don't argue that you should make such trust configuration,
> but
> >> what
> >> How would the OCSP responder initiate such revocation action
without
> >> being
> >> It's not like the OCSP responder can get on the phone and convince
> the
> >> RP to
> >> not trust a cert.
> >>
> >>
> >>> I don't think the assurance provided by OCSP should change based
on
> >> the
> >>> insecurity of your local network, DNS source, and all network
links
> >> between
> >>> you and the OCSP responder. We should not design security around
an
> >> assumption
> >> certificate and on local configuration decide which OCSP responder
> to
> >> ask
> >> for status.
> >>
> >> I do not see any problems however if an organization sets up their
> own
> >> OCSP
> >> responder (which for example pulls down CRLs from all relevant CAs)
> to
> >> act
> >> as a local OCSP responder for that local organization under it's
own
> >> root.
> >> This is how I read the Microsoft approach and it seems sensible to
> me
> >> if
> >> configured right.
> >>
> >> /Stefan
> >>
> >>
> >>
> >>
> >>
> >>
> >>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Jul 2010 15:36:42 -0400

>I still think you miss a fundamental aspect. Just because an OCSP
>responder is trusted as OCSP responder does not mean that it will be trusted to

>I don't se the problem. Maybe I'm missing something.

I pulled the MS doc in question and there's no mention of a configured certificate trust list for OCSP signature validation.  The previously noted wording on p.13 is re-stated on p.23 thus:

"""
To be considered a valid OCSP signing certificate, the certificate must contain the OCSP Signing Enhanced Key Usage (EKU) object identifier (1.3.6.1.5.5.7.3.9). In addition, the certificate must form a valid chain from the OCSP signing certificate to a trusted root CA. Windows Vista SP1 and Windows Server 2008 support an OCSP Signing certificate that chains to a different root CA than the certificate being checked for revocation status (as shown in Figure 3). If the OCSP signing certificate chains up to a different root CA, the chain must be valid for the OCSP Signing usage. In this figure, the OCSP responder implements a signing certificate that chains to Root CA2, but is signing OCSP responses for the Internal Issuing CA1 that chains to Root CA1.
Additionally, Windows Vista SP1 and Windows Server 2008 enable configuration of custom OCSP download locations through Group Policy.
"""

And further reinforced on p.25:

"""
To allow the use of a different rooted chain for the OCSP signing certificate, the following changes were made to the chaining engine:

*       The certificates, which are part of the chain for the OCSP signing certificate to its root CA, will be sent by the OCSP server as part of the OCSP response. As described in RFC 2560, the OCSP response can also include an explicit sequence of certificates. CryptoAPI 2.0 will look through the certificates in the OCSP response to discover the intermediate certificates that exist between the OCSP signing certificate and the trusted root CA.

*       If the OCSP response does not provide enough information to build a certificate chain, CryptoAPI 2.0 will use the authority information access extension in the OCSP signing certificate to build the certificate chain.

If a certificate chain from the OCSP signing certificate to a trusted root CA cannot be validated, then CryptoAPI 2.0 will return an error message that the revocation server was offline.
"""

I queried colleagues who've worked with the system, they don't know of any certificate trust list configuration for OCSP either.  Since no-one on this thread has mentioned specific testing of the MS OCSP client on this particular point, I'm going to try to cause it to be tested.

-- Tim

---

From: Yogesh Mehta <[email-masked]>
Date: Thu, 15 Jul 2010 13:04:16 -0700

Let me clarify the Windows OCSP client behavior.
There is no configurable certificate trust list for OCSP validation. But, as Stefan indicated, the relying party needs to indicate which OCSP responder to ask for OCSP status. This can be configured by specifying the additional OCSP download URLs through group policy. This is described in Appendix A of the document referred to in this thread (also available online here - http://technet.microsoft.com/en-us/library/ee619786(WS.10).aspx). This OCSP URL can be configured per CA and is used to check status of certificates issued by that CA.
If no such OCSP responder URL is configured, the client will use the OCSP responder URL from the AIA extension in the certificate to check status. 

An OCSP responder will be used to check status only for those certificates that either explicitly include an OCSP AIA extension pointing to the responder or have been explicitly configured as such by the RP using the GP configuration described above.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Thursday, July 15, 2010 12:37 PM
To: 'Stefan Santesson'; Santosh Chokhani; Matt Cooper; Peter Gutmann; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

>responder is trusted as OCSP responder does not mean that it will be 
>trusted to provide responses for any certificate. The RP still need to 
>decide which OCSP responder is the appropriate one to ask for status.

"""

"""

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Jul 2010 16:17:58 -0400

Yogesh,

Your response seems to be focused how the clients locate the OCSP
Responder.

What I am trying to find out how do clients come to trust an OCSP
Responder in general as well as for a specific certificate.

> From: Yogesh Mehta [mailto:[email-masked]]
> Sent: Thursday, July 15, 2010 4:04 PM
> To: Miller, Timothy J.; 'Stefan Santesson'; Santosh Chokhani; Matt
> Cooper; Peter Gutmann; [email-masked]
> Cc: [email-masked]
> There is no configurable certificate trust list for OCSP validation.
> But, as Stefan indicated, the relying party needs to indicate which
> OCSP responder to ask for OCSP status. This can be configured by
> specifying the additional OCSP download URLs through group policy.
This
> is described in Appendix A of the document referred to in this thread
> (also available online here - http://technet.microsoft.com/en-
> us/library/ee619786(WS.10).aspx). This OCSP URL can be configured per
> CA and is used to check status of certificates issued by that CA.
> If no such OCSP responder URL is configured, the client will use the
> OCSP responder URL from the AIA extension in the certificate to check
> status.
> 
> An OCSP responder will be used to check status only for those
> certificates that either explicitly include an OCSP AIA extension
> pointing to the responder or have been explicitly configured as such
by
> the RP using the GP configuration described above.
> 
> Miller, Timothy J.
> I pulled the MS doc in question and there's no mention of a configured
> certificate trust list for OCSP signature validation.  The previously
> noted wording on p.13 is re-stated on p.23 thus:
> 
> """
> To be considered a valid OCSP signing certificate, the certificate
must
> contain the OCSP Signing Enhanced Key Usage (EKU) object identifier
> (1.3.6.1.5.5.7.3.9). In addition, the certificate must form a valid
> chain from the OCSP signing certificate to a trusted root CA. Windows
> Vista SP1 and Windows Server 2008 support an OCSP Signing certificate
> that chains to a different root CA than the certificate being checked
> for revocation status (as shown in Figure 3). If the OCSP signing
> certificate chains up to a different root CA, the chain must be valid
> for the OCSP Signing usage. In this figure, the OCSP responder
> implements a signing certificate that chains to Root CA2, but is
> signing OCSP responses for the Internal Issuing CA1 that chains to
Root
> CA1.
> Additionally, Windows Vista SP1 and Windows Server 2008 enable
> configuration of custom OCSP download locations through Group Policy.
> """
> 
> To allow the use of a different rooted chain for the OCSP signing
> certificate, the following changes were made to the chaining engine:
> 
> *       The certificates, which are part of the chain for the OCSP
> signing certificate to its root CA, will be sent by the OCSP server as
> part of the OCSP response. As described in RFC 2560, the OCSP response
> can also include an explicit sequence of certificates. CryptoAPI 2.0
> will look through the certificates in the OCSP response to discover
the
> intermediate certificates that exist between the OCSP signing
> certificate and the trusted root CA.
> 
> *       If the OCSP response does not provide enough information to
> build a certificate chain, CryptoAPI 2.0 will use the authority
> information access extension in the OCSP signing certificate to build
> the certificate chain.
> 
> If a certificate chain from the OCSP signing certificate to a trusted
> root CA cannot be validated, then CryptoAPI 2.0 will return an error
> message that the revocation server was offline.
> """
> 
> I queried colleagues who've worked with the system, they don't know of
> any certificate trust list configuration for OCSP either.  Since
no-one
> on this thread has mentioned specific testing of the MS OCSP client on
> this particular point, I'm going to try to cause it to be tested.
> 
> -- Tim
> 
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 15 Jul 2010 16:22:17 -0400

>But, as Stefan indicated, the relying party needs to indicate which OCSP
>responder to ask for OCSP status. This can be configured by specifying
>the additional OCSP download URLs through group policy.

That's not what the documentation says.  

Group policy clearly is used to configure OCSP services when certificates don't contain the OCSP AIA, or to override the OCSP AIA in certificates that have them.  This impacts the algorithm for selecting OCSP over CRLs.

The OCSP signature validation algorithm does not reference any group policy settings. 

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Jul 2010 01:17:43 +0200

> authoritative for which certificate?

In this case by local configuration.

Pick any suitable method (Microsoft group policy, preconfigured OCSP cert
and URL, SRV record in preconfigured domain once such is defined, etc, etc).

I.e. By a method that requires active administration.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 15 Jul 2010 23:15:45 -0400

Stefan,

Again, how does the Responder gets tied to certificates?

For example what elements in the OCSP cert and URL the client checks to
determine that this responder is authoritative for a certificate in
question?

Or, is it as simple as that the Responder is trusted to give you the
right answer whether it is authoritative for a certificate in question?

> Sent: Thursday, July 15, 2010 7:18 PM
[email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Jul 2010 09:36:09 +0200

According to section 3.2 and mainly 4.2.2.2  "Authorized Responders" of RFC
2560.

In this case:

   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:

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

/Stefan

---

From: Yogesh Mehta <[email-masked]>
Date: Fri, 16 Jul 2010 10:36:27 -0700

The clients trust the OCSP responder as documented:

"To be considered a valid OCSP signing certificate, the certificate must contain the OCSP Signing Enhanced Key Usage (EKU) object identifier (1.3.6.1.5.5.7.3.9). In addition, the certificate must form a valid chain from the OCSP signing certificate to a trusted root CA"

As long as the OCSP response signing certificate has the OCSP signing EKU and a valid chain up to a trusted root CA, it is trusted by the client to provide OCSP responses only for those certificates that have the responder URL implicitly present in the AIA extension or explicitly configured using Group Policy.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 1:18 PM
To: Yogesh Mehta; Miller, Timothy J.; Stefan Santesson; Matt Cooper; Peter Gutmann; [email-masked]
Cc: [email-masked]
Subject: RE: [pkix] Revising OCSP

Yogesh,

Your response seems to be focused how the clients locate the OCSP Responder.

What I am trying to find out how do clients come to trust an OCSP Responder in general as well as for a specific certificate.

This
by
must
Root
the
no-one

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 16 Jul 2010 15:19:53 -0400

>"To be considered a valid OCSP signing certificate, the certificate must
>chain from the OCSP signing certificate to a trusted root CA"

>As long as the OCSP response signing certificate has the OCSP signing
>EKU and a valid chain up to a trusted root CA, it is trusted by the
>client to provide OCSP responses only for those certificates that have
>the responder URL implicitly present in the AIA extension or explicitly
>configured using Group Policy.

Um, what?  DNS is not a reliable binding.  What stops an attacker from redirecting an OCSP client via DNS poisoning to an OCSP service under his control, and signing responses with an OCSP responder certificate legitimately acquired from a widely-trusted PKI (such as a commercial PKI vendor, or a national PKI)?  The client thinks it's talking to the OCSP service identified by the AIA, but isn't.

Under the documentation as worded, such OCSP responses would be treated as valid and authoritative.

-- Tim

---

From: "Andrews, Rick" <[email-masked]>
Date: Fri, 16 Jul 2010 13:05:24 -0700

Tim,

It should be difficult or impossible for an attacker to get an OCSP
responder certificate from a commercial or national PKI vendor that has
the OCSP signing EKU in it.

-Rick Andrews

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Miller,
> Timothy J.
> Sent: Friday, July 16, 2010 12:20 PM
> To: 'Yogesh Mehta'; Santosh Chokhani; Stefan Santesson; Matt Cooper;
Peter
> Gutmann; [email-masked]
> Cc: [email-masked]
> Um, what?  DNS is not a reliable binding.  What stops an attacker from
redirecting
> an OCSP client via DNS poisoning to an OCSP service under his control,
and
> signing responses with an OCSP responder certificate legitimately
acquired from a
> widely-trusted PKI (such as a commercial PKI vendor, or a national
PKI)?  The
> client thinks it's talking to the OCSP service identified by the AIA,
but isn't.
> 
> Under the documentation as worded, such OCSP responses would be
treated as
> valid and authoritative.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 16 Jul 2010 16:15:07 -0400

Yogesh,

Assuming you have listed all the checks, this is where the rub is.  It
seems that these checks are missing a delegation by the CA or explicit
decision by the RP to trust the public key as OCSP response signer.
Thus, this will not fall within the three models of 2560.  More
importantly, it can create a security weakness.

> Sent: Friday, July 16, 2010 1:36 PM
> To: Santosh Chokhani; Miller, Timothy J.; Stefan Santesson; Matt
> "To be considered a valid OCSP signing certificate, the certificate
> must contain the OCSP Signing Enhanced Key Usage (EKU) object
> identifier (1.3.6.1.5.5.7.3.9). In addition, the certificate must form
> a valid chain from the OCSP signing certificate to a trusted root CA"
> 
> > To: 'Stefan Santesson'; Santosh Chokhani; Matt Cooper; Peter
Gutmann;

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 16 Jul 2010 16:25:45 -0400

Stefan,

In this thread yesterday I stated "On the issue of a RP client being
configured to trust a responder, that is already covered by one of the
RFC 2560 models -- locally trusted OCSP Responder".  If the RP
configures to trust a public key as OCSP Signer, we are ok.

But, if this trust is based on an URL or DN, it is a security problem.
An OCSP Responder designated by CA other the one that issued a
certificate is not authoritative.

If the logic as simple as OCSP chains to any trust anchor and that makes
it authoritative for any certificate, that is a poor design and should
not be included in 2560 and should be cautioned against.

> Sent: Friday, July 16, 2010 3:36 AM
[email-masked]
> According to section 3.2 and mainly 4.2.2.2  "Authorized Responders"
of
> RFC
> >> Pick any suitable method (Microsoft group policy, preconfigured
OCSP
> >> cert
> >> and URL, SRV record in preconfigured domain once such is defined,
> etc,
> >> etc).
> >>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 16 Jul 2010 16:32:28 -0400

You should know better than that, Rick.  Any PKI can be coerced to issue anything at all, under the right legal pressure.  This was recently in the press re: SSL certificates issued under subpoena under false DNS names in order to allow TLS content inspection by a man-in-the-middle network tap device.  Hell, this is a *feature* of BlueCoat OS since 4.0, IIRC.

The OCSP EKU is not a binding either, any more than DNS is.

The problem with MS's implementation still stands, so far as I'm concerned, unless testing shows the current documentation to be wrong.  I've added specific tests to an existing test plan this week, but I don't have a schedule yet.

-- Tim

>From: Andrews, Rick [mailto:[email-masked]]
>Sent: Friday, July 16, 2010 3:05 PM
>To: Miller, Timothy J.; Yogesh Mehta; Santosh Chokhani; Stefan
>Santesson; Matt Cooper; Peter Gutmann; [email-masked]
>Cc: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 16 Jul 2010 16:34:51 -0400

Tim,

What do you mean by " The OCSP EKU is not a binding either"?

> Sent: Friday, July 16, 2010 4:32 PM
> To: 'Andrews, Rick'; Yogesh Mehta; Santosh Chokhani; Stefan Santesson;
> Matt Cooper; Peter Gutmann; [email-masked]
> Cc: [email-masked]
> You should know better than that, Rick.  Any PKI can be coerced to
> issue anything at all, under the right legal pressure.  This was
> recently in the press re: SSL certificates issued under subpoena under
> false DNS names in order to allow TLS content inspection by a man-in-
> the-middle network tap device.  Hell, this is a *feature* of BlueCoat
> OS since 4.0, IIRC.
> 
> The problem with MS's implementation still stands, so far as I'm
> concerned, unless testing shows the current documentation to be wrong.
> I've added specific tests to an existing test plan this week, but I
> don't have a schedule yet.
> 
> -- Tim
> 
Behalf

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 16 Jul 2010 16:43:58 -0400

Tim,

I think Rick has more persuasive argument, but not sufficient to sway me
for other reasons you cite.  OCSP EKU is checked by the RP and thus
cannot be spoofed like DNS.

The issue basically one of the Responder being authoritative for a given
certificate.

> Sent: Friday, July 16, 2010 4:38 PM
> To: Santosh Chokhani; Andrews, Rick; Yogesh Mehta; Stefan Santesson;
> Presence of the OCSP EKU doesn't bind the response to a RP trust
> anchor.  Rick's claim of 'trust us not to do that' is no better than
> Yogesh's presumption that DNS always gets you to the right endpoint.
> 
> -- Tim
> 
> 
> >Sent: Friday, July 16, 2010 3:35 PM
> >To: Miller, Timothy J.; Andrews, Rick; Yogesh Mehta; Stefan
Santesson;
> >> >responder certificate from a commercial or national PKI vendor
that
> >> has
> >> >> >client to provide OCSP responses only for those certificates
> that
> >> >have
> >> >> Um, what?  DNS is not a reliable binding.  What stops an
attacker
> >> from

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 17 Jul 2010 00:51:01 +0200

Santosh,

There are good and bad ways to bind to the OCSP responder of choice, no
doubt.

But even configuration based on DN and URL can be done with adequate
security if combined with a policy that requires the OCSP certificate to
support that DN/URL. Especially if this points to a locally configured
server.

Things are not bad just because you use a separate root or because you
identify OCSP by DN. There are many variables in the equation.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Jul 2010 07:36:01 -0400

Stefan,

Things are bad if any of the CA can be trusted to revoke certificate
issued by any of the other CAs.  This is not what PKIX should be
advocating or writing in the standards.

DNS and URL are insecure and that is why SSL is used to secure HTTP.

RFC 5280 Security Considerations sections says:
"   While X.509 mandates that names be unambiguous, there is a risk that
   two unrelated authorities will issue certificates and/or CRLs under
   the same issuer name.  As a means of reducing problems and security
   issues related to issuer name collisions, CA and CRL issuer names
   SHOULD be formed in a way that reduces the likelihood of name
   collisions.  Implementers should take into account the possible
   existence of multiple unrelated CAs and CRL issuers with the same
   name.  At a minimum, implementations validating CRLs MUST ensure that
   the certification path of a certificate and the CRL issuer
   certification path used to validate the certificate terminate at the
   same trust anchor."

I read the current 2560 stronger than this by providing crypto binding
to the authorization.  You want to not only bring in a security problem,
but make it worse than what 5280 says should be done as a minimum.

> Sent: Friday, July 16, 2010 6:51 PM
[email-masked]
> >>    response if the certificate required to validate the signature
on
> >>> For example what elements in the OCSP cert and URL the client
> checks
> >> to

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Jul 2010 18:23:34 +0200

Santosh,

If what you mean is that it is the responsibility of PKIX to change OCSP and
prevent local configuration which, if implemented badly, provides bad
security.... Then I have to disagree strongly.

RFC 2560 already allows local configuration of trust. A RP is free to trust
whoever they choose. We can't change that.

   "Systems or applications that rely on OCSP ..<snip>.. 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."

But we can provide good security guidance. If that is what you want, then I
fully agree.
 
/Stefan

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 19 Jul 2010 18:32:36 +0200

Miller, Timothy J. wrote:
> Any PKI can be coerced to issue anything at all, under the right legal pressure.
> This was recently in the press re: SSL certificates issued under
> subpoena under false DNS names in order to allow TLS content
> inspection by a man-in-the-middle network tap device.

If you're referring to this device 
http://www.wired.com/threatlevel/2010/03/packet-forensics/ , I think 
it's better to say that it's not a definitive demonstration subpoena are 
used to get false SSL certificates issued.

Nobody can say such a thing never happens, but it leaves annoying 
fingerprints for the agency that does it, so I don't believe it's that 
likely to happen.

It's much more likely to see the subpoena used to get the private key of 
the legitimate SSL server, the result being then really invisible for 
the user and requiring no cooperation of the CA.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Jul 2010 14:53:27 -0400

Stefan

Read Section 2.2 and 2.6 and 4.2.2.2 of 2560:

2.2 says:
"   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the
requester...."

This aligns with 4.2.2.2 that the RP need to trust the public key.

2.6 says:
"   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...."

Thus, unless the RP trust the OCSP Responder Signing Key directly, it
needs a delegated certificate from the cognizant CA.

4.2.2.2 says:
"They MUST reject the

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

This is clearly a certificate match and not simply a name match.

In summary, simply validating a certificate to a root and verifying that
the certificate contains OCSP Signing EKU does not meet any of the three
models.  Furthermore, it is insecure and provides room for mischief.  I
hope PKIX community does not dilute 2560 trust framework which seems to
be sound.

> Sent: Monday, July 19, 2010 12:24 PM
[email-masked]
> >> There are good and bad ways to bind to the OCSP responder of
choice,
> > no
> >> security if combined with a policy that requires the OCSP
> certificate
> >> to
> >>>>>> On 10-07-15 9:11 PM, "Santosh Chokhani"
<[email-masked]>
> >>>>> wrote:

---

From: Yogesh Mehta <[email-masked]>
Date: Mon, 19 Jul 2010 12:03:32 -0700

With respect to the security weakness based on DNS spoofing threat that Tim pointed out, a deployment can mitigate the threat through appropriate configuration and trust management. While Windows does not support a configurable CTL for OCSP signers, administrators can either trust only a limited set of root CAs or even for the root CAs they trust, they can restrict the scope of what each root is trusted for. Windows allows restricting EKUs on root certificates through policy. For example, an administrator can configure their trust such that OCSP signing EKU is disabled for all roots except the root CAs that have issued certificates to their locally configured OCSP responders.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, July 16, 2010 1:15 PM
To: Yogesh Mehta; Miller, Timothy J.; Stefan Santesson; Matt Cooper; Peter Gutmann; [email-masked]
Cc: [email-masked]
Subject: RE: [pkix] Revising OCSP

Yogesh,

Assuming you have listed all the checks, this is where the rub is.  It seems that these checks are missing a delegation by the CA or explicit decision by the RP to trust the public key as OCSP response signer.
Thus, this will not fall within the three models of 2560.  More importantly, it can create a security weakness.

Gutmann;

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 19 Jul 2010 15:09:31 -0400

Yogesh,

This is all fine.  There are some problems with it.

First, it is all outside the scope of RFC 2560.  The Windows certificate
store properties are not part of any of the PKIX standards.

Second, this still permits any CA to revoke certificate issued by any
other CA.

> Sent: Monday, July 19, 2010 3:04 PM
> With respect to the security weakness based on DNS spoofing threat
that
> Tim pointed out, a deployment can mitigate the threat through
> appropriate configuration and trust management. While Windows does not
> support a configurable CTL for OCSP signers, administrators can either
> trust only a limited set of root CAs or even for the root CAs they
> trust, they can restrict the scope of what each root is trusted for.
> Windows allows restricting EKUs on root certificates through policy.
> For example, an administrator can configure their trust such that OCSP
> signing EKU is disabled for all roots except the root CAs that have
> issued certificates to their locally configured OCSP responders.
> 
> > > >trusted to provide responses for any certificate. The RP still
> need
> > to
> > > signing certificate to its root CA, will be sent by the OCSP
server
> > as
> > > I queried colleagues who've worked with the system, they don't
know
> > > on this thread has mentioned specific testing of the MS OCSP
client

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 16 Jul 2010 16:37:44 -0400

Presence of the OCSP EKU doesn't bind the response to a RP trust anchor.  Rick's claim of 'trust us not to do that' is no better than Yogesh's presumption that DNS always gets you to the right endpoint.

-- Tim

>To: Miller, Timothy J.; Andrews, Rick; Yogesh Mehta; Stefan Santesson;

---

From: Yogesh Mehta <[email-masked]>
Date: Mon, 19 Jul 2010 17:44:48 -0700

Thanks for the feedback, Rob. We review the root program policy from time to time and will look into this. 

For further questions specific to Microsoft implementation and policy, please share them off-list.

Thank you,
Yogesh

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Monday, July 19, 2010 1:30 PM
To: [email-masked]; Yogesh Mehta
Cc: Santosh Chokhani; Miller, Timothy J.; Stefan Santesson; Matt Cooper; Peter Gutmann; [email-masked]
Subject: Re: [pkix] Revising OCSP

Yogesh,

Leaving aside what an administrator may configure, let's look at the default configuration.

63 (~20%) of the Root Certificates in Microsoft's Root Certificate Program currently have the "OCSP Signing" trust purpose enabled by default.

Is there any reason why you couldn't remove this default trust purpose from these Root Certificates via the Windows Automatic Root Update facility (for Windows Vista / 2008 / 7, at least) ?

On Monday 19 July 2010 20:03:32 Yogesh Mehta wrote:
> that Tim pointed out, a deployment can mitigate the threat through 
<snip>

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Jul 2010 03:33:45 +0200

Certificate in this sentence refers to the certificate being checked for
revocation.

> This is clearly a certificate match and not simply a name match.

You are twisting the words there Santosh.
Since the OCSP response is signed then of-course the RP need to trust the
public key of the OCSP responder certificate.

The question is how the RP come to trust that public key. That is totally up
to local configuration.

What kind of restrictions do you want to impose?

/Stefan

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 20 Jul 2010 03:46:52 -0700

Stefan,
 
I think the local configuration must consist of:
 
- The specific public key (or cert) of the responder (OR) The specific public key (or cert) of the *direct* issuer of the responder certs.  (i.e. This is **not** any root that leads through any number of CAs to any responder)
 
(***AND***)
 
- The specific list of CAs for which the specific locally configured responder is trusted to provide status.

The second option ("The specific public key (or cert) of the *direct* issuer of the responder certs") is I think no less secure than configuring a specific responder key (or cert) if implemented properly. I would see this implemented as an offline CA. This would provide the ability to re-key your responder(s) without reconfiguring clients. The important thing to recognize here is that this CA must be the DIRECT issuer of the responder certs and I would think the CA should be dedicated to that purpose in this scenario.
 
Also note the (***AND***) above is just as important as what precedes it. Best I can tell, the Microsoft implementation does not offer that part in any capacity except "Trust to provide revocation status for every CA everywhere" which is apparently the default when I install any new TA.
 
-Matt

From: Stefan Santesson [mailto:[email-masked]]
Sent: Mon 7/19/2010 9:33 PM
To: Santosh Chokhani; Matt Cooper; Peter Gutmann; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 20 Jul 2010 07:45:51 -0400

Stefan,

The RFC is saying that the 
"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:

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

This means that the RP system is configured with an OCSP certificate as
explicitly trusted for OCSP Signing and you match the certificate (not
just a name).

You need to read the lead in sentence along with the three choices.

> Sent: Monday, July 19, 2010 9:34 PM
[email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Jul 2010 17:18:05 +0200

> You need to read the lead in sentence along with the three choices.

No, it means that the RP must have a configuration that causes that OCSP
certificate to be trusted in this way.

There are more ways to achieve this than to configure the certificate (or
public key) directly.

/Stefan

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 20 Jul 2010 17:28:29 -0400

Matt,

I understand that this thread began with a suggestion to include 
Microsoft's trust model in the update to RFC 2560, but I think the 
working group has already made it quite clear that it is against that.  
So, at this point my only interest is in what the update to RFC 2560 
should say rather than what Microsoft has done or should do in the future.

I think we need to be careful about being overly prescriptive about how 
local configuration is performed on an OCSP client.  Although, it would 
certainly be reasonable to include a statement about this in the 
Security Considerations section.  Here is a paragraph that I found in 
the Security Considerations section of RFC 5280:

    The certification path validation algorithm depends on the certain
    knowledge of the public keys (and other information) about one or
    more trusted CAs.  The decision to trust a CA is an important
    decision as it ultimately determines the trust afforded a
    certificate.  The authenticated distribution of trusted CA public
    keys (usually in the form of a "self-signed" certificate) is a
    security critical out-of-band process that is beyond the scope of
    this specification.

Note that neither of the constraints that you suggest for configuration 
of locally trusted OCSP responders are imposed on path validation trust 
anchors.  The Trust Anchor Management Protocol (draft-ietf-pkix-tamp-08) 
begins with a locally configured Apex Trust Anchor, but there is no 
requirement that a path validation trust anchor be either the Apex Trust 
Anchor itself or that it be signed directly by the Apex Trust Anchor.  
Similarly, most clients do not permit a set of constraints (e.g., 
initial-permitted-subtrees, initial-explicit-policy, 
user-initial-policy-set) to be associated with a trust anchor that must 
be provided as input to the path validation algorithm whenever that 
trust anchor is used.

I think the underlying problem is that the "local configuration" trust 
model is being overused.  Most likely the problem is that issuers that 
have a PKI hierarchy and a single OCSP responder find it difficult to 
implement the CA delegated model.  So the issuers create a situation in 
which client can only accept responses from their OCSP servers using 
local configuration.

Ideally, whenever a OCSP responder is set up by a CA for use by any 
client that is attempting to validate one of the certificate that CA 
issued, the responder would operate as an Integrated or Designated OCSP 
responder.  If this were the case, local configuration would only need 
to be used to accept responses from a locally operated OCSP responder.  
OCSP clients would in most cases be configured to use that local OCSP 
responder to obtain revocation status information for all certificates 
(e.g., as in Appendix D.3 in draft-cooper-pkix-rfc2560bis-00).

Dave

On 07/20/2010 06:46 AM, Matt Cooper wrote:
> - The specific public key (or cert) of the responder (OR) The specific 
> public key (or cert) of the *direct* issuer of the responder certs.  
> (i.e. This is **not** any root that leads through any number of CAs to 
> any responder)
>
> (***AND***)
>
> The second option ("The specific public key (or cert) of the *direct* 
> issuer of the responder certs") is I think no less secure than 
> configuring a specific responder key (or cert) if implemented 
> properly. I would see this implemented as an offline CA. This would 
> provide the ability to re-key your responder(s) without reconfiguring 
> clients. The important thing to recognize here is that this CA must be 
> the DIRECT issuer of the responder certs and I would think the CA 
> should be dedicated to that purpose in this scenario.
>
> Also note the (***AND***) above is just as important as what precedes 
> it. Best I can tell, the Microsoft implementation does not offer that 
> part in any capacity except "Trust to provide revocation status for 
> every CA everywhere" which is apparently the default when I install 
> any new TA.
>
> -Matt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 21 Jul 2010 07:24:03 -0400

Stefan,

Your interpretation is incorrect in light of how the three models in
4.2.2.2 of the 2560 tie to the three options in 2.2.

Requester/RP need to directly trust the public key of the responder.  If
the trust could come via 5280, there would not be a need to represent
the three models since under 5280 all three would be eventually trusted.

RFC is saying that to trust an OCSP response, you either trust the
responder key (and not by path validation), or the CA key used to sign
the certificate is used to sign the response, or CA key used to issue
certificate is used to issue a delegated certificate.

> Sent: Tuesday, July 20, 2010 11:18 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> >> Certificate in this sentence refers to the certificate being
checked
> >> for
> >> Since the OCSP response is signed then of-course the RP need to
> trust
> >> the

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Jul 2010 11:55:49 +0200

Santosh,

I don't think we can get any further on this more than agree to disagree.

I think it would be more constructive if you suggest text that you want to
change or add and then we can take it from there.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 22 Jul 2010 14:39:27 -0400

Stefan

I will recommend changes if they come to mind.

> Sent: Thursday, July 22, 2010 5:56 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> I think it would be more constructive if you suggest text that you
want
> >>> This means that the RP system is configured with an OCSP
> certificate
> >> as
> >> There are more ways to achieve this than to configure the
> certificate
> >> (or
> >> public key) directly.
> >>
> >> /Stefan
> >>
> >>
> >>>
> >>>>>    1. Matches a local configuration of OCSP signing authority
for

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 24 Jul 2010 15:53:36 +0200

Matt,

I don¹t question that what you suggest is good security practice in many
common situations.
I question what a standard should mandate with respect to relaying party
configuration practice.

So I ask you. Would you like to write into the standard what you suggest.
I.e. that a compliant relying party MUST configure trust in a specific OCSP
certificate or public key.

If no, then what do you suggest?
If yes, then define ³configure²/²configuration².

For example, If the RP system is trusting a local PKI only configured to
trust local root certificates and the RP is configured any OCSP responder
with the name ³Foo² that can present a valid certificate that is trusted
under the local PKI root. Then is this an illegal implementation of OCSP?

Why? It is perfectly secure and reasonable within the local context of use.
Yet it configures trust by name and not by key/cert.

/Stefan

On 10-07-20 12:46 PM, "Matt Cooper" <[email-masked]> wrote:

> - The specific public key (or cert) of the responder (OR) The specific public
> key (or cert) of the *direct* issuer of the responder certs.  (i.e. This is
> **not** any root that leads through any number of CAs to any responder)
>  
> (***AND***)
>  
> The second option ("The specific public key (or cert) of the *direct* issuer
> of the responder certs") is I think no less secure than configuring a specific
> responder key (or cert) if implemented properly. I would see this implemented
> as an offline CA. This would provide the ability to re-key your responder(s)
> without reconfiguring clients. The important thing to recognize here is that
> this CA must be the DIRECT issuer of the responder certs and I would think the
> CA should be dedicated to that purpose in this scenario.
>  
> Also note the (***AND***) above is just as important as what precedes it. Best
> I can tell, the Microsoft implementation does not offer that part in any
> capacity except "Trust to provide revocation status for every CA everywhere"
> which is apparently the default when I install any new TA.
>  
> -Matt
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 25 Jul 2010 21:15:34 -0400

Stefan,

Standard already requires the trust in the certificate (not a name or
URL) for the local configuration model.

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Saturday, July 24, 2010 9:54 AM
To: Matt Cooper; Santosh Chokhani; Peter Gutmann; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Revising OCSP

Matt,

I don't question that what you suggest is good security practice in many
common situations.
I question what a standard should mandate with respect to relaying party
configuration practice.

So I ask you. Would you like to write into the standard what you
suggest. I.e. that a compliant relying party MUST configure trust in a
specific OCSP certificate or public key.

If no, then what do you suggest?
If yes, then define "configure"/"configuration".

For example, If the RP system is trusting a local PKI only configured to
trust local root certificates and the RP is configured any OCSP
responder with the name "Foo" that can present a valid certificate that
is trusted under the local PKI root. Then is this an illegal
implementation of OCSP?

Why? It is perfectly secure and reasonable within the local context of
use.
Yet it configures trust by name and not by key/cert.

/Stefan

Stefan,

(***AND***)

- The specific list of CAs for which the specific locally configured
responder is trusted to provide status.

The second option ("The specific public key (or cert) of the *direct*
issuer of the responder certs") is I think no less secure than
configuring a specific responder key (or cert) if implemented properly.
I would see this implemented as an offline CA. This would provide the
ability to re-key your responder(s) without reconfiguring clients. The
important thing to recognize here is that this CA must be the DIRECT
issuer of the responder certs and I would think the CA should be
dedicated to that purpose in this scenario.

Also note the (***AND***) above is just as important as what precedes
it. Best I can tell, the Microsoft implementation does not offer that
part in any capacity except "Trust to provide revocation status for
every CA everywhere" which is apparently the default when I install any
new TA.

-Matt

You are twisting the words there Santosh.
Since the OCSP response is signed then of-course the RP need to trust
the
public key of the OCSP responder certificate.

The question is how the RP come to trust that public key. That is
totally up
to local configuration.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Jul 2010 09:47:29 +0200

On 10-07-26 3:15 AM, "Santosh Chokhani" <[email-masked]> wrote:

> Stefan,
>  
> Standard already requires the trust in the certificate (not a name or URL) for
> the local configuration model.
>  

That I have never challenged.

However, there are many valid ways for a RP to come to the conclusion that
it trusts that certificate.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 26 Jul 2010 10:39:09 -0400

Other mechanisms that are vulnerable should not be part of the standard.

> Sent: Monday, July 26, 2010 3:47 AM
[email-masked]