Subject: Re: ASN.1 syntax for OCSP nonce value?

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 May 2002 02:49:53 +1200 (NZST)

Geoff Elgey <[email-masked]> writes:

>This implies that a "nonce" must have some ASN.1 syntax, the complete DER-
>encoding of which is encapsulated as the value part of an OCTET STRING
>encoding.

I thought the nonce was an INTEGER?  My code has:

  /* Although the nonce should be an integer, it's really an integer equivalent
     of an octet string hole so we call it an octet string to make sure it gets
     handled appropriately */

(that is, I treat it as an INTEGER encoded as an OCTET STRING hole).  The
result is:

  75 30   32:         SEQUENCE {
  77 06    9:           OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)
  88 04   19:           OCTET STRING, encapsulates {
  90 02   17:               INTEGER
            :                 00 C0 4B 2A 18 F8 25 91 6C 49 1A 86 34 E7 45 D0
            :                 67
            :               }
            :           }

Peter.

---

From: Geoff Elgey <[email-masked]>
Date: Wed, 29 May 2002 08:08:10 +1000

G'day,

Peter Gutmann wrote:
> (that is, I treat it as an INTEGER encoded as an OCTET STRING hole).  

RFC 2560 does not specify what the nonce is.

I thought that the ambiguity of some applications treating a nonce as an 
encapsulated INTEGER, while others treat the nonce as the complete OCTET 
STRING transmitted, meant that replay attacks could be exploited.

However, since a DER encoding is required, unique INTEGER values will 
always give unique OCTET STRING values (although at least the first two 
bytes of the OCTET STRING will be discarded).

In fact, it does not matter what the syntax happens to be of the value 
part of the OCTET STRING. Whether it is INTEGER, GeneralizedTime, BIT 
STRING, or even a complete X509 Certificate, is irrelevent. The encoding 
will be canonical, and the only requirement is that the encoding is 
sufficient enough to detect replay attacks.

However, since RFC 2560 defines the nonce as an EXTENSION as defined in 
RFC 2459, then there *should* be a syntax associated with the object 
identifier (just as Peter defines above).  This is simply for conformity 
with the specification, which (hopefully) will not affect any extant 
implementations.

-- Geoff

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 28 May 2002 23:50:11 +0100

>             :                 00 C0 4B 2A 18 F8 25 91 6C 49 1A 86 34 E7 45 D0

IIRC one client I tried placed an OCTET STRING inside the OCTET STRING
whereas another just put the raw nonce value in there with no encoding.
All the responders I tried would correctly handle the raw value. 

I had to treat ocspNonce as a special case in OpenSSL becasuse normally
it assumes some encoded structure is in there, it now treats it as a
'blob'.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.