| Jim:
Sorry. I did not realize that I was replying to a message that was being sent as part of the mailman3 transition backlog.
So, I reread the thread and I reread version -09 of the Internet-Draft. I am now even more confused. I do not see any place where two things are being concatenated to produce the Nonce value. Maybe this has already been sorted by removing something.
Russ
On May 21, 2024, at 2:34 PM, Jim Fenton <fenton@xxxxxxxxxxxxxxx> wrote:
[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
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
|
