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

From: [email-masked] (Peter Gutmann)
Date: Tue, 4 Jun 2002 14:59:06 +1200 (NZST)

Ambarish Malpani <[email-masked]> writes:

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

---

From: David Hopwood <[email-masked]>
Date: Tue, 04 Jun 2002 21:01:24 +0000

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

>   b. There's no confusion over encoding of sign bits.

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