Subject: Matching CertIDs between OCSP requests and responses

From: [email-masked]
Date: Wed, 14 Mar 2001 12:24:32 +0000

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: Wed, 14 Mar 2001 08:38:31 -0800

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,
>
> 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.