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

From: [email-masked] (Peter Gutmann)
Date: Sat, 1 Jun 2002 18:11:21 +1200 (NZST)

Geoff Elgey <[email-masked]> writes:

>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.

The problem with this is that it's then in violation of all other definitions
of EXTENSION in any other standard (X.509, RFC 2459/3280, etc etc).  It's an
error in the OCSP spec which needs to be fixed.  Bride-of-2560 should include a
warning to implementors to say that older implementations may get it wrong (in
terms of what X.509/2459/3280 define) and that implementations should therefore
be able to handle either alternative, but what's actually used should be
consistent with the accepted definition.  Otherwise there's little point in
going through draft standards and whatnot if errors aren't corrected.

Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 03 Jun 2002 13:03:24 -0700

I agree with Peter.

Would people be fine with a nonce that was an OCTET STRING?

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: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 11:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: ASN.1 syntax for OCSP nonce value?
> 
> 
>

---

From: "Frank Balluffi" <[email-masked]>
Date: Tue, 4 Jun 2002 08:45:22 -0400

I was able to quickly find three precedents:

Kerberos (RFC 1510)  INTEGER
TSP (RFC 3161)       INTEGER
SCVP (draft)         OCTET STRING

Frank

---------------------------------------- Message History ----------------------------------------

From:  [email-masked] (Peter Gutmann)@mail.imc.org on 06/04/2002 02:59 PM ZE12

DELEGATED - Sent by:    [email-masked]

To:    [email-masked]; [email-masked]; [email-masked]
cc:    [email-masked]
Subject:    RE: ASN.1 syntax for OCSP nonce value?

>Would people be fine with a nonce that was an OCTET STRING?

Even though I mentioned the use of INTEGER earlier on (probably due to its
origins in TSP), I'd actually prefer OCTET STRING to INTEGER because:

  a. Most applications use an octet string anyway (typically a SHA-1 hash),
     even if it's encoded as an integer.
  b. There's no confusion over encoding of sign bits.

Peter.

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---

From: "Frank Balluffi" <[email-masked]>
Date: Tue, 4 Jun 2002 11:06:34 -0400

I should have added that I prefer OCTET STRING, as the processing does not involve any math.

Frank

---------------------------------------- Message History ----------------------------------------

From:  "Frank Balluffi" <[email-masked]>@mail.imc.org on 06/04/2002 08:45 AM AST

To:    [email-masked] (Peter Gutmann)
cc:    [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject:    RE: ASN.1 syntax for OCSP nonce value?

Frank

---------------------------------------- Message History ----------------------------------------

Peter.

--

--

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 4 Jun 2002 19:04:07 +0200 (MET DST)

> I should have added that I prefer OCTET STRING, as the processing does not involve any math.

3029 also has a Nonce of INTEGER but actually allows that during chaining nonces
can be made longer, and in the responses just a prefix should match (regarding the
integer as a octet string, not as a number. 

I don't know why TSP and DVCS initially uses Integer, maybe because of kerberos,
anyway, for OCSP no compatibility with other protocols seem necassary anyway.

---

From: Ambarish Malpani <[email-masked]>
Date: Tue, 04 Jun 2002 14:52:26 -0700

Dave, if there is no backwards compatibility issue, you could
decide to only support (b).

As a paranoid engineer, I would recommend that the entity
making the OCSP request followed (b), while a responder/proxy (to be
more liberal), used the rule defined in (c).

Regards,
Ambarish

> From: David Hopwood [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 2:01 PM
> To: [email-masked]
> Cc: [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> [Context for ietf-tls: the IETF-PKIX WG have been discussing 
> the fact that
> RFC 2560 (OCSP) is unclear about how the nonce value in the OCSP
> id-pkix-ocsp-nonce extension is encoded. OCSP Extensions 
> should be a DER
> encoding of some specified type encapsulated as an OCTET 
> STRING, but some
> OCSP clients just send a raw OCTET STRING containing the nonce.]
> 
> Peter Gutmann wrote:
> One of the TLS extensions in 
> <draft-ietf-tls-extensions-04.txt>, just about to
> go to Last Call, uses OCSP. In that extension (see section 
> 3.6 of the draft),
> the TLS client acts as an OCSP client, and the TLS server 
> acts as an OCSP proxy.
> 
> Strictly speaking it's not up to that draft to clarify the 
> specification of
> OCSP, but it might be helpful to do so if this is considered 
> a bug in RFC 2560.
> Which option would the PKIX group prefer?
> 
>   a) No change.
>   b) Say that an OCSP nonce extension generated by a TLS 
> client MUST be a
>      DER-encoded OCTET STRING (encapsulated as another OCTET STRING).
>   c) Say that the TLS server MUST pass each OCSP extension as 
> an opaque blob,
>      i.e. not check that it encapsulates a valid DER encoding.
>   d) Both b) and c).
> 
> My preference is for b) (there's no backward compatibility 
> problem in this
> case).
> 
> - -- 
> David Hopwood <[email-masked]>
> 
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C 
> D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If 
> I revoke a
> public key but refuse to specify why, it is because the 
> private key has been
> seized under the Regulation of Investigatory Powers Act; see 
> www.fipr.org/rip
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBPP0qbjkCAxeYt5gVAQFn+Af+OCYbp9OgVouFVImZVe3yrJ7Aafq0w0qa
> 9xFCuCB9ULOtilCg12NMwq772fv2bXlHWriOQGX8G0o90aqpuTfOELf3sw/CRcIS
> 5Y3cIeLbza//RcTw3JuL9Pk8OkCVKATbwlRW8ZenagI3XJuDoCDd5HiTHgBPf5lX
> 7Klb6ZZuZBBDIUYavRqMmzy7Bzq3zqy2fi3it3YYsYswl5UtHQgZ/f7tCDdc2uBS
> B75/skpdTJJ+C1DdUPQYRw3WwlZAxvcj4Q0z8dYmTfy0Aesg292e7jxp0Ckhrn23
> dm8xe/LsVmueV/lv8QXzFo7W9aZAUbEhNS1dBzVcVJu/kM+dOdIhtw==
> =N5lp
> -----END PGP SIGNATURE-----
>

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 5 Jun 2002 16:21:54 +1200 (NZST)

>I should have added that I prefer OCTET STRING, as the processing does not

Yup, that's what I implied with the "sign bit" point.  Comparing two integers
(acting as octet string holes) is far more difficult than it needs to be, since
some will be zero-padded and some won't, and some should be but aren't, so
instead of a simple memcmp() you have to handle all sorts of special cases. You
also run into problems if a client submits a non-DER request (eg sign bit
incorrectly encoded) and the server replies with a correctly DER-encoded
response, which the client may or may not reject as not matching the request.

Peter.