Re: [auth48] AUTH48: RFC-to-be 9530 <draft-ietf-httpbis-digest-headers-13> for your review

[Madison Church <[e-mail]>]

Hi Authors,

This is another friendly reminder that we await answers to the followup questions below and your review of the document before continuing with the publication process. 

Thank you!
RFC Editor/mc

> On Dec 14, 2023, at 8:39 AM, Madison Church <[e-mail]> wrote:
> 
> Hi Authors,
> 
> This is just a friendly reminder that we await answers to the followup questions below and your review of the document before continuing with the publication process. 
> 
> Thank you!
> RFC Editor/mc
> 
>> On Dec 7, 2023, at 9:05 AM, Madison Church <[e-mail]> wrote:
>> 
>> Hi Lucas,
>> 
>> Thank you for your reply! We have updated the document accordingly.
>> 
>> We have a few followup questions/comments.
>> 
>> For question 8:
>>> 8) <!-- [rfced] Please clarify "can remove or recalculate and substitute". 
>>> If substitution can happen after either removal or recalculation, 
>>> we suggest adding 'then' as follows.
>>> 
>>> Original:
>>>  In the absence of additional
>>>  security mechanisms, an on-path, malicious actor can remove or
>>>  recalculate and substitute a digest value.
>>> 
>>> Perhaps:
>>>  In the absence of additional
>>>  security mechanisms, an on-path, malicious actor can remove or
>>>  recalculate and then substitute a digest value. -->
>>> 
>>> The intent here is "actor can either A or B", specifically they can either remove entirely (A) or recalculate & substitute (B). Remove & substitute (with some bogus value) isn't a valid threat because of the design. Would phrase this as the following make things clearer?
>>> 
>>> Perhaps:
>>>  In the absence of additional
>>>  security mechanisms, an on-path, malicious actor can either remove or
>>>  a digest value entirely, or substitute it with a new digest value computed over
>>>  manipulated representation data or content.
>> 
>> Thank you for the clarification! We have updated the document using your suggested text with just a few alterations to improve sentence flow (removing commas). Please let us know any objections.
>> 
>> Current:
>> In the absence of additional
>> security mechanisms, an on-path malicious actor can either remove a
>> digest value entirely or substitute it with a new digest value
>> computed over manipulated representation data or content.
>> 
>> 
>> For question 10b:
>>> 
>>> 10) <!-- [rfced] References
>>> 
>>> b) The following reference has a Warning Notice stating that the
>>> publication has been "withdrawn (archived)". Please let us know if 
>>> any updates are needed.
>>> 
>>> Original:
>>> [NIST800-32]
>>>          National Institute of Standards and Technology, U.S.
>>>          Department of Commerce, "Introduction to Public Key
>>>          Technology and the Federal PKI Infrastructure", February
>>>          2001, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
>>>          nistspecialpublication800-32.pdf>. 
>>> 
>>> I'm not 100% sure what to do here. I asked some folks with better knowledge of crypto if they can recommend a better citation.
>> 
>> Noted! Let us know what you find out, and we will update the document accordingly at that time.
>> 
>> 
>> For question 16e:
>>> e) The following terms use <tt> tags inconsistently throughout the
>>> document. Please review the usage of <tt> and let us know if any 
>>> updates are needed.
>>> 
>>> Byte Sequence
>>> Remove <tt> for all these
>>> 
>>> Content-Digest
>>> Apply <tt> for all these
>>> 
>>> Dictionary
>>> Remove <tt> for all these 
>>> 
>>> Digest (field)
>>> Apply <tt> for all these 
>>> PATCH (when referring to PATCH requests)
>>> Remove <tt> for all these  
>>> Repr-Digest  
>>> Apply <tt> for all these
>>> 
>>> Want-Digest
>>> Apply <tt> for all these 
>>> 
>>> Want-Repr-Digest 
>>> Apply <tt> for all these
>> 
>> In addition to updating the terms above, we have applied <tt> tags to instances of Want-Content-Digest for consistency. Also, we have added <tt> tags around Digest where it appears in figure titles and section titles; please review whether each instance is referring to the field and let us know which instances (if any) should be reverted.
>> 
>> 
>> For the following:
>>> LP 3) Section 6.3 gnarly digests' 
>>> 
>>> Original:
>>> Any mangling of Integrity fields, including digests' de-duplication
>>> or combining different field values (see Section 5.2 of [HTTP])
>>> might affect signature validation.
>>> 
>>> RFC Editor:
>>> Any mangling of Integrity fields, including the digests' de-duplication
>>> or combination of different field values (see Section 5.2 of [HTTP])
>>> might affect signature validation.
>>> 
>>> Both of these forms are pretty gnarly and I still find hard to read (the clarity from stepping away from the text for 6 months :-) ) WDYT to this instead?
>>> 
>>> Proposed:
>>> Any mangling of Integrity fields might affect signature validation. For example, de-duplicating digests or combining different field values (see Section 5.2 of [HTTP]).
>> 
>> Thank you for the clarification! Would either of the following suggestions work?
>> 
>> Perhaps:
>> Any mangling of Integrity fields might affect signature validation, for 
>> example, de-duplicating digests or combining different field values 
>> (see Section 5.2 of [HTTP]).
>> 
>> Or:
>> Any mangling of Integrity fields might affect signature validation. 
>> Examples of such mangling include de-duplicating digests or combining 
>> different field values (see Section 5.2 of [HTTP]).
>> 
>> 
>> Updated XML file:
>>  https://www.rfc-editor.org/authors/rfc9530.xml
>> 
>> Updated output files:
>>  https://www.rfc-editor.org/authors/rfc9530.txt
>>  https://www.rfc-editor.org/authors/rfc9530.pdf
>>  https://www.rfc-editor.org/authors/rfc9530.html
>> 
>> Diff file showing all changes made during AUTH48:
>>  https://www.rfc-editor.org/authors/rfc9530-auth48diff.html
>> 
>> Diff files showing all changes:
>>  https://www.rfc-editor.org/authors/rfc9530-diff.html
>>  https://www.rfc-editor.org/authors/rfc9530-rfcdiff.html (side-by-side diff)
>>  https://www.rfc-editor.org/authors/rfc9530-alt-diff.html (diff showing changes where text is moved or deleted)
>> 
>> Note that it may be necessary for you to refresh your browser to view the most recent version. 
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9530
>> 
>> Thank you!
>> RFC Editor/mc
>