I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is has issues.  I'm probably just missing some history/context, here are the items that stood out.   

1. The document states "An OCSP client that implements this document SHOULD use a minimum length of 32 octets for Nonce octets in the Nonce extension."  How was the minimum of 32 bytes chosen? This seems like it might be longer than necessary. Is there a security reason for this or a different reason? Later in the document it states receiver MUST accept at least 16 octets.  

2. In addition, the SHOULD should say when it is acceptable not to follow it. When is it OK for an implementation to send less than 32 bytes?  For example, you could rephrase this as "clients MUST use a minimum length of 32 octets unless they are configured to interoperate with a OCSP responder that requires a shorter nonce length or ... ".  Also if a client uses more than 32 bytes their request may be ignored. 

3. An 8954 server will respond to greater than 32 octet nonce with a malformedRequest. The client can report this and indicate that perhaps it needs to be configured to talk to an 8954 server.  
The text goes further to say that the server MAY ignore nonces greater than 32 and less than 16 octets. Does this mean that the response does not contain the nonce? What should the client do in this case? Why even allow responders to ignore a nonce that is greater than 32 octets?  

4. I took a look at the ASN.1, it looks OK to me, but I'm a bit rusty. I assume that it was reviewed by the working group, it not then someone with more recent ASN.1 experience should look at it.