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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[trying to recall this after the delivery delay]

Is the issue my use of the word “extension”? If so, it is because I didn’t realize that it conflicted with other things. Other words should be chosen then. Perhaps (not entirely seriously):

BigNonce == Nonce || MoreNonce

-Jim

On 21 May 2024, at 11:08, Russ Housley wrote:

Jim:

I do not think that this would be helpful:

Extended Nonce == Nonce || Nonce Extension Value

Extensions in ASN.1 protocols are used in many places, inclusing Certificates, CRL, OCSP Requests, and OCSP Responses.

In all cases, they use the same syntax.  From RFC 2459 (the first RFC to use Extension), the syntax is::

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }

Then, RFC 2459 says:

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue.  Only one instance of a particular
   extension may appear in a particular certificate. For example, a
   certificate may contain only one authority key identifier extension
   (see sec. 4.2.1.1).  An extension includes the boolean critical, with
   a default value of FALSE.  The text for each extension specifies the
   acceptable values for the critical field.

So, the proposed text would be very misleading to an implementer.

Russ

On May 6, 2024, at 3:07 PM, Jim Fenton <fenton@xxxxxxxxxxxxxxx> wrote:

Thanks for your clarification, Tomas. I don’t have any history with the document, so I wasn’t familiar with the potential confusion.

It did seem to be using “octets” annoyingly often; I think of octets as a sort of unit of measure. I think it’s important to make sure the document is readable by outsiders like myself, so I would prefer some more descriptive words here. I’m sure the wg has thought about this a lot more than I have, but the sort of terminology I have in mind is something like:

Extended Nonce == Nonce || Nonce Extension Value

-Jim

On 6 May 2024, at 11:55, Tomas Gustavsson wrote:

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..."

"



--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux