Re: [secdir] [EXTERNAL] Secdir last call review of draft-ietf-lamps-ocsp-nonce-update-04

[Himanshu Sharma <[e-mail]>]

Hi Joseph,
  As discussed offline, explained and agreed upon the reason for choosing
the 32 bytes primarily for backward compatibility, and explained about the
behavior of ocsp client in case of response that doesn't contain nonce from
responder.
I have updated the ID (
https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce-update/05/)
according to your and other reviewr's suggestions.
Russ helped in verification of ASN.1 modules and it compiles fine.

I believe it satisfies all the outstanding questions.
 Please let me know if there are still any outstanding questions that I can
answer in order to get the approval.

Thanks
Himanshu




On Sun, Mar 31, 2024 at 12:21 PM Joseph Salowey via Datatracker <
[e-mail]> wrote:

> Reviewer: Joseph Salowey
> Review result: Has Issues
>
> 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.
>
>
>