Subject: ASN.1 syntax for OCSP nonce value?

From: Geoff Elgey <[email-masked]>
Date: Mon, 20 May 2002 15:29:03 +1000

G'day,

Section 4.4.1 of RFC 2560 describes a "nonce" extension, but only gives 
the object identifier for that extension. It mentions that the 
"extnValue" component of the extension contains the nonce value, but 
does not describe the syntax of this value.

I'm assuming that the syntax for a nonce value is an OCTET STRING, correct?

Cheers,
Geoff

---

From: Ambarish Malpani <[email-masked]>
Date: Sun, 19 May 2002 23:40:16 -0700

Hi Geoff,
    Yes, the syntax for the value of a nonce is an OCTET STRING
(because the nonce is specified as an extension and the value
of an extension is always encoded in an OCTET STRING).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Geoff Elgey [mailto:[email-masked]]
> Sent: Sunday, May 19, 2002 10:29 PM
> To: [email-masked]
> Subject: ASN.1 syntax for OCSP nonce value?
> 
> 
> 
> G'day,
>

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 28 May 2002 11:50:47 -0700

Our server doesn't check to see the contents of the nonce value,
since all we do it put it back in the response.

I don't know how others encode it.

Regards,
Ambarish

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 7:50 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: ASN.1 syntax for OCSP nonce value?
> 
> 
> 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: [email-masked] (Peter Gutmann)
Date: Wed, 29 May 2002 18:49:41 +1200 (NZST)

I 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?  Could it be something which vanished during the editing
>process?

In case anyone cares the nonce appeared in -03 (I don't have -02, only -01
before that) and then remained constant until -08 and the final RFC.  No
mention of an INTEGER.  Hmm...

Peter.

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 30 May 2002 16:16:14 -0400

Geoff:

      Even ANY requires that the length field of the embedded object be
consistent with its wrapping.  In particular, the following ugly check
could be performed: "If (considering octet values as unsigned integers in
the range 0-255) the value of the first octet of the embedded object is not
31 mod 32, either the next series of octets must be a definite-length
encoding matching the length of the OCTET STRING after deduction for the
DER/BER header or the value of the next octet must be 128 and the values of
the last two octets of the encoding must both be zero.".  There's a
corresponding check if the first byte's value is 31 mod 32.
      Even these relatively weak constraints are inconsistent with treating
the value as an untyped blob.  A large majority (over 95%) of untyped blobs
of random data will fail this check, and the proportion will go up (not
down) if one includes a check for multi-byte identifiers.

            Tom Gindin

Geoff Elgey <[email-masked]>@mail.imc.org on 05/30/2002 03:47:52 AM

Sent by:    [email-masked]

To:    Peter Gutmann <[email-masked]>
cc:    [email-masked]
Subject:    Re: ASN.1 syntax for OCSP nonce value?

G'day,

Peter Gutmann wrote:
> (Some implementation guidance as to what's really supposed to be
encapsulated
>  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

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 31 May 2002 17:13:31 +0200 (MET DST)

> G'day,
> 
> Peter Gutmann wrote:
> > (Some implementation guidance as to what's really supposed to be encapsulated

Geoff,

I rather believe that the omission is not voluntary, a pure error,
not detected during the fast review process like for example an OID 
that was initially defined in another PKIX draft....

CLIENTS that create a blob as the value can also be considered as simply 
wrong; or, there cannot be a conformant implementation because there is 
no complete definition (i.e., a missing piece ASN1 syntax). 

It was not possible to detect this automatically with some ASN1 tool as it 
would be possible in the new 2002 asn1 by specifying something like 

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING (
         CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
    }

( One can also argue that the whole concept of have an encapsulated
  piece of syntax in an octet string is a horrible and useless non-sense 
  IF in all cases the content is supposed to be correctly encoded
  but this is really almost 'talking about cars' (to avoid usage
  of 'religious'). )

Now one can strt and discuss whether one want to find a ASN1 definition
that matches the current client implementations or whether it seems
more appropriate to make a syntax which is clean with 3280. 

> be defined as having an INTEGER syntax.

I'd would support introducing this, and allowing client to generate
invalid encodings until some not so far time in the future, and or
indicate that servers may want not to decode all extensions, etc.

Technically, fixing a client doesn't seem a big issue to me, 
installing it in a real environment, ... hm ... 

Somehow this reminds me to to SMIME encapssulated content vs PKCS7 V1.

Peter