Hi Joseph
In case the updated I-D was missed, I am trying to put the email on top.
Here I am summarizing our off-line discussion so that everyone in the group will be on the same page.
[Joe] So 32 bytes will hopefully help interoperability.
[HS] Yes, I mentioned and explained the decision and discussion related to RFC8954 and keeping the same Nonce length recommendation (32 bytes) for interoperability purposes. I believe that the concern related to length of 32 bytes has been addressed.
[Joe] I think it is better to have a MUST. It should result in better interoperability. (referring the section 2.1 para 2)
[HS] I have updated I-D to version 05 to include the "MUST" inplace of "SHOULD" As per your feedback and discussion.
Now I-D 05 mentions
"An OCSP client that implements this document MUST use a minimum
length of 32 octets for Nonce octets in the Nonce extension. "
[Joe] With current deployed behavior servers can choose not to support the nonce extension and ignore it. For servers that do support the nonce extension would it be acceptable to say that they have to respond to the nonce extension if it is between 16 and 128 bytes? Or are there servers that will just ignore nonces greater that 32 bytes (instead of sending an error).
[HS] With this Draft we are making sure that the server that supports Nonce, MUST support the nonce between 16-32 and may choose to ignore the nonce between 1-to-16 and 33-to-128 bytes.
[Joe] What do clients typically do if they do not get a nonce in response, do they reject the response?"
[HS] Most of the clients just log a warning message and accept the response. As few public responders do not support nonce for performance reasons.
I believe the I-D 05 version (https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce-update/05/) addresses your concerns. Please let me know if there is any outstanding concern that I can answer.
-Himanshu
On Thu, Apr 4, 2024 at 11:58 AM Himanshu Sharma <himanshu@xxxxxxxxxxxx> wrote:
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.ThanksHimanshuOn Sun, Mar 31, 2024 at 12:21 PM Joseph Salowey via Datatracker <noreply@xxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
