Online Certificate Status Protocol (OCSP) Nonce Extension
draft-ietf-lamps-ocsp-nonce-05

Just some nits of varying severity from me...

Abstract

   This document specifies the updated format of the Nonce extension in
   Online Certificate Status Protocol (OCSP) request and response

nit(?): is it the format itself that is specified or constraints upon
the format?

Section 1

   Due to not having an upper or lower limit of the length of the Nonce
   extension, the OCSP responders that follow [RFC6960] may be
   vulnerable to various attacks like Denial of Service attacks
   [RFC4732], chosen prefix attacks to get a desired signature from the
   OCSP responder and possible evasions that can use the Nonce extension
   data for evasion.  [...]

nit: "evasions that can use [...] for evasion" is slightly awkward
wording.  Could we say something different about what is being evaded?

                      This document specifies a lower limit of 1 and an
   upper limit of 32 to the length of the Nonce extension.  This

(pedantic nit): the length of the extension, or the length of the OCTET
STRING bearining the nonce value, contained in the extension?

Section 2

Thanks for agreeing to remove the unrelated list of OCSP extnsions.

Section 2.1

I'm happy to see the discussion with Barry about mandating the behavior
of new clients more tightly without breaking old clients.

   A server MUST reject any OCSP request having a Nonce extension with
   length of 0 octets or more than 32 octets with the malformedRequest
   OCSPResponseStatus as described in section 4.2.1 of [RFC6960].

(same nit about exactly which length is being constrained.)

Section 3.1

(side note) the bit about the Nonce being optional in the response even
if it was present in the request is actually in 6960 itself if you read
carefully; 5019 has a bit more exposition on it but may not, strictly
speaking, be a necessary reference.

Section 5.x

[I expect that the RFC Editor will adjust the formatting/wording a bit,
especially since "old syntax" and "new syntax" in the context of 1998
vs. 2008 ASN.1 syntax is probably going to make people think ASN.1, as
opposed to "OLD text" and "NEW text" or just "OLD"/"NEW".]