Subject: Re: Open issue: DPV relay

From: Peter Sylvester <[email-masked]>
Date: Wed, 10 Apr 2002 20:39:43 +0200 (MET DST)

>  
> > In OCSP, you have that either the response is signed by the same entity that
> > signed the certificate or by an OCSP entity which has a certificate directly
> > signed by the CA in question with some extended key usage.
> 
> True.

Well, maybe not, I was just made aware that I have forgotten that OCSP 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
   -- 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

See the second point and also read 4.2.2.2

Or: You may want a requirement that the DPV responder must ensure
that the OCSP responses are signed by a CA or an authorised responder
and not by some locally trusted OCSP responder in order to
be sure that an 'evidence verifier' finds trustworthy information. 

>  
> > To make the simple case, if a DPV response is signed directly by the CA
> > (or by an authorised responder), you have the same situation.
> 
> No. A CA can only assert information about what it is directly responsible.
So, the DPV response made by the CA just talks about the certificates
it has directly issued.

> No CA is responsible for all the certifiactes from one path. An OCSP query
> is for ONE certificate, while a DPV query involves a CHAIN of certificates.

The text says:

   The Delegated Path Validation (DPV) protocol allows a server to 
   validate one or more public key certificates according to a validation 
   policy.

   In order to validate a certificate, a chain of multiple certificates, 
   called a certification path, may be needed, comprising a certificate 
   of the public key owner (the end entity) signed by one CA, and zero or 
   more additional certificates of CAs signed by other CAs.

In the simple case of only one CA, an OCSP response signed by the CA
concerning the certificate in question does not say anything the
validity of the CA cert since when it was signed with the same key.
You thus just have on certificate.

In a case of one intermediate CA, the DPV response may for example
contain two OCSP responses, one signed by the intermediate CA
concerning the revocation status of the end user and another
concerning the statius of the intermediate CA signed by the
top CA. 

If both CAs provide a DPV service instead of an OCSP service
in the same way, you have exactly the same situation except
that this is a positive status information. 

For example, the initial client asks for a combined status, 
it asks his own trusted service, this server asks the intermediate
CA either to provide an OCSP status or a DPV status of the
cert in question and then asks the top CA to provide a status of
the intermediate CA's cert, and well, even three other OCSP
responders to provide statement that the top level 
CA's cert is good. 

DPV would allow to combine the responses differently. 
It can well be that the intermediate CA/DPV responder
itself asks for a DPV response from the top CA/DPV
and include this in his DPV response to the initial server.  
  
> 
> There are no similarities.
"Ok, let's talk." 

> > I think that there must be a language problem somewhere because I
> > fail to see what *not* you are referring, i.e. to see where we are
> > in disagreement.  I have not said that it is necessary for the client
> > to gather all information. I have said that the protocol must provide
> > a method to allow a client to ask and the server to respond with that
> > information.
> 
> Maybe, since we possibly interpreted diffrently "what has contributed to the
> final decision".
> 
> > > In case of a dispute, testing again the certificate validity, means that
> > > certificates, CRLs and OCSP responses must be available. Anything else is
> > > useless.
>  
> > I think that this may be the core of our disagreement.
>  
> > This is because you only accept that CA can create assertions about the
> > validity of their certificates using CRLs and OCSP. 
> 
> Correct.

Unfortunately we may be both wrong.  
 
> > As soon as you would
> > admit that some new protocol or service is provided that enhances and in
> > particular replaces them, the statements obtained via that service are
> > necessary.
> 
> > I would like to know what you would have said 5 years ago when only
> > CRLs existed.
> 
> Basicaly the chain must be verified and no element fom the chain must be
> revoked. 
> 
> Five years ago this information was provided off-line, i.e. via CRLs. OCSP
> allows to obtain the same information on-line. Between on-line and off-line
> I currently see no other mechanism. 

But you can have different protocols for these characteristics. Offline
you could use trees, online you can have DPV, or other techniques like
timestamps over CRLs and OCSP responses to have a proof that the server 
has provided the OCSPresp/CRL at a current date. 

> The basic question is whether first-hand information and second-hand
> information should be used. In case of a dispute, only first-hand
> information is useful (certificates and revocation status information from
> the CAs responsible for every certificate from the chain). DPV responses
> (i.e. the signed "yes" answers) are useless, unless the plaintiff and the
> defendant both trust the same DPV server.

OCSP responses may also be useless, unless the plaintiff and the
defendant both trust the same OCSP server. 

Peter

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 10 Apr 2002 13:52:22 -0700

Maybe this is well understood but FWIW take care in reading
4.2.2.2 of RFC 2560.  In part, we wrote "Therefore, a
certificate's issuer MUST either sign the OCSP responses itself
or . . ."  The intent with this particular wording its related
text "The key that signs a certificate's status information need
not be the same key that signed the certificate." was to enable
a differentiation between the identity of an abstract entity and
the key or keys that entity uses to assert its identity in
various circumstances.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Peter Sylvester
> Sent: Wednesday, April 10, 2002 11:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Open issue: DPV relay
>
>
>
> >

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 Apr 2002 12:18:22 +0200

Peter,

> See the second point and also read 4.2.2.2

Which says: 

   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. 
 
> be sure that an 'evidence verifier' finds trustworthy information.

This is correct. However, it is not necesssary to add this requirement in
the DPV requirements document since this requirement is already in section
4.2.2.2 from RFC 2560 (OCSP).

> So, the DPV response made by the CA just talks about the certificates

No. Talking about the certificates that a DPV server may have issued does
not make sense. Certificates are only issued by CAs, AFAIK. Once again, 
a DPV server MUST answer for one (or more) certificates and must verify 
an entire chain of certificates, whoever has issued them. A DPV server is 
*not* a CA. A DPV server can be *any* service provider. An organization
running a CA may also run a DPV server, in the same way as an organization
running a CA may also provide a Time-Stamping service.

 
 
> If both CAs provide a DPV service instead of an OCSP service

You mean "If the organisation hosting a CA also provides a DPV service ... "

> responders to provide statement that the top level

I believe that you have mis-understood one idea behind DPV. DPV verifies the
whole path processing. A DPV status about one intermediate certificate of
the chain does not make sense. The validation policy is not about that
intermediate certificate but about a given certificate and a whole chain
above it. Applying the validation policy on an intermediate certificate only
does not make sense.

> you could use trees, online you can have DPV, 

No. On-line, to know the revocation status of a single certificate we only
have OCSP. RFC 2560 states:

   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.  

Note that this is true as well for CRLs. Either the CA signs the CRL
directly or designate another authority.

RFC 2459 RECOMMENDS for the support of the CRL distribution points extension
which then contains a cRLIssuer field. "If the certificate issuer is not the
CRL issuer, then the cRLIssuer field MUST be present and contain the Name of
the CRL issuer. If the certificate issuer is also the CRL issuer, then the
cRLIssuer field MUST be omitted ..." 

> or other techniques like

Time-stamping is not needed to prove that the server has provided the
OCSPresp/CRL at a current date. An OCSP response includes such a date. CRL
checking uses thisUpdate and nextUpdate. Time-stamping may however be useful
for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
Signature Formats for long term electronic signatures) does however indicate
such a format in the context of a signature policy. Another format could be
derived from it in the context of a validation policy.

> defendant both trust the same OCSP server.

Wrong. RFC 2560 sates:

   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. 

In either of these cases, the plaintiff and the defendant cannot argue that
the OCSP response is not valid (unless the OCSP responder has been revoked
by the CA). They cannot argue that such responses are useless, or if they
do, 
this argumentation will be rejected.

I have made my best efforts to explain all the rational behind DPV
responses,
which are very different from OCSP responses. I have also made my best
efforts to explain why in the general case a DPV response from a given
server is not necessarilly trusted by all clients, and thus would be useless
in front of a court.

The security consideration section is very explicit on this issue:

"A DPV client must trust a DPV server to provide the correct answer. 
However, this does not mean that all DPV clients will trust the same 
DPV servers. While a positive answer might be sufficient for one DPV 
client, that same positive answer will not necessarily convince 
another DPV client."

Can we finally close this issue ?

Denis