[Last-Call] Re: [lamps] Re: [EXTERNAL] Artart telechat review of draft-ietf-lamps-ocsp-nonce-update-06

Corey Bonnell <Corey.Bonnell=40digicert.com@xxxxxxxxxxxxxx> · Mon, 6 May 2024 20:56:18 +0000

I suggest creating an example OCSP response (and corresponding dumpasn1 output) with a correctly encoded Nonce extension in an appendix. The text in that paragraph could probably be clarified, but this is one of those times where an ASN.1 dump is worth 1,000 words.

Thanks,
Corey

From: Tomas Gustavsson <Tomas.Gustavsson@xxxxxxxxxxxxx> 
Sent: Monday, May 6, 2024 2:56 PM
To: Himanshu Sharma <himanshu=40netskope.com@xxxxxxxxxxxxxx>; Jim Fenton <fenton@xxxxxxxxxxxxxxx>
Cc: art@xxxxxxxx; draft-ietf-lamps-ocsp-nonce-update.all@xxxxxxxx; last-call@xxxxxxxx; spasm@xxxxxxxx
Subject: [lamps] Re: [EXTERNAL] Artart telechat review of draft-ietf-lamps-ocsp-nonce-update-06

Trying to be more helpful. 

Jim: We need good terminology that clearly separates the "Nonce Extension Value" from the "Nonce bytes/octets". In the past the word value was being used interchangeably, which lead to confusion.

I'm not sure what this terminology should be, which is why it ended up specifying "octets" perhaps annoyingly often (partly due to my persistence on this specific issue).

Cheers;
Tomas

From: Tomas Gustavsson <Tomas.Gustavsson@xxxxxxxxxxxxx>
Sent: Monday, May 6, 2024 8:46 PM
To: Himanshu Sharma <himanshu=40netskope.com@xxxxxxxxxxxxxx>; Jim Fenton <fenton@xxxxxxxxxxxxxxx>
Cc: art@xxxxxxxx <art@xxxxxxxx>; draft-ietf-lamps-ocsp-nonce-update.all@xxxxxxxx <draft-ietf-lamps-ocsp-nonce-update.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; spasm@xxxxxxxx <spasm@xxxxxxxx>
Subject: [lamps] Re: [EXTERNAL] Artart telechat review of draft-ietf-lamps-ocsp-nonce-update-06 

I think this encodes exactly the confusion that has lead to implementation issues. "Nonce will be identified by the object identifier id-pkix-ocsp- nonce, while the extnValue is the encoded value of Nonce. If the Nonce extension is present, 

I think this encodes exactly the confusion that has lead to implementation issues.

"Nonce will be identified by the object identifier id-pkix-ocsp-
   nonce, while the extnValue is the encoded value of Nonce.  If
   the Nonce extension is present, then the length of the Nonce value
   MUST be at least 1 octet and can be up to 128 octets."

"Nonce value" (1-128 octets) here is easily confused with "extnValue is the encoded value", which is longer (1-128 octets plus ASN.1 encoding bytes).
So I think that change will lead to the confusion that we wish to avoid.

Regards,
Tomas

From: Himanshu Sharma <himanshu=40netskope.com@xxxxxxxxxxxxxx>
Sent: Monday, May 6, 2024 8:42 PM
To: Jim Fenton <fenton@xxxxxxxxxxxxxxx>
Cc: art@xxxxxxxx <art@xxxxxxxx>; draft-ietf-lamps-ocsp-nonce-update.all@xxxxxxxx <draft-ietf-lamps-ocsp-nonce-update.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; spasm@xxxxxxxx <spasm@xxxxxxxx>
Subject: [lamps] Re: [EXTERNAL] Artart telechat review of draft-ietf-lamps-ocsp-nonce-update-06 

Hi Jim We are using the word "Nonce octets" to show the clear difference between "Nonce: the complete encoded extension" vs "Nonce octet: value of the Nonce that gets encoded. " All the previous RFCs had this confusion 
Hi Jim 
   We are using the word "Nonce octets" to show the clear difference between "Nonce: the complete encoded extension" vs "Nonce octet:  value of the Nonce that gets encoded." 
All the previous RFCs had this confusion and developers interpreted these values wrongly in some implementations. 
Will it fine if I use "Nonce value" instead of "Nonce octets" for example 

"Nonce will be identified by the object identifier id-pkix-ocsp-
   nonce, while the extnValue is the encoded value of Nonce octets.  If
   the Nonce extension is present, then the length of the Nonce octets
   MUST be at least 1 octet and can be up to 128 octets."

will be represented as:

"Nonce will be identified by the object identifier id-pkix-ocsp-
   nonce, while the extnValue is the encoded value of Nonce octets.  If
   the Nonce extension is present, then the length of the Nonce value octets
   MUST be at least 1 octet and can be up to 128 octets."

Please let me know your thoughts.

-Himanshu

On Mon, May 6, 2024 at 11:07 AM Himanshu Sharma <himanshu@xxxxxxxxxxxx> wrote:
Thanks Jim for the review and feedback. I will update the draft to address the review comments soon. 

-Himanshu

On Fri, May 3, 2024 at 12:52 PM Jim Fenton via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Jim Fenton
Review result: Ready with Nits

I am the designated ARTART reviewer for this draft. This is a re-review of -06
following my review of -04.

Status: Ready with Nits

Thanks for addressing basically all of my comments from my earlier review. This
is ready to go, although I spotted a few more instances of the overuse of
"octets" in Section 2.1 that result in some awkward wording. Examples and
suggested replacements:

"...while the extnValue is the encoded value of Nonce octets" -> "...while the
extnValue is the encoded value of the nonce"

"...then the length of the Nonce octets MUST be..." -> "...then the length of
the nonce MUST be..."

"...MUST use a minimum length of 32 octets for Nonce octets in the Nonce
extension." -> "...MUST use a minimum length of 32 octets for the nonce in the
nonce extension."

"...that has a Nonce octets with a length..." -> "...that has a nonce with a
length..."

"The value of the Nonce octets MUST be..." -> "The value of the nonce MUST
be..."

"

<<attachment: smime.p7s>>
-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx