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

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 May 2002 17:33:21 +1200 (NZST)

Juergen Brauckmann <[email-masked]> writes:
>Peter Gutmann wrote:
>>Hmm, I wonder where I got the INTEGER from?  The fact that I complain about it
>>in the code indicates that something at some point specified it... does anyone
>>archive old drafts?
>
>Perhaps you mixed it with TSP?

That would explain it.  I'm guessing it was a cut-and-paste from one to the
other (I use customised ASN.1 definitions to handle implementation bugs and
ambiguities in specs, so the TSA customisation would have been copied across.
Luckily the code is already set up to handle the situation of finding non-DER
values where there should be DER, because a widely-used CA did this a few years
ago in its certificates :-).

(Some implementation guidance as to what's really supposed to be encapsulated
 in the OCTET STRING would be useful for bride-of-2560).

Peter.

---

From: Geoff Elgey <[email-masked]>
Date: Thu, 30 May 2002 17:47:52 +1000

G'day,

>  in the OCTET STRING would be useful for bride-of-2560).

I think the rationale for the nonce value as defined in RFC 2560 is as 
follows:

"It does not matter what value is inside the OCTET STRING, so long as 
this value can be recognized as unique by the requestor and responder. 
The requestor MAY define additional semantics on the V part of the OCTET 
STRING TLV (for example, treating the V part as having a DER encoded 
INTEGER value). Such semantics are beyond the scope of the OCSP 
specification. The responder however MUST treat the V part of the OCTET 
STRING TLV as an untyped blob, and put it back unmodified into the 
response. The requestor MUST check that the untyped blob received in the 
response matches the V part of the OCTET STRING in the original request."

This leads to the following: treating the V part of the nonce TLV as 
having some specific syntax is clearly implementation specific. Any 
OCSPRequest / OCSPResponse value inspected by third-party tools (such as 
Peter's "dumpasn1" tool) therefore MUST treat the nonce as an untyped 
blob. While the original requestor may consider the nonce value of "02 
01 01" as representing an INTEGER with the value 1, to the OCSP server 
and any third-party tools, the nonce value is simply three bytes.

Of course, any implementation that treats the complete OCTET STRING TLV 
as the nonce is asking for trouble (since DER encoding of the OCTET 
STRING is only mandated for OCSP over HTTP).

The arguments above simply reflect the fact that the nonce extension in 
RFC 2560 was not defined consistently with the definition of EXTENSION 
in RFC 2459. The only way it can be made consistent with RFC 2459 and 
remain consistent with existing implementations is to associate the 
ASN.1 type ANY with the nonce object identifier. But this will only be 
valid of pre-1997 ASN.1 compilers. Sigh.

If the nonce extension was being introduced now, I'd recommend that it 
be defined as having an INTEGER syntax.

Cheers,
Geoff