Subject: RE: Open issue: DPV relay

From: Peter Sylvester <[email-masked]>
Date: Fri, 12 Apr 2002 18:28:29 +0200 (MET DST)

Peter, 

I am a little bit confused that you replied to a message sent
by Denis as a repl to me. 

>  
> Peter.
> 
> OCSP has always envisioned and practised a relying party
> authorizing an OCSP Responder: no CA/AA involvement
> is required and no certificate need be issued, in this
> case.  

There seems to be a confusion about the difference of
a 'Trusted Responder' and an 'Authorised Responder' 

   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
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating 
      that the responder may issue OCSP responses for that CA

In 4.2.2.2 the text

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
  
seem to indicate that two of the three cases are AUTHORISED responders. 
The next sentences say: 

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

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

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

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

which seems to explain an additional,thus three possible conditions for which
a response can be excepted. But what exactly means 1) ?

what means 'locally configuring one or more OCSP signing authorities'?

Does it mean that this matched the second case in the introduction,
which IMO is that a relying party that can operate its own OCSP
service for its own benefit, just as a front end to a collection
of some CRLs for example. 

Or, the text says TWO things:

How a CA can delegate OCSP operations resulting in 2 modes 
to accept responses by a relying party, and a third mode indicating
how a relying party can have an additional mode to trust someone
who is NOT in one of the two other cases, and may have no
relationship with the CA or else. 

> Carry over this conformance requirement from OCSP to DPV:
> 
> An OCSP client (which includes a client that is a DPV server)
> must potentially accept an OCSP response according to ALL the 
> rules of 4.2.2.2. There are three cases: (1) (2) and (3).
Do You mean ALL (conditions met at the same time) or *ANY*
(of them may be true). ?  

> 
> Lets remember, a relying party can operate its
> own DPV service for its own benefit. The relying party 
> needs no authority from a CA to do so. The operator
> of a DPV server is not necessarily a TTP, and
> need have no relationship to the cert or CRL 
> issuer, other than that of performing
> relying party obligations or (less stringent) user 
> obligations according to the CP.
> 
In your paragraph, if you replace DPV by OCSP, I don't see
why this would be different if my interpretation of the
three cases are correct. 

Or, for OCSP the condition

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

doesn't it mean that some other relying party who will inspect the
response will not necessarily have the same configuration? 

Peter S

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Apr 2002 09:49:21 +0200

Peter (Sylvester),

I agree that there is a difference between an authorized responder 
and a server trusted under a given policy. 

So in order to solve this last issue, I propose to replace the current text
which is:

The DPV request MUST allow the client to request that the response 
include the certification path and revocation status information used 
by the DPV server to process the request. When requested, the DPV 
server MUST include the certification path and revocation status 
information in the response when the certificate is valid according to 
the validation policy. However, the server MAY omit the certification 
path and revocation status information when the certificate is invalid.

by the following text:

The DPV request MUST allow the client to request the response to 
include either the certification path and the revocation status 
information from authorised CRL issuers or authorised OCSP responders, 
or a DPV response from a DPV server that is trusted under the 
validation policy. This information may allow other clients, not 
trusting the requested DPV server to be confident that the certificate 
validation has correctly be performed. When the certificate is valid 
according to the validation policy, the server MUST, upon request, 
include that information in the response. However, the server MAY 
omit that information when the certificate is invalid or when it 
cannot determine the validity.

Regards,

Denis

---

From: "todd glassey" <[email-masked]>
Date: Mon, 15 Apr 2002 05:13:32 -0700

Gentlemen -See inline below...

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 15, 2002 12:49 AM
Subject: Re: Open issue: DPV relay

> validation has correctly be performed.

Denis - Peter -

I disagree with this next paragraph -

> When the certificate is valid

I cant think of a commercial process when the RP would want the DPV to make
ANY decisions regarding what to include or not to as part of the data gram
and this is important to the bigger picture. The key-concept for audit-model
stability is to to keep the response types identical (from yes to no
answers) and have the content be reflective of that yes or a no answer
rather than the structure of the message envelope itself changing from
positive to negative states.

This is one of the ongoing problems with many PKI protocols. It is
technologically slick if the message types are different for a YES and NO
answer but from a commercial use standpoint the exact opposite is true... in
fact many PKI protocls have too much diversity and divergences in the
srtructure of YES messages relative to their NO messages. In fact from a
Legalese standpoint, it is very important that the record reflect why you
said "NO" too so the datapoints used to signify this are equally critical to
the yes or no content they reinforce.