Subject: RE: Matching CertIDs between OCSP requests and responses

From: [email-masked]
Date: Wed, 14 Mar 2001 16:40:15 +0000

Mike,

Thanks for the reply.  I think my use of the phrase 'server error' was
perhaps misleading:  what I mean is, has the server behaved in a
non-compliant manner if a certificate from the request is missing from the
response (or, for that matter, if the response contains information about a
certificate not present in the request).  That is, is doing so an improper
response?

The idea of non-global errors is interesting, I hadn't thought about that.
It might be useful where multiple certificates are present in the request.
The most likely case I can think of is where the OCSP server is acting in
request-forwarding mode, splitting a request and farming it out to several
other servers, which in turn may return differing error states.  It would
be a pity to simply throw out the valid information and return an error
just because one of the second-level servers did.

Regards,

Jonathan

                    "Michael                                                                 
                    Myers"               To:     <[email-masked]>,             
                    <myers@coasts        <[email-masked]>                                 
                    ide.net>             cc:                                                 
                                         Subject:     RE: Matching CertIDs between OCSP      
                    14/03/01             requests and responses                              
                    16:38                                                                    

Jonathan,

You are correct in your assumptions.  One point of clarification however.

Server errors appear in the mandatory responseStatus field of OCSPResponse
and not the optional responseBytes field in order to ensure that a server
will produce *some* type of feedback in the event of an error.

OCSPResponse ::= SEQUENCE {
    responseStatus     OCSPResponseStatus,
    responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }

Given that, such errors speak to the server's response as a whole and not
to
individual certificates in the instance when multiple certificates are
identified in a single request and corresponding response (the latter via
SingleResponse syntax).

In other words, we assumed that the type of server problems enumerated in
OCSPResponseStatus would be global with respect a request regardless of
whether or not that request addressed a single certificate or multiple
certificates.

In the context of the v2 work, I'd be very interested to hear if your
implementation experience leads to a need for error states at the
SingleResponse level.

Your point regarding certificate identification matching in the v2 case is
well noted.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 4:25 AM
> To: [email-masked]
> Subject: Matching CertIDs between OCSP requests and responses
>
>
> All,
>
> Another OCSP (v1) question:  Can a client assume that the OCSP response
> CertID terms will precisely match those from the request?  That is, can
it
> assume
> 1 - that every certificate in the request will be in the response (i.e.
> it's a server error otherwise)
> 2 - that the hashing algorithm in the response CertIDs will be the same
as
> that which was used in the request (that is, the CertID data will match
> byte-for-byte between request and response).
>
> I guess given the variety of identifiers available alongside
> CertID in OCSP
> v2 that the issue of matching identifiers between request and response
> raised in point 2 above will be even more critical there.  But that's for
> other people to worry about - it's v1 I'm interested in for now.
>
> Thanks,
>
> Jonathan
> ----------------
> Dr Jonathan Tuliani
> www.symbian.com
>
>
>
> **********************************************************************
> Symbian Ltd is a company registered in England and Wales with
> registered number 01796587 and registered office at 19 Harcourt
> Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee and
> may contain privileged and/or confidential information. If you
> are not the named addressee you should not disseminate, copy or
> take any action in reliance on it. If you have received this
> message in error please notify [email-masked] and delete
> the message and any attachments accompanying it immediately.
> Symbian does not accept liability for any corruption,
> interception, amendment, tampering or viruses occuring to this
> message in transit or for any message sent by its employees which
> is not in compliance with Symbian corporate policy.
> **********************************************************************
>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 15 Mar 2001 15:45:54 -0800

Jonathan,

Apologies for not getting back sooner.  I see things have been busy.
Anyway, an RFC 2560 server is compliant even if it behaves in the manner you
describe.  There are no normative requirements in RFC 2560 to the contrary.
However, I'm of the opinion that a robust client should be capable of
handling this potential error condition.  This condition, along with several
other processing considerations that contribute to interoperability, could
be better addressed.  We will be working on these issues in the v2 context
over the next few months.  Perhaps you would care to join us in that,
particularly from the thin client perspective.  In any case, thanks for the
catch.  Hope this helps.

Mike

> Sent: Wednesday, March 14, 2001 8:40 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
>
>
>
> Mike,
>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 15 Mar 2001 15:45:54 -0800

Jonathan,

Mike