Subject: Clarification request on RFC 2560

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 Sep 2001 12:20:10 +0200

In RFC 2560 section 4.2.1 (OCSP Response), we have

BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Usually every ASN1 field is explained, but in that document the certs field
is not explained.

Should that optional field be interpreted to carry a sequence of possibly
useful certificates ?

Denis

---

From: Rich Salz <[email-masked]>
Date: Thu, 13 Sep 2001 09:06:16 -0400

It's the signer's cert chain.  (Well, not *the* but you get the point.)

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

---

From: Phil Griffin <[email-masked]>
Date: Thu, 13 Sep 2001 16:41:52 -0400

> Should that optional field be interpreted to carry a sequence of possibly

That might be nice, but the big defect in this
ASN.1 is that there are two more or less "optional"
cases. One is when there are zero values of type 
Certificate, and the other when the OPTIONAL "certs"
component is absent. 

This could be fixed by defining or importing a type

   Certificates ::= SEQUENCE SIZE(1..MAX) OF Certificate

and changing the definition of type BasicOCSPResponse
to 

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT Certificates OPTIONAL
   }
 
This would also provide better semantic meaning when a
value of type "BasicOCSPResponse" was defined in a user
application using the new ASN.1 XML Value Notation.

Phil Griffin