> On Nov 26, 2019, at 2:54 PM, Rene Struik <[email protected]> wrote:
>
> Dear Russ:
>
> Thanks for your review (and speedy turn-around).
>
> Please find below feedback on how I intend to address all but your last
> remarks (I will reflect on your suggestion as to introductory text with the
> appendices when looking over Daniel Migault's earlier "guidance of the
> reader" remarks).
>
> Best regards, Rene
>
> On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote:
>> Reviewer: Russ Housley
>> Review result: Has Issues
>>
>> I 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 authors, document editors, and WG chairs should
>> treat these comments just like any other IETF Last Call comments.
>>
>> Document: draft-ietf-lwig-curve-representations-08
>> Reviewer: Russ Housley
>> Review Date: 2019-11-26
>> IETF LC End Date: unknown
>> IESG Telechat date: unknown
>>
>> Summary: Has Issues
>>
>>
>> Major Concerns:
>>
>> I am confused by the first paragraph in Section 10. It says that "An
>> object identifier is requested ...", but then code points for COSE
>> and JOSE (not object identifiers) are requested in the subsection.
>>
>> I am confused by the second paragraph in Section 10. It says that
>> "There is *currently* no further IANA action required ...". Please
>> delete this paragraph.
>
> RS>> If I remember this correctly, I borrowed this from another draft (but
> perhaps was somewhat ignorant here about proper formulation). I intend to
> change the first para to "code points are requested for ....". As to the
> second para, I believe it has some merit to keep this in, in slightly altered
> form, e.g., as "New object identifiers would be required in case one wishes
> to specify one or more of the "offspring" protocols exemplified in Section
> 4.4. Specification hereof is, however, outside scope of the current document."
>
> <<RS
I do not see how the second paragraph gives any direction regarding the IANA
registries.
>
>> Minor Concerns:
>>
>> Requirements Language section is out of date. It should reference
>> RFC 8174 in addition to RFC 2119, as follows:
>>
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>> "OPTIONAL" in this document are to be interpreted as described in
>> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>> capitals, as shown here.
>
> RS>> will do. As minor point (from a non-native speaker's perspective):
> shouldn't the last part of the above sentence read "if, and only if, these
> appear...."? <<RS
RFC 8174 calls for this exact text.
>
>> Section 2 says: "... reuse of existing generic code ..."; I do not know
>> what is meant by "generic". It either needs to be defined, reworded, or
>> dropped. I note that elsewhere in the document "existing code" is used.
> RS>> I will add a sentence to that effect, e.g., "(Here, generic code refers
> to an implementation that does not depend on hardcoded domain parameters (see
> also Section 6).)" <<RS
Thanks.
>>
>> I expected Section 9 to say something about public keys being unique
>> identifiers of the private key holder.
>
> RS>> I will add an extra paragraph to this effect, e.g., "Use of a public key
> in any protocol for which successful execution evidences knowledge of the
> corresponding private key implicitly indicates the entity holding this
> private key. Reuse of this public key with more than one protocol or more
> than one protocol instantiation may, therefore, allow traceability of this
> entity." <<RS
Also, using the same public key with different addresses allows an observer to
correlate them.
>
>>
>> Some introduction text at the beginning of each Appendix would be very
>> helpful. Please tell the reader what they will learn by delving into
>> the subsections of the appendix.
> RS>> I will reflect on this somewhat more (while also considering "guidance
> to the reader" remarks in Daniel Migault's Early IoTDir review). Broadly
> speaking, though, inclusion of all these appendices makes the entire docment
> self-contained, including arithmetic, representations, how-to-convert
> details, etc. <<RS
Yes, I understand that. Some of the appendicies have introductory text, but
other do not. I think they all should have introductory text.
>> Nits:
>>
>> Section 4.2 says: "... at the end of hereof ...". This does not tell
>> me anything useful. I suggest deleting this phrase.
> RS>> I will change this to "at the end hereof" (i.e., will remove "of" - a
> glitch). Here, one can only recover the y-coordinate at the end of the
> Montgomery ladder, since one needs the x-coordinates of k*G and (k+1)*G to
> make this work. <<RS
I think it would be better to say: ... at the end of the Montgomery ladder ..."
Russ
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
