Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Oct 2012 13:31:45 +0200

Why do you need this at all?

I don't see that this extension is required in order to split OCSP
responding for chunks of certs.
You can point the client to the correct responder using information in the
cert today.
The responder can determine if the requested vert is within it's handled
portion of certs.

Given that you trust the OCSP responder and the responder is honest, you
will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder
responds outside of it's authority, but if the OCSP responder is dishonest,
then you are screwed in any case.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Friday, September 28, 2012 4:17 PM
To:  "[email-masked]" <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

> Denis,
>  
> I find the document in general acceptable.  It definitely fills a hole.
>  
> That said, it is effective both in general and against MITM attack if the CA
> recognizes that the absence of the critical extension you designed in the OCSP
> certificate means that the Responder is authoritative for all certificates as
> long as the rest of the requirements in RFC 2560 are met.
>  
> Note that absence of IDP means that the CRL is full and complete.  We do not
> have a similar statement in 2560 and this extension is fully effective only if
> such is the case, i.e., by omitting this extension, the CA implies that the
> Responder is authoritative for all certificates signed using that CA key.
>  
> We either need to impose this requirement, which while new, most
> implementations I know impose or discuss it in the Security Considerations
> section.
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, September 25, 2012 11:12 AM
> To: pkix
> Subject: [pkix] New Version Notification for
> draft-pinkas-2560bis-ocsp-locationcheck-00.txt
>  
> To the list, 
> 
> The last comment from Santosh, triggered me to write a new draft proposal
> directly related to 2560bis.
> 
> This proposal allows to split the workload of an OCSP service from a CA
> between several OCSP Responders.
> This may be desirable for PKIs issuing a large number of certificates (e.g.
> several hundred of thousands).
> 
> Denis 
> 
> ==============================================================================
> ================ 
> 
> A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
> has been successfully submitted by Denis Pinkas and posted to the
> IETF repository.
> 
> Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
> Revision:                 00
> Title:                 OCSP LocationCheck certificate extension Update to OCSP
>                   < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
> Creation date:                  2012-09-25
> WG ID:                                   Individual Submission
> Number of pages: 6
> URL:             
> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00
> .txt 
> <http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-0
> 0.txt> 
> Status:          
> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
> <http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck>
> Htmlized:        
> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00
> <http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00>
> 
> 
> Abstract: 
> 
>   RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
>   Responders for being responsible to provide the revocation status
>   of the certificates they issue under a given CA key.
> 
>   This document introduces a new feature that allows allows CAs to
>   split the workload between different sets of OCSP Responders in a
>   way that is analogous to the way CRLs can be split between
>   different sets of CRL issuers (using the cRLDistributionPoints
>   extension).
> 
>   This new feature allows a CA to designate one or more OCSP
>   Responders for being responsible to provide the revocation status
>   for a subset of the certificates they issue under a given CA key.
> 
>   This document defines a critical extension that may only be placed
>   in an OCSP certificate and the way it shall be processed by OCSP
>   clients.
> 
> The IETF Secretariat
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Denis Pinkas Bull <[email-masked]>
Date: Thu, 11 Oct 2012 07:31:30 +0200

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 
issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 
100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP 
Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 
issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 
100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP 
Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate 
to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed 
to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known 
that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect 
revocation status results.

Denis

  Santesson a écrit :
> You can point the client to the correct responder using information in 
> the cert today.
> The responder can determine if the requested vert is within it's 
> handled portion of certs.
>
> Given that you trust the OCSP responder and the responder is honest, 
> you will receive an appropriate response.
>
> So, why the extension?
>
> responds outside of it's authority, but if the OCSP responder is 
> dishonest, then you are screwed in any case.
>
> /Stefan
>
>
> From: Santosh Chokhani <[email-masked] 
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, pkix 
> <[email-masked] <mailto:[email-masked]>>
>     That said, it is effective both in general and against MITM attack
>     if the CA recognizes that the absence of the critical extension
>     you designed in the OCSP certificate means that the Responder is
>     authoritative for all certificates as long as the rest of the
>     requirements in RFC 2560 are met.
>
>     Note that absence of IDP means that the CRL is full and complete. 
>     We do not have a similar statement in 2560 and this extension is
>     fully effective only if such is the case, i.e., by omitting this
>     extension, the CA implies that the Responder is authoritative for
>     all certificates signed using that CA key.
>
>     implementations I know impose or discuss it in the Security
>     Considerations section.
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     *Sent:* Tuesday, September 25, 2012 11:12 AM
>     *To:* pkix
>     *Subject:* [pkix] New Version Notification for
>     The last comment from Santosh, triggered me to write a new draft
>     proposal directly related to 2560bis.
>
>     This proposal allows to split the workload of an OCSP service from
>     a CA between several OCSP Responders.
>     This may be desirable for PKIs issuing a large number of
>     certificates (e.g. several hundred of thousands).
>
>     Denis
>
>     ==============================================================================================
>
>
>     http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
>     Status:
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pkix 
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 07:40:25 +0200

Sorry, Still don't get it.

In your example, the client receives a response that the responder is not
authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan

From:  Denis Pinkas Bull <[email-masked]>
Date:  Thursday, October 11, 2012 7:31 AM
To:  Stefan Santesson <[email-masked]>
Cc:  Santosh Chokhani <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

>  OCSP Responder 1 receives delegation from CA x for the first 100.000 issued
> certificates.
>  The first 100.000 issued certificates contain url1 to locate OCSP Responder
> 1.
>  
>  OCSP Responder 2 receives delegation from CA x for the next 100.000 issued
> certificates.
>  OCSP Responder 2 has only access to the revocation status of the next 100.000
> issued certificates.
>  The next 100.000 issued certificates contains url2 to locate OCSP Responder
> 2.
>  
>  A Relying Party (RP) uses url1 that is present in the target certificate to
> query OCSP Responder 1.
>  However, there is a man-in-the-middle-attack and this request in routed to
> OCSP Responder 2.
>  If the man-in-the-middle attack were not done, the RP would have known that
> the certificate 
>> I don't see that this extension is required in order to split OCSP responding
>> for chunks of certs.
>>  
>> Given that you trust the OCSP responder and the responder is honest, you will
>> receive an appropriate response.
>>  
>> 
>>  
>>  
>> So, why the extension?
>>  
>> 
>>  
>>  
>>> recognizes that the absence of the critical extension you designed in the
>>> OCSP certificate means that the Responder is authoritative for all
>>> certificates as long as the rest of the requirements in RFC 2560 are met.
>>>  
>>>  
>>>  
>>> have a similar statement in 2560 and this extension is fully effective only
>>> if such is the case, i.e., by omitting this extension, the CA implies that
>>> the Responder is authoritative for all certificates signed using that CA
>>> key.
>>>  
>>>  
>>>  
>>> <http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck
>>> -00.txt> 
>>>  Status:

---

From: Denis Pinkas Bull <[email-masked]>
Date: Thu, 11 Oct 2012 07:53:04 +0200

Stefan,

As fas as I know, there are only three major status: "good", "revoked" 
or "unknown".

Error messages are:

    -- malformedRequest,
    -- internalError,
    -- tryLater,
    -- sigRequired,
    -- unauthorized.

There is no response like: "the responder is not authorised to provide 
information about the cert".
In the example, the RP gets "unknown" (witha correct signature from the 
OCSP responder),
whereas it would have received either "good" or "revoked", if there had 
been no attack.

Denis

> In your example, the client receives a response that the responder is 
> not authorised to provide information about the cert.
> From: Denis Pinkas Bull <[email-masked] 
> <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: Santosh Chokhani <[email-masked] 
> <mailto:[email-masked]>>, pkix <[email-masked] 
> <mailto:[email-masked]>>
>     OCSP Responder 1 receives delegation from CA x for the first
>     OCSP Responder 1 has only access to the revocation status of the
>     first 100.000 issued certificates.
>     OCSP Responder 2 receives delegation from CA x for the next
>     OCSP Responder 2 has only access to the revocation status of the
>     next 100.000 issued certificates.
>     A Relying Party (RP) uses url1 that is present in the target
>     certificate to query OCSP Responder 1.
>     However, there is a man-in-the-middle-attack and this request in
>     routed to OCSP Responder 2.
>     If the man-in-the-middle attack were not done, the RP would have
>     known that the certificate
>     Without the proposed extension, the protocol would provide
>     incorrect revocation status results.
>
>     Denis
>
>
>
>      Santesson a écrit :
>>     I don't see that this extension is required in order to split
>>     OCSP responding for chunks of certs.
>>     You can point the client to the correct responder using
>>     information in the cert today.
>>     Given that you trust the OCSP responder and the responder is
>>     honest, you will receive an appropriate response.
>>
>>     So, why the extension?
>>
>>     I can only imagine the extension being useful to detect if a
>>     responder responds outside of it's authority, but if the OCSP
>>     responder is dishonest, then you are screwed in any case.
>>
>>     /Stefan
>>
>>
>>         That said, it is effective both in general and against MITM
>>         attack if the CA recognizes that the absence of the critical
>>         extension you designed in the OCSP certificate means that the
>>         Responder is authoritative for all certificates as long as
>>         the rest of the requirements in RFC 2560 are met.
>>
>>         Note that absence of IDP means that the CRL is full and
>>         complete.  We do not have a similar statement in 2560 and
>>         this extension is fully effective only if such is the case,
>>         i.e., by omitting this extension, the CA implies that the
>>         We either need to impose this requirement, which while new,
>>         most implementations I know impose or discuss it in the
>>         Security Considerations section.
>>
>>         The last comment from Santosh, triggered me to write a new
>>         draft proposal directly related to 2560bis.
>>
>>         This proposal allows to split the workload of an OCSP service
>>         from a CA between several OCSP Responders.
>>         A new version of I-D,
>>                           <
>>         draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
>>         _______________________________________________ pkix mailing
>>         list [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 10:24:05 +0200

The "unauthorized" response seems suitable to me.

"The response "unauthorized" is returned in cases where the client is not
authorized to make this query to this server or the server is not capable of
responding authoritatively (cf. [RFC5019], Section 2.2.3)"

/Stefan

Date:  Thursday, October 11, 2012 7:53 AM

>     
>  
> Stefan,
>  
>  As fas as I know, there are only three major status: "good", "revoked" or
> "unknown".
>  
>  Error messages are:
>  
>     -- malformedRequest,
>     -- internalError,
>     -- tryLater,
>     -- sigRequired,
>     -- unauthorized.
>  
>  In the example, the RP gets "unknown" (with a correct signature from the OCSP
> responder), 
>  whereas it would have received either  "good" or "revoked", if there had been
> no attack.
>  
>  Denis
>  
>  
>  
>>  
>>>>> That said, it is effective both in general and against MITM attack if the
>>>>> CA recognizes that the absence of the critical extension you designed in
>>>>> the OCSP certificate means that the Responder is authoritative for all
>>>>> Note that absence of IDP means that the CRL is full and complete.  We do
>>>>> not have a similar statement in 2560 and this extension is fully effective
>>>>> only if such is the case, i.e., by omitting this extension, the CA implies
>>>>> that the Responder is authoritative for all certificates signed using that
>>>>> CA key.
>>>>>  
>>>>>  
>>>>>  
>>>>>  This may be desirable for PKIs issuing a large number of certificates
>>>>> (e.g. several hundred of thousands).
>>>>>  
>>>>>  Denis 
>>>>>  
>>>>>  
>>>>> <http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationche
>>>>> ck-00.txt> 
>>>>>  Status:

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 14:25:39 +0200

Stefan,

RFC 2560 states:

  "In case of errors, the OCSP Responder may return an error message.
These messages are not signed".

So an "unauthorized" response is not signed.

The text from RFC 2560 states:

The response "unauthorized" is returned in cases where the client is
not authorized to make this query to this server.

The text from RFC 5019 states the following:

As long as the OCSP infrastructure has authoritative records for a

particular certificate, an OCSPResponseStatus of "successful" will be

returned.When access to authoritative records for a particular

certificate is not available, the responder MUST return an

OCSPResponseStatus of "unauthorized".As such, this profile extends

the RFC 2560 [OCSP] definition of "unauthorized" as follows:

The response "unauthorized" is returned in cases where the client

is not authorized to make this query to this server or the server

is not capable of responding authoritatively.

In the absence of the proposed extension, RFC 5019 could not do better.

With the proposed extension, it is possible to do better and to get a 
signed "unknown" status in a signed response
rather than an "unauthorized" error in an unsigned response, that is 
harder to interpret and subject to attacks:

  - was there a substitution attack, since this may not be a response 
from the authorized responder ?
  - am I using a wrong URL, since I am not sure this response comes from 
the right URL ?
  - am I missing an authorization to get the status ?

Denis

> "The response "unauthorized" is returned in cases where the client is 
> not authorized to make this query to this server or the server is not 
> capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)"
>
> /Stefan
>
>
>
>     As fas as I know, there are only three major status: "good",
>     "revoked" or "unknown".
>
>     Error messages are:
>
>        -- malformedRequest,
>        -- internalError,
>        -- tryLater,
>        -- sigRequired,
>        -- unauthorized.
>
>     There is no response like: "the responder is not authorised to
>     provide information about the cert".
>     In the example, the RP gets "unknown" (witha correct signature
>     from the OCSP responder),
>     whereas it would have received either "good" or "revoked", if
>     there had been no attack.
>
>     Denis
>
>>     In your example, the client receives a response that the
>>     responder is not authorised to provide information about the cert.
>>         OCSP Responder 1 has only access to the revocation status of
>>         the first 100.000 issued certificates.
>>         The first 100.000 issued certificates contain url1 to locate
>>         OCSP Responder 1.
>>
>>         OCSP Responder 2 has only access to the revocation status of
>>         the next 100.000 issued certificates.
>>         The next 100.000 issued certificates contains url2 to locate
>>         OCSP Responder 2.
>>
>>         However, there is a man-in-the-middle-attack and this request
>>         in routed to OCSP Responder 2.
>>         If the man-in-the-middle attack were not done, the RP would
>>         have known that the certificate
>>>         I don't see that this extension is required in order to
>>>         split OCSP responding for chunks of certs.
>>>         The responder can determine if the requested vert is within
>>>         it's handled portion of certs.
>>>
>>>         responder responds outside of it's authority, but if the
>>>         OCSP responder is dishonest, then you are screwed in any case.
>>>
>>>         /Stefan
>>>
>>>
>>>             That said, it is effective both in general and against
>>>             MITM attack if the CA recognizes that the absence of the
>>>             critical extension you designed in the OCSP certificate
>>>             means that the Responder is authoritative for all
>>>             this extension is fully effective only if such is the
>>>             case, i.e., by omitting this extension, the CA implies
>>>             that the Responder is authoritative for all certificates
>>>             signed using that CA key.
>>>
>>>             We either need to impose this requirement, which while
>>>             new, most implementations I know impose or discuss it in
>>>             the Security Considerations section.
>>>
>>>             The last comment from Santosh, triggered me to write a
>>>             new draft proposal directly related to 2560bis.
>>>
>>>             This proposal allows to split the workload of an OCSP
>>>             service from a CA between several OCSP Responders.
>>>             _______________________________________________ pkix
>>>             mailing list [email-masked] <mailto:[email-masked]>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 15:07:02 +0200

I still think the gain obtained by your proposal is far less than the pain
of introducing a new critical extension that needs client support.

I still can't see an attacker achieving anything beyond a DoS and I can't
see this scaled to a DDoS attack.
Signed error or not.

/Stefan

From:  Denis Pinkas <[email-masked]>
Date:  Thursday, October 11, 2012 2:25 PM
To:  Stefan Santesson <[email-masked]>
Cc:  Santosh Chokhani <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

>    returned.  When access to authoritative records for a particular
>  
>    OCSPResponseStatus of "unauthorized".  As such, this profile extends
>  
>  With the proposed extension, it is possible to do better and to get a signed
> "unknown" status in a signed response
>  rather than an "unauthorized" error in an unsigned response, that is harder
> to interpret and subject to attacks:
>  
>   - was there a substitution attack, since this may not be a response from the
> authorized responder ?
>   - am I using a wrong URL, since I am not sure this response comes from the
> right URL ? 
>>>  In the example, the RP gets "unknown"  (with a correct signature from the
>>> OCSP responder),
>>>>>>> That said, it is effective both in general and against MITM attack if
>>>>>>> the CA recognizes that the absence of the critical extension you
>>>>>>> designed in the OCSP certificate means that the Responder is
>>>>>>> not have a similar statement in 2560 and this extension is fully
>>>>>>> effective only if such is the case, i.e., by omitting this extension,
>>>>>>> the CA implies that the Responder is authoritative for all certificates
>>>>>>> <http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationc
>>>>>>> heck-00.txt>
>>>>>>>  Status:   
>>>>>>> <http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
>>>>>>> > 
>>>>>>>  Htmlized:

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 11 Oct 2012 10:26:27 -0400

Stefan,

It is possible that a Responder will assert good (e.g., for pre-signed responses) since RFC 2560 does not address if the CA splits the responsibility among multiple responders.  In that case, MITM can get and play a response of "good" from a legitimate Responder.

CAs and Responders who implement this extension are protected.  For further discussion, see my comment in this thread that Denis has not addressed.

It is akin to IDP for partitioned CRL, but my concern is different than yours.  I am concerned that unless the assumptions made by this extension are adhered to by the CA and the Responders, there is less of a benefit.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, October 11, 2012 9:07 AM
To: Denis Pinkas
Cc: Santosh Chokhani; pkix
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

I still think the gain obtained by your proposal is far less than the pain of introducing a new critical extension that needs client support.

I still can't see an attacker achieving anything beyond a DoS and I can't see this scaled to a DDoS attack.
Signed error or not.

/Stefan

From: Denis Pinkas <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 11, 2012 2:25 PM
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>
Cc: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

RFC 2560 states:

With the proposed extension, it is possible to do better and to get a signed "unknown" status in a signed response
rather than an "unauthorized" error in an unsigned response, that is harder to interpret and subject to attacks:

 - was there a substitution attack, since this may not be a response from the authorized responder ?
 - am I using a wrong URL, since I am not sure this response comes from the right URL ?
 - am I missing an authorization to get the status ?

Denis

"The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)"

/Stefan

From: Denis Pinkas Bull <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>
Cc: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

In your example, the client receives a response that the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan

From: Denis Pinkas Bull <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>
Cc: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis

 Santesson a écrit :

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 28, 2012 4:17 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
Revision:                 00
Title:                 OCSP LocationCheck certificate extension Update to OCSP
                  < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:                  2012-09-25
WG ID:                                   Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00

Abstract:

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 16:47:00 +0200

Santosh,

Reading your message below reminded me that I forgot to respond to your 
comment. Sorry, about that.
In order to address your comment, I propose the following:

Change :

4.5.X OCSP LocationCheck extension

    This single extension MAY only be placed in an OCSP certificate.

into:

4.5.X OCSP LocationCheck extension

    This single extension MAY only be placed in an OCSP certificate.

    By omitting this extension, the CA implies that any designated OCSP 
Responder
    is authoritative for all certificates signed using the key used to 
sign the OCSP
    certificate.

Denis

> Stefan,
>
> It is possible that a Responder will assert good (e.g., for pre-signed 
> responses) since RFC 2560 does not address if the CA splits the 
> responsibility among multiple responders.  In that case, MITM can get 
> and play a response of "good" from a legitimate Responder.
>
> CAs and Responders who implement this extension are protected. For 
> further discussion, see my comment in this thread that Denis has not 
> addressed.
>
> It is akin to IDP for partitioned CRL, but my concern is different 
> than yours.  I am concerned that unless the assumptions made by this 
> extension are adhered to by the CA and the Responders, there is less 
> of a benefit.
>
> *From:*Stefan Santesson [mailto:[email-masked]]
> *Sent:* Thursday, October 11, 2012 9:07 AM
> *To:* Denis Pinkas
> *Cc:* Santosh Chokhani; pkix
> *Subject:* Re: [pkix] New Version Notification for 
> I still think the gain obtained by your proposal is far less than the 
> pain of introducing a new critical extension that needs client support.
>
> *From: *Denis Pinkas <[email-masked] 
> *Date: *Thursday, October 11, 2012 2:25 PM
> *To: *Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> *Cc: *Santosh Chokhani <[email-masked] 
> *Subject: *Re: [pkix] New Version Notification for 
>     With the proposed extension, it is possible to do better and to
>     get a signed "unknown" status in a signed response
>     rather than an "unauthorized" error in an unsigned response, that
>     is harder to interpret and subject to attacks:
>
>         "The response "unauthorized" is returned in cases where the
>         client is not authorized to make this query to this server or
>         the server is not capable of responding authoritatively (cf.
>         [RFC5019], Section 2.2.3)"
>
>         /Stefan
>
>         *From: *Denis Pinkas Bull <[email-masked]
>         *Date: *Thursday, October 11, 2012 7:53 AM
>         *To: *Stefan Santesson <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc: *Santosh Chokhani <[email-masked]
>         *Subject: *Re: [pkix] New Version Notification for
>             There is no response like: "the responder is not
>             authorised to provide information about the cert".
>                 In your example, the client receives a response that
>                 the responder is not authorised to provide information
>                 about the cert.
>
>                 *From: *Denis Pinkas Bull <[email-masked]
>                 *Date: *Thursday, October 11, 2012 7:31 AM
>                 *To: *Stefan Santesson <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc: *Santosh Chokhani <[email-masked]
>                 *Subject: *Re: [pkix] New Version Notification for
>                     OCSP Responder 1 has only access to the revocation
>                     status of the first 100.000 issued certificates.
>                     OCSP Responder 2 has only access to the revocation
>                     status of the next 100.000 issued certificates.
>                     A Relying Party (RP) uses url1 that is present in
>                     the target certificate to query OCSP Responder 1.
>                     However, there is a man-in-the-middle-attack and
>                     this request in routed to OCSP Responder 2.
>                     Without the proposed extension, the protocol would
>                     provide incorrect revocation status results.
>
>                     Denis
>
>
>
>                      Santesson a écrit :
>
>                         I don't see that this extension is required in
>                         order to split OCSP responding for chunks of
>                         certs.
>
>                         You can point the client to the correct
>                         responder using information in the cert today.
>
>                         The responder can determine if the requested
>                         vert is within it's handled portion of certs.
>
>                         Given that you trust the OCSP responder and
>                         the responder is honest, you will receive an
>                         appropriate response.
>
>                         So, why the extension?
>
>                         I can only imagine the extension being useful
>                         to detect if a responder responds outside of
>                         it's authority, but if the OCSP responder is
>                         *From: *Santosh Chokhani
>                         <[email-masked]
>                         *Date: *Friday, September 28, 2012 4:17 PM
>                         *To: *"[email-masked]
>                         <mailto:[email-masked]>"
>                         <[email-masked]
>                         *Subject: *Re: [pkix] New Version Notification
>                         for draft-pinkas-2560bis-ocsp-locationcheck-00.txt
>
>                             Denis,
>
>                             OCSP certificate means that the Responder
>                             is authoritative for all certificates as
>                             Note that absence of IDP means that the
>                             CRL is full and complete. We do not have a
>                             similar statement in 2560 and this
>                             extension is fully effective only if such
>                             is the case, i.e., by omitting this
>                             extension, the CA implies that the
>                             We either need to impose this requirement,
>                             which while new, most implementations I
>                             know impose or discuss it in the Security
>                             Considerations section.
>
>                             [mailto:[email-masked]] *On Behalf
>                             Of [email-masked]
>                             <mailto:[email-masked]>
>                             The last comment from Santosh, triggered
>                             me to write a new draft proposal directly
>                             related to 2560bis.
>
>                             This proposal allows to split the workload
>                             of an OCSP service from a CA between
>                             several OCSP Responders.
>                             This may be desirable for PKIs issuing a
>                             large number of certificates (e.g. several
>                             hundred of thousands).
>
>                             Denis
>
>                             _______________________________________________
>                             pkix mailing list [email-masked]
>                             <mailto:[email-masked]>

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 11 Oct 2012 08:07:50 -0700

I fail to understand the benefits of this underlying assumption on which the
proposal for this extension is based.

“This proposal allows tosplit the workload of an OCSP service from a CA
between several OCSP Responders. 
This may be desirable for PKIs issuing a large number of certificates (e.g.
several hundred of thousands).”

The proposal just cites that it may be desirable without saying what those
benefits are.

I think that this approach does not help either with scalability or security
and  it introduces unnecessary complexity.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Thursday, October 11, 2012 7:26 AM
To: Stefan Santesson; Denis Pinkas
Cc: pkix
Subject: Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

It is possible that a Responder will assert good (e.g., for pre-signed
responses) since RFC 2560 does not address if the CA splits the
responsibility among multiple responders.  In that case, MITM can get and
play a response of “good” from a legitimate Responder.

CAs and Responders who implement this extension are protected.  For further
discussion, see my comment in this thread that Denis has not addressed.

It is akin to IDP for partitioned CRL, but my concern is different than
yours.  I am concerned that unless the assumptions made by this extension
are adhered to by the CA and the Responders, there is less of a benefit.

Signed error or not.

/Stefan

Stefan,

RFC 2560 states:

 

 - was there a substitution attack, since this may not be a response from
the authorized responder ?
 - am I using a wrong URL, since I am not sure this response comes from the
right URL ? 
 - am I missing an authorization to get the status ?

Denis

/Stefan

Stefan,

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

Denis

/Stefan

Stefan,

Denis

 Santesson a écrit :

So, why the extension?

/Stefan

Denis,

To the list, 

Denis 

============================================================================
================== 

Title:                 OCSP LocationCheck certificate extension Update to
OCSP 
http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-
00.txt

Abstract: 

The IETF Secretariat

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 18:30:42 +0200

Piyush,

> I fail to understand the benefits of this underlying assumption on 
> which the proposal for this extension is based.
>
> "This proposal allows tosplit the workload of an OCSP service from a 
> CA between several OCSP Responders.
> (e.g. several hundred of thousands)."
>
> The proposal just cites that it may be desirable without saying what 
> those benefits are.
>

The benefit is that every OCSP responder is only responsible for a 
fraction of the issued certificates.
It is up to the CA to decide which fraction.

As an example, "critical servers" may be served by a dedicated OCSP 
responder servicing around 1.000 servers,
while "usual servers" may be served by another OCSP responder servicing 
around 100.000 servers.

So the first URL will be less loaded than the second one.

Another advantage is that the first URL will be kept unknown, unless you 
get a certificate from a critical server.
So a denial of service attack is more difficult to construct, since you 
need to get a certificate from a critical server,
rather than any certificate issued by the CA.

Denis

> I think that this approach does not help either with scalability or 
> security and  it introduces unnecessary complexity.
>
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 11 Oct 2012 13:01:49 -0400

How is an OCSP responder that is fed by CRLs supposed to know which fraction
it is responsible for?

Why would you limit an OCSP responder that had direct access to a CA
database?  

You could achieve your example below by issuing the critical servers off of
a different CA than usual servers and avoid updating client software.

The unknown URL point is pretty thin.

From:  Denis Pinkas <[email-masked]>
Date:  Thursday, October 11, 2012 12:30 PM
To:  Piyush Jain <[email-masked]>
Cc:  'Stefan Santesson' <[email-masked]>, 'pkix' <[email-masked]>
Subject:  Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

>> ³This proposal allows tosplit the workload of an OCSP service from a CA
>> several hundred of thousands).²
>>  
>>  
>>  
>  The benefit is that every OCSP responder is only responsible for a fraction
> of the issued certificates.
>  As an example, "critical servers" may be served by a dedicated OCSP responder
> servicing around 1.000 servers,
>  Another advantage is that the first URL will be kept unknown, unless you get
> a certificate from a critical server.
>  So a denial of service attack is more difficult to construct, since you need
> to get a certificate from a critical server,

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 11 Oct 2012 19:04:07 +0200

If a CA creates 100K or more certificates, one might consider
to split the CA and with a designated ocsp responder per CA.

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 11 Oct 2012 10:10:05 -0700

Denis,

Thanks for your quick response.

The way I interpret it is that in you example some certificates issued by
the CA are more critical than others.

That an interesting idea. One outcome could be that CAs can charge a premium
based on the OCSP URI that is put in your certificate. I wonder what the CPS
for such a CA would look like.

Don't you think that public CA vendors already have a way to do this? They
don't partition OCSP responders, instead they partition CAs based on
'criticality' of the certificates that are issued by that CA.

You also made a point about denial of service. Personally I'm not a fan of
security through obscurity. But even if this point has some merit, your
proposed extension is not needed for such a design. CAs are free to put
whatever AIA extension they want in any certificate they issue.

-Piyush

From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 11, 2012 9:31 AM
To: Piyush Jain
Cc: 'Santosh Chokhani'; 'Stefan Santesson'; 'pkix'
Subject: Re: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Piyush,

"This proposal allows tosplit the workload of an OCSP service from a CA
between several OCSP Responders. 
This may be desirable for PKIs issuing a large number of certificates (e.g.
several hundred of thousands)."

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 19:18:02 +0200

Carl,

> How is an OCSP responder that is fed by CRLs supposed to know which 
> fraction it is responsible for?
>
As you have implicitly noticed, this scheme is only adequate when the 
OCSP responder has a direct access
to the portion of the CA database for which it is responsible. I take 
your point: this should be better advertised.

> You could achieve your example below by issuing the critical servers 
> off of a different CA than usual servers and avoid updating client 
> software.

This may or may not be possible or desirable.

Denis

> From: Denis Pinkas <[email-masked] <mailto:[email-masked]>>
> To: Piyush Jain <[email-masked] <mailto:[email-masked]>>
> Cc: 'Stefan Santesson' <[email-masked] 
> <mailto:[email-masked]>>, 'pkix' <[email-masked] 
> <mailto:[email-masked]>>
>>     I fail to understand the benefits of this underlying assumption
>>     on which the proposal for this extension is based.
>>
>>     "This proposal allows tosplit the workload of an OCSP service
>>     certificates (e.g. several hundred of thousands)."
>>
>>     The proposal just cites that it may be desirable without saying
>>     what those benefits are.
>>
>
>     As an example, "critical servers" may be served by a dedicated
>     OCSP responder servicing around 1.000 servers,
>     while "usual servers" may be served by another OCSP responder
>     servicing around 100.000 servers.
>
>     Another advantage is that the first URL will be kept unknown,
>     unless you get a certificate from a critical server.
>     So a denial of service attack is more difficult to construct,
>     since you need to get a certificate from a critical server,
>>     I think that this approach does not help either with scalability
>>     or security and  it introduces unnecessary complexity.
>>
>>
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 19:25:20 +0200

Piyush,
> The way I interpret it is that in you example some certificates issued 
> by the CA are more critical than others.
>
> That an interesting idea. One outcome could be that CAs can charge a 
> premium based on the OCSP URI that is put in your certificate. I 
> wonder what the CPS for such a CA would look like.
>
> Don't you think that public CA vendors already have a way to do this? 
> They don't partition OCSP responders, instead they partition CAs based 
> on 'criticality' of the certificates that are issued by that CA.
>
It is a chicken and egg problem. Public CA vendors can't partition OCSP 
responders since the proposed extension is not defined/standardized.
So the only solution is to act as you indicate.

Denis

> You also made a point about denial of service. Personally I'm not a 
> fan of security through obscurity. But even if this point has some 
> merit, your proposed extension is not needed for such a design. CAs 
> are free to put whatever AIA extension they want in any certificate 
> they issue.
>
> -Piyush
>
>
> *From:*Denis Pinkas [mailto:[email-masked]]
> *Sent:* Thursday, October 11, 2012 9:31 AM
> *To:* Piyush Jain
> *Cc:* 'Santosh Chokhani'; 'Stefan Santesson'; 'pkix'
>     "This proposal allows tosplit the workload of an OCSP service from
> Another advantage is that the first URL will be kept unknown, unless 
> you get a certificate from a critical server.
> So a denial of service attack is more difficult to construct, since 
> you need to get a certificate from a critical server,

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Oct 2012 19:26:30 +0200

Peter,

See my response to Carl.

Denis

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 11 Oct 2012 19:34:45 +0200

Bonsoir,

2012/10/11 Denis Pinkas <[email-masked]>:
>>  Don’t you think that public CA vendors already have a way to do this? They
>> don’t partition OCSP responders, instead they partition CAs based on
>> ‘criticality’ of the certificates that are issued by that CA.
>

I don't think public CAs want to partition OCSP responders. CA
partitioning is quasi-free, while performant OCSP isn't.
Adding OCSP partitioning will just render the whole stuff harder to use.
Ongoing discussions in CABForum go toward an optional "mustStaple"
extension for certificates.

-- 
Erwann.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 11 Oct 2012 20:02:43 +0200

>
>> You could achieve your example below by issuing the critical servers off of a different CA than 
>> usual servers and avoid updating client software.
>
To me this doesn't seem very helpful.
Could you provide a concrete use case where
this is not possible or where this is not desirable?

Erwann gave a concrete response.

Peter

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 23:38:58 +0200

A responder that is designed to work within the described setup will not
respond good.
It's hard to protect against bad implementations through protocol design.

My personal view is still that this is not worth the pain.

But we are in any case not allowed to take on more work in PKIX, so my
opinion is not important.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Thursday, October 11, 2012 4:26 PM
To:  Stefan Santesson <[email-masked]>, Denis Pinkas
<[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  RE: [pkix] New Version Notification for
draft-pinkas-2560bis-ocsp-locationcheck-00.txt

> responses) since RFC 2560 does not address if the CA splits the responsibility
> among multiple responders.  In that case, MITM can get and play a response of
> ³good² from a legitimate Responder.
>  
> It is akin to IDP for partitioned CRL, but my concern is different than yours.
> I am concerned that unless the assumptions made by this extension are adhered
> to by the CA and the Responders, there is less of a benefit.
>  
> 
> I still think the gain obtained by your proposal is far less than the pain of
> introducing a new critical extension that needs client support.
> 
>  
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Oct 2012 23:51:43 +0200

Not that I really care about this, butŠ

Just for the record, the below requirement is not good standards language.

> This single extension MAY only be placed in an OCSP certificate.

What you are trying to say (I assume) is that "This single extension MUST
NOT be placed in any certificates other than OCSP responder certificates".

"MAY only" is not a testable requirement.

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Fri, 12 Oct 2012 04:27:27 +0200 (CEST)

Santosh Chokhani wrote:
> 
> It is possible that a Responder will assert good
> (e.g., for pre-signed responses) since RFC 2560 does not
> address if the CA splits the responsibility among multiple
> responders.  In that case, MITM can get and play a response
> of "good" from a legitimate Responder.

What you're describing is not OCSP (rfc2560).

In difference to CRLs, an OCSP "good" response is an affirmative
response for an explicitly identified certificate.  An OCSP responder
can only produce "good" responses for certs for which it officially
claims to be authoritative (whether the OCSP client sees a specific
OCSP responder as being authorized is a completely distinct question).

> extension are adhered to by the CA and the Responders, there is less

To me that seems like a bad analogy.  When processing CRLs, the "good"
(aka unrevoked) status is a bold conclusion drawn from the absence of
a negative confirmation of revocation for an explicitly identified cert
on one (or a set of) CRL(s) that is(are) alleged to be authoritative.

A single or fixed URL also does not seem to be an issue for scaling.
DNS round robin A/AAAA records can load-balance OCSP requests across
different IP-Addresses, and NATs can load-balance OCSP requests to
the same IP-Address onto different backend OCSP servers.

When the OCSP signer cert is properly included in the OCSP response,
then each of the backend OCSP servers can operate with its own
signing key.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 12 Oct 2012 04:36:46 +0200 (CEST)

Denis Pinkas Bull wrote:
> OCSP responder), whereas it would have received either "good" or
> "revoked", if there had been no attack.

Why should a MitM try to obtain an unsigned(!!) "unauthorized" response
form your second OCSP responder AT ALL?  The MitM could simply make up
that unsigned "unauthorized" response all by himself, and the OCSP
requestor has no means to distinguish an MitM from a real unauthorized
rfc2560 responder.

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 12 Oct 2012 16:18:35 +0200

Peter,

This may be costly since some PKI vendors are charging per CA, and
you also need to pay for the writing of a CP, the writing of a CPS, the 
writing of conditions of use,
the change of the CA key when it will need to be changed, etc ...

This extension is optional and thus CAs shall only use it after making 
sure that the RPs which trust
them are able to support it.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 12 Oct 2012 16:19:00 +0200

Martin,

The point is that, when a  RP gets  "unknown" (with a correct signature 
from the OCSP responder),
it sure that it is cannot be a response from MitM.

Denis

=================================================================

Error messages are:

     -- malformedRequest,
     -- internalError,
     -- tryLater,
     -- sigRequired,
     -- unauthorized.

==========================================================================

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 12 Oct 2012 16:43:20 +0200

On 10/12/2012 04:18 PM, Denis Pinkas wrote:
> you also need to pay for the writing of a CP, the writing of a CPS, 
> the writing of conditions of use,

"Maybe". I think it is more efficient to convince vendors to change 
their policy
than to play play cat and mice with them.
Other vendors might sell as a function of the number of Issued certificates.
Tell me the vendor, I'l might charge you two days of consulting.

The CP/CPS are the same if this is just another incarnation of the same 
CA for
performance reasons.
If you have different rules depending on whatever thing, I am not sure
that you would put this all together into one CP/CPS.
N.B. CP/CPS is not a good distrinction between two documents.

> them are able to support it.
Doesn't sound very realistic to me.

BTW: What is the difference to use a subjectAltName with the URI of the 
access location?
No new extension.

Peter

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Oct 2012 01:24:31 +0200 (CEST)

Denis Pinkas wrote:
> from the OCSP responder), it sure that it is cannot be a response from MitM.

But that is completely useless information.

The objective of OCSP/rfc2560 is not doing isolated OCSP for its
own merits or fun.  It is a means to an end: a possible method
to check the revocation status of a certificate.

When trying OCSP to perform a revocation check for a certificate
it doesn't really matter how the operation fails, whether the
DNS lookup of the hostname on the OCSP URL fails with NXDOMAIN
or NODATA, whether the connect fails with "ICMP no route to host",
the "administratively firewalled" ICMP, a connection timeout or
connection failure (TCP RST), whether the response is an rfc2560
error message does not make any difference.  All of these are
fully equivalent useless answers to determine the status of
a certificate.  Doing digital signatures on anything will have
exactly zero impact on the uselessness for the purpose of
determining the status of the certificate.

If the CA would operate a feature-enhanced OCSP server
itself, that is capable of returned signed errors, and if the
EE cert contained an extension that indicates this feature
for the CA's own OCSP server, what would that mean for RPs
that have local (plain-rfc2560) OCSP responders configured?

-Martin