Subject: Possible Errata on RFC 2560

From: "Jim Schaad" <[email-masked]>
Date: Sat, 20 Sep 2008 13:03:31 -0700

Section 4.4.1 says

4.4.1  Nonce

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

This does not tell me the ASN.1 type of the nonce.  I assume, but do not
know for sure that it is suppose to be an OCTET STRING.

Jim Schaad

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Sep 2008 16:26:32 -0700

>know for sure that it is suppose to be an OCTET STRING.

This looks like a reasonable erratum to me.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 25 Sep 2008 05:10:03 +1200

"Jim Schaad" <[email-masked]> writes:

>This does not tell me the ASN.1 type of the nonce.  I assume, but do not know
>for sure that it is suppose to be an OCTET STRING.

Its supposed to be an INTEGER AFAIK but implementations treat it as a INTEGER
form of an OCTET STRING hole.  Actually there are (or at least were a few
years ago) so many broken interpretations of this (INTEGER hole, OCTET STRING
hole, OCTET STRING inside another OCTET STRING, and finally just raw binary
data with no ASN.1 structure at all) that it's safest to treat it on reading
as a blob.

Peter.