Re: AD Review of draft-ietf-httpbis-message-signatures-15

Hi Francesca,

Thanks again for the thorough review, we have published draft -16 to incorporate your feedback, and I believe this is ready for IETF LC:

Name: draft-ietf-httpbis-message-signatures
Revision: 16
Title: HTTP Message Signatures
Document date: 2023-02-06
Group: httpbis
Pages: 108
URL:            https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-16.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

Html:           https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-16.html

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures

Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-message-signatures-16


— Justin

On Feb 1, 2023, at 10:36 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi Justin,

Thanks! I have reviewed the PRs and I consider my comments addressed – I also don’t think any of these were significant changes, but as you mentioned in separate mail threads/github issues it is good to hear if anybody in the working group objects.

No worry about the ref issue, at worst we will fix it with the RFC Editor.

Please go ahead and merge + submit a new version, so in a couple of days (time for others in the wg to react if they wish) I can request the IETF LC.

Thanks,
Francesca

From: Justin Richer <jricher@mit.edu>
Date: Tuesday, 24 January 2023 at 18:17
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: AD Review of draft-ietf-httpbis-message-signatures-15
Hi Francesca,

Thanks for the thorough AD review. I’ve gone through the items and have addressed most of the concerns in a series of PRs:

https://github.com/httpwg/http-extensions/pulls?q=is%3Apr+is%3Aopen+label%3Asignatures<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-93bb8814568a0e96&q=1&e=cbece33b-a96b-4905-a31b-e995ba197ea7&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fpulls%3Fq%3Dis%253Apr%2Bis%253Aopen%2Blabel%253Asignatures>

Would you like to look through the changes in the PR form first, or would you like me to merge and create a new document for review? Either works for me.

One issue of yours remains open after the above changes are accepted: The reference to RFC7545 seems to be a tooling error, since the source text only references BCP19 and is supposed to pull in the latest copy of the reference automatically. This is being discussed in this issue:

https://github.com/httpwg/http-extensions/issues/2369<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-aea75c9c60280c4c&q=1&e=cbece33b-a96b-4905-a31b-e995ba197ea7&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fissues%2F2369>

If you think it would avoid hiccups during IESG review, I can just put in the reference to RFC9325 directly instead of referring to the BCP. Otherwise, we can just wait for the tooling to get untangled. This probably isn’t the only spec that’s affected by this in process right now, I’d imagine.

 — Justin


On Jan 9, 2023, at 4:38 PM, Francesca Palombini <francesca.palombini@ericsson.com<mailto:francesca.palombini@ericsson.com>> wrote:

# AD Review of draft-ietf-httpbis-message-signatures-15

cc @fpalombini

Thank you to the authors and working group for another well written document. Also, I appreciate the several examples throughout the document, they make the text even more clear and easy to read.

I don't have many comments, mostly minor and nits. I do have one comment about the reference to HTMLURL that we should probably fix before the IETF Last Call is started. The rest of the comment and questions you can address together with any other IETF Last Call comments. Feel free to take or leave, however answers are appreciated.

Francesca

## Comments

### Absent query

Section 2.2.7:
>If the query string is absent from the request message, the value is the leading ? character alone:

When would it make sense to sign this component although empty? Might be good to add some clarification for the reader.

### IANA registry names inconsistencies

Section 2.3:
>alg: The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as a String value.

Section 3.2:
>If the algorithm is explicitly stated in the signature parameters using a value from the HTTP Message Signatures registry, the verifier will use the referenced algorithm.

Section 3.3:
>through mutual agreement between the signer and verifier. Signature algorithms selected using the alg parameter MUST use values from the HTTP Message Signature Algorithms Registry (Section 6.2).

Section 3.3.7:
>algorithm values are not registered in the HTTP Message Signature Algorithms Registry (Section 6.2), and so the explicit alg signature

Section 7.3.1:
>used to sign HTTP messages. The HTTP Message Signatures Algorithm Registry is one source of trusted signature algorithms for applications to apply to their messages.

I believe all of the above should refer to HTTP Signature Algorithms Registry instead (I hope I caught all of them)

Section 2.2:
> Additional derived component names are defined in the HTTP Signatures Derived Component Name Registry. (Section 6.4)

Should be HTTP Signature Derived Component Names Registry

Section 2.3:
> Additional parameters can be defined in the HTTP Signature Parameters Registry (Section 6.3.2). Note that there is no general ordering to

Should be HTTP Signature Component Parameters Registry - Also it would be better to reference 6.3 rather than 6.3.2.

### Accept clarification question

Section 5.1:
>algorithm or key identifier. These parameters MUST NOT include parameters that the signer is expected to generate, such as the created parameter.

Why should it not? Couldn't the verifier include these empty parameters to indicate that the signer is expected to generate and send them?

### Missing expert guidelines

The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See section 4.5 of RFC8126:

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.

### Define deprecated

I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.

### Wrong ref

Section 2.1:
> Additional parameters can be defined in the registry established in Section 6.3.

I believe it should be 6.5. Also it would be good to name the HTTP Signature Component Parameters Registry explicitely.

### Reference to RFC7525

Obsolete informational reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325). Please update.

### Reference to HTMLURL

Thanks to Tommy for detailed shepherd write up, that tells me you have discussed this already.
Seems obvious that the HTMLURL reference needs to be normative, so we might need to reference a snapshot of this instead.

See the following text in the IESG statement: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/


> Note 4: Normative references in RFCs cannot be to "work in progress" documents such as Internet Drafts. Drafts with such references will not be published as RFCs until the references are also published.

I'd like to get this fixed before starting the Last Call.

## Nits

### Editorial Nits

Section 3.1:
>several concrete applications of signing algorithms are defined in in Section 3.3.

s/in in/in

Section 3.3:
>The following sections contain several common signature algorithms and demonstrates how these cryptographic primitives map to the

s/demonstrates/demonstrate

Section 3.3.7:
>other mechanisms common to JOSE implementations. In fact, and JWA algorithm values are not registered in the HTTP Message Signature Algorithms Registry (Section 6.2), and so the explicit alg signature

s/and JWA algorithm values/JWA algorithm values

Section 5.1:
>message signature. The member's name is label that uniquely identifies the requested message signature within the context of the

s/is label/is the label

Section 7.4.3:
>verifier has access to. Both signers and verifiers need to take carefully consider the source of all information when creating

s/take carefully/carefully

Section 7.5.2:
>The verifier would have have a difficult time finding this class of errors since the value of the

s/have have/have

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9faa09361356e426&q=1&e=cbece33b-a96b-4905-a31b-e995ba197ea7&u=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments%2Fblob%2Fmain%2Fformat.md>
[ICT]: https://github.com/mnot/ietf-comments<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-85de72c60dc0c7a6&q=1&e=cbece33b-a96b-4905-a31b-e995ba197ea7&u=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments>