HTTP Message Signatures
draft-ietf-httpbis-message-signatures-19

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-httpbis-message-signatures and RFC 9421, changed IESG state to RFC Published)

[Ballot comment]
Thanks to Harald T. Alvestrand for his ARTART review.

I support Roman's DISCUSS position.

[My review is not complete, so I am not selecting a ballot position yet.]

[Ballot discuss]
I am raising a similar argument as Martin Duke left in his COMMENT feedback.

** Section 6.2.  HTTP Signature Algorithms Registry.

-- What is the difference between how this “Expert Review” registration guidance as written (of being a DE review + spec) and one that is “Specification Required”.  Both appear to require an expert review and a specification.

-- What does “Active” mean?  “Deprecated” is framed as the algorithm is “no longer recommended for use and might be insecure or unsafe”.  Does “Active” mean “recommended and secure/safe”?  Is the DE responsible for assessing the cryptographic properties of new registration?  Is that a realistic expectation? 

Subsequent language in Section 7.3.1 suggests that the registry is the source of “trust signature algorithms”:
  To counter this, only vetted keys and signature algorithms should be
  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.

Should a mechanism like the “Recommended” column in the TLS registries be used:

“If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that
the item either has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use
cases.”

[Ballot comment]
** Section 1.1
  The term "Unix time" is defined by [POSIX.1], Section 4.16
  (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
  V1_chap04.html#tag_04_16)

That URL should be a reference.

** Section 1.4.
  Historical
  systems, such as [AWS-SIGv4], can provide inspiration and examples of
  how to apply similar mechanisms in a secure and trustable fashion.

With due respect to AWS, is this too strong of a statement of a system not evaluated by the IETF?

** Section 2.  Editorial.  s/a the raw query string/a raw query string/

** Section 2.
Message component values must therefore be canonicalized

Should this be “Message component values MUST ...?

** Section 2.1
  Other encodings could exist
  in some implementations, and all non-ASCII field values MUST be
  encoded to ASCII before being added to the signature base.

Is there a standardized way to do this canonicalization to ASCII?

** Section 2.1
  Specifically, HTTP fields
  sent as multiple fields MUST be combined using a single comma (",")
  and a single space (" ") between each item.

Recommend making this text clear.  I initially read it as space on either side of the comma (because it said “between each item”).  The intent from Section 5.2 of [HTTP] appears to be “concatenate a ‘,’ + ‘ ‘” between items.

** Section 2.1.3.  Editorial. Recommend adding an explicit reference to Byte Sequences per Section 3.3.5 of RFC8941.  Perhaps in step 3.4.

** Section 2.3.  Provide a formal reference to “UNIX timestamp”.  Perhaps:  IEEE Std 1003.1-2017 (https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html)

** Section 2.3.  Editorial.  Consider using a date in 2023 for the example (instead of 2021).

** Section 2.3.  I didn’t find any guidance in the text around setting the “expires” signature parameter.  However, many of the non-normative example seem to use 300 seconds (5 minutes).  What is the basis of that value?  Is there a recommendation on how to reason about setting the expiration?

** Section 3.1
3.  If applicable, the signer sets the signature's expiration time
      property to the time at which the signature is to expire.  The
      expiration is a hint to the verifier, expressing the time at
      which the signer is no longer willing to vouch for the safety of
      the signature.

What is “safety of the signature”?  Is this safety window measured in 5 minutes, like in the various examples?

** Section 3.3.
  An HTTP Message signature MUST use a cryptographic digital signature
  or MAC method that is appropriate for the key material, environment,
  and needs of the signer and verifier.  This specification does not
  strictly limit the available signature algorithms, and any signature
  algorithm that meets these basic requirements MAY be used by an
  application of HTTP message signatures.

It is unclear what the normative MUST and MAY are prescribing.  Recommend not using the RFC2119 language here.

-- Per sentence 1, Lacking any context, “appropriate for the …” seems entirely subjective.  My judgement on what’s appropriate may not be yours.

-- Per sentence 2, what are the “basic requirements”?

** Section 3.3.7.
  If the signing algorithm is a JOSE signing algorithm from the JSON
  Web Signature and Encryption Algorithms Registry established by
  [RFC7518], the JWS algorithm definition determines the signature and
  hashing algorithms to apply for both signing and verification.

I don’t understand this guidance.  Don’t the signing algorithms have to be pulled from the (new) “HTTP Signature Algorithm” registry?

** Section 5.1.  Editorial.  Should a reminder be added to the alg field that the values come from the HTTP Signature Algorithms registry

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-httpbis-message-signatures-17

Thank you for the work put into this document. This I-D is not in my area of technical expertise, so the review is only high-level and focused on the Internet aspects.

I especially like the possibility to have multiple signatures.

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-httpbis-message-signatures-17
CC @jgscudder

Thanks for this thorough and well-written spec. Although I haven't done anything like a detailed line-by-line review of it, I noticed a few minor things to comment on (some are just proofreading), I hope some of these are helpful.

## COMMENTS

### General, keyword rendering

You have numerous keywords identified in the source by enclosing them in <tt></tt>. This works well (or well enough) to distinguish them for what they are in the HTML rendering, but unfortunately in the txt rendering, xml2rfc does exactly and only what RFC 7991 says: renders them in a constant-width font. Since in the txt rendering, everything else is in a constant-width font too (or to split hairs, really no font information is present) this means there's nothing at all to distinguish the keywords you've gone to the trouble of identifying in your source, in the txt rendering, <tt> is basically a no-op.

For the most part this is OK, context makes it clear enough, but I noticed one place where it creates ambiguity in the txt rendering. In Section 1.4, first bullet, you have

                                                For example, an
      authorization protocol could mandate that the Authorization field
      be covered to protect the authorization credentials and mandate
      the signature parameters contain a created parameter,
     
In this case, there's nothing to cue a reader that "created" is the name of a particular parameter, and not an adjective being used to describe "parameter".

This isn't a huge problem even in this case, and I haven't identified any more-problematic instances (although I've made no effort to audit all 448 <tt> uses). Arguably this is something for the RSWG and not the authors at all, but I wanted to make sure you were aware of it. If you've only been reviewing the HTML rendering you may never have seen the issue.

### Section 1.1, quibble about "Unix time"

  The term "Unix time" is defined by [POSIX.1], Section 4.16

The string "Unix time" never appears in the reference. Though the text is correct as written, if closely parsed, it might be nice to write it a little more bluntly, as in

  The term "Unix time" refers to what [POSIX.1], Section 4.16 calls
  "Seconds Since the Epoch."
 
### Section 2.5, imprecision in step (2)(1)

      1.  Check that the component identifier (including its
          parameters) has not already been added to the signature base.
          If this happens, produce an error.

I think a close and uncharitable reading of this step leaves "this" without a clear referent. It's clear enough from context what you mean, so I'm not really worried, but it's nice for algorithms to be as unambiguous as possible. Perhaps something like

      1.  If the component identifier (including its
          parameters) has already been added to the signature base,
          produce an error.

would do the job.

### Section 2.5, even nittier nit in (2)(5) bullet 2

          *  If the component identifier has several incompatible
              parameters, such as bs and sf, produce an error.

Perhaps replace "several" with "two or more" or rewrite as "... has parameters that are mutually incompatible" or "... has parameters that are incompatible with one another".

### Section 2.5, another nit

  If covered components reference a component identifier that cannot be
  resolved to a component value in the message, the implementation MUST
  produce an error and not create a signature base.  Such situations
  are included but not limited to:

Last line should be something like "include, but are not limited to:"

### Section 6.2, spurious "are"

  The Designated Expert (DE) is expected to ensure that the algorithms
  referenced by a registered algorithm identifier are fully defined
  with all parameters (such as salt, hash, required key length, etc)
  are fixed by the defining text.  The DE is expected to ensure that

I think the "are" in "are fixed by the defining text" should be deleted.

### Section 8.4

  A possible mitigation for this specific situation would be for the
  intermediary to verify the signature itself, then modifying the
  message to remove the privacy-sensitive information. 
 
"then modifying" -> "and then modify"

## 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
[ICT]: https://github.com/mnot/ietf-comments</tt></tt>

[Ballot comment]
What is the position on including national crypto and other potentially compromised algorithms? Section 6.2 doesn't demand that the DE evaluate algorithm security, but section 7.3.1 says "The HTTP Message Signatures Algorithm Registry is one source of trusted signature algorithms for applications to apply to their messages."

I could see a case for including not-provably secure algorithms in the registry to avoid squatting, assuming they are fully specified, but if this were the case the registry probably needs a recommended/non recommended field.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-message-signatures-16. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

three new registrations are to be made as follows:

Field Name: Signature-Input
Template:
Status: permanent
Reference: [ RFC-to-be; Section 4.1 ]

Field Name: Signature
Template:
Status: permanent
Reference: [ RFC-to-be; Section 4.2 ]

Field Name: Accept-Signature
Template:
Status: permanent
Reference: [ RFC-to-be; Section 5.1 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the HTTP Signature Algorithms registry. Management of the registry will be done through the Expert Review process as defined by RFC8126.

There are initial registrations in the new registry as follows:

Algorithm Name Description Status Specification document(s)
rsa-pss-sha512 RSASSA-PSS using SHA-512 Active [ RFC-to-be; Section 3.3.1 ]
rsa-v1_5-sha256 RSASSA-PKCS1-v1_5 using SHA-256 Active [ RFC-to-be; Section 3.3.2 ]
hmac-sha256 HMAC using SHA-256 Active [ RFC-to-be; Section 3.3.3 ]
ecdsa-p256-sha256 ECDSA using curve P-256 DSS and SHA-256 Active [ RFC-to-be; Section 3.3.4 ]
ecdsa-p384-sha384 ECDSA using curve P-384 DSS and SHA-384 Active [ RFC-to-be; Section 3.3.5 ]
ed25519 Edwards Curve DSA using curve edwards25519 Active [ RFC-to-be; Section 3.3.6 ]

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

Third, a new registry is to be created called the HTTP Signature Algorithms registry. Management of the registry will be done through the Expert Review process as defined by RFC8126.

There are initial registrations in the new registry as follows:

Name Description Specification document(s)
alg Explicitly declared signature algorithm [ RFC-to-be; Section 2.3 ]
created Timestamp of signature creation [ RFC-to-be; Section 2.3 ]
expires Timestamp of proposed signature expiration [ RFC-to-be; Section 2.3 ]
keyid Key identifier for the signing and verification
keys used to create this signature
nonce A single-use nonce value [ RFC-to-be; Section 2.3 ]
tag An application-specific tag for a signature [ RFC-to-be; Section 2.3 ]

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

Fourth, a new registry is to be created called the HTTP Signature Derived Component Names registry. Management of the registry will be done through the Expert Review process as defined by RFC8126.

There are initial registrations in the new registry as follows:

Name Description Status Target Specification document(s)
@signature-params Reserved for signature parameters Active Request, [ RFC-to-be; Section 2.3 ]
line in signature base Response
@method The HTTP request method Active Request [ RFC-to-be; Section 2.2.1 ]
@authority The HTTP authority, or target host Active Request [ RFC-to-be; Section 2.2.3 ]
@scheme The URI scheme of the request URI Active Request [ RFC-to-be; Section 2.2.4 ]
@target-uri The full target URI of the request Active Request [ RFC-to-be; Section 2.2.2 ]
@request-target The request target of the request Active Request [ RFC-to-be; Section 2.2.5 ]
@path The full path of the request URI Active Request [ RFC-to-be; Section 2.2.6 ]
@query The full query of the request URI Active Request [ RFC-to-be; Section 2.2.7 ]
@query-param A single named query parametes Active Request [ RFC-to-be; Section 2.2.8 ]
@status The status code of the response Active Response [ RFC-to-be; Section 2.2.9 ]

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

Fifth, a new registry is to be created called the HTTP Signature Component Parameters registry. Management of the registry will be done through the Expert Review process as defined by RFC8126.

There are initial registrations in the new registry as follows:

Name Description Specification document(s)
sf Strict structured field serialization [ RFC-to-be; Section 2.1.1 ]
key Single key value of dictionary structured fields [ RFC-to-be; Section 2.1.2 ]
bs Byte Sequence wrapping indicator [ RFC-to-be; Section 2.1.3 ]
tr Trailer Section [ RFC-to-be; Section 2.1.4 ]
req Related request indicator [ RFC-to-be; Section 2.2.4 ]
name Single named query parameter [ RFC-to-be; Section 2.2.8 ]

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-message-signatures@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (HTTP Message Signatures) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP Message Signatures'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-02-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism for creating, encoding, and
  verifying digital signatures or message authentication codes over
  components of an HTTP message.  This mechanism supports use cases
  where the full HTTP message may not be known to the signer, and where
  the message may be transformed (e.g., by intermediaries) before
  reaching the verifier.  This document also describes a means for
  requesting that a signature be applied to a subsequent HTTP message
  in an ongoing HTTP exchange.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document spent a couple years in the working group, and got feedback from many
contributors, both from people specifically interested in signatures, as well as
the people involved in generic HTTP. It received quite careful review and I sense
it has broad agreement. The WGLC didn't receive many specific email responses, but
there was sufficient discussion on GitHub and in the meeting to confirm consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

At IETF 114, there was concern raised (by Chris Wood) that there should be more formal
analysis performed, akin to the process normally used in CFRG. This document was then
presented at IETF 115 in SAAG for broad discussion of formal analysis as well as to
get specific feedback on this document. The sense of that room was that formal
analysis was not a gating factor that is present for security documents, and the comments
about this document were positive. Separately, an academic formal analysis is ongoing,
but the chairs have decided to progress this document to the IETF and IESG in parallel
with that work.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are many implementations of earlier versions of signatures, and this version
has also received implementation and interop testing, which has been discussed and presented
to the working group. (Note that this is not documented in the document itself.)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document mainly overlaps with security area. It received an early SecDir
review last year, as well as extra reviews in the past month by security area
reviewers (such as Kyle Rose).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of the above apply. The document does add HTTP field registrations, but this
working group is appropriate to review those.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

This document does use ABNF, which has been checked and validated.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written in my opinion, and ready for hand-off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SecDir review has been conducted, as earlier noted.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, as this specifies a standard version of HTTP message signatures
(distinct from previous non-standard versions). The datatracker state and document
state are consistent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors and others have not disclosed any relevant IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors (3) are active in participation.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Current nits are only around normative downrefs, see below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

See https://github.com/httpwg/http-extensions/issues/2317

The following are listed as downrefs, but are part of the downref registry
(https://datatracker.ietf.org/doc/downref/) and should be thus accepted.

  ** Downref: Normative reference to an Informational RFC: RFC 2104
  ** Downref: Normative reference to an Informational RFC: RFC 6234
  ** Downref: Normative reference to an Informational RFC: RFC 8017
  ** Downref: Normative reference to an Informational RFC: RFC 8032

The following is a downref to a document also normatively referenced
in RFC 8292 and should be accepted:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'

The following is a downref that may not have other examples, but the
authors and chairs believe is an acceptable downref:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTMLURL'

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The normative references are available publicly.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

If the registry can contain non-RFC documents, we should consider adding
the FIPS186-4 and HTMLURL references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to Internet Drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change any RFC status.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registry changes look correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This creates the following new registries:
HTTP Signature Algorithms Registry
HTTP Signature Metadata Parameters Registry
HTTP Signature Derived Component Names Registry
HTTP Signature Component Parameters Registry

All use Expert Review as their process. The authors or other HTTPbis WG contributors
would be good candidates for acting as the experts.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document spent a couple years in the working group, and got feedback from many
contributors, both from people specifically interested in signatures, as well as
the people involved in generic HTTP. It received quite careful review and I sense
it has broad agreement. The WGLC didn't receive many specific email responses, but
there was sufficient discussion on GitHub and in the meeting to confirm consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

At IETF 114, there was concern raised (by Chris Wood) that there should be more formal
analysis performed, akin to the process normally used in CFRG. This document was then
presented at IETF 115 in SAAG for broad discussion of formal analysis as well as to
get specific feedback on this document. The sense of that room was that formal
analysis was not a gating factor that is present for security documents, and the comments
about this document were positive. Separately, an academic formal analysis is ongoing,
but the chairs have decided to progress this document to the IETF and IESG in parallel
with that work.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are many implementations of earlier versions of signatures, and this version
has also received implementation and interop testing, which has been discussed and presented
to the working group. (Note that this is not documented in the document itself.)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document mainly overlaps with security area. It received an early SecDir
review last year, as well as extra reviews in the past month by security area
reviewers (such as Kyle Rose).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of the above apply. The document does add HTTP field registrations, but this
working group is appropriate to review those.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

This document does use ABNF, which has been checked and validated.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written in my opinion, and ready for hand-off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SecDir review has been conducted, as earlier noted.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, as this specifies a standard version of HTTP message signatures
(distinct from previous non-standard versions). The datatracker state and document
state are consistent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors and others have not disclosed any relevant IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors (3) are active in participation.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Current nits are only around normative downrefs, see below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

See https://github.com/httpwg/http-extensions/issues/2317

The following are listed as downrefs, but are part of the downref registry
(https://datatracker.ietf.org/doc/downref/) and should be thus accepted.

  ** Downref: Normative reference to an Informational RFC: RFC 2104
  ** Downref: Normative reference to an Informational RFC: RFC 6234
  ** Downref: Normative reference to an Informational RFC: RFC 8017
  ** Downref: Normative reference to an Informational RFC: RFC 8032

The following is a downref to a document also normatively referenced
in RFC 8292 and should be accepted:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'

The following is a downref that may not have other examples, but the
authors and chairs believe is an acceptable downref:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTMLURL'

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The normative references are available publicly.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

If the registry can contain non-RFC documents, we should consider adding
the FIPS186-4 and HTMLURL references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to Internet Drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change any RFC status.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registry changes look correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This creates the following new registries:
HTTP Signature Algorithms Registry
HTTP Signature Metadata Parameters Registry
HTTP Signature Derived Component Names Registry
HTTP Signature Component Parameters Registry

All use Expert Review as their process. The authors or other HTTPbis WG contributors
would be good candidates for acting as the experts.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document spent a couple years in the working group, and got feedback from many
contributors, both from people specifically interested in signatures, as well as
the people involved in generic HTTP. It received quite careful review and I sense
it has broad agreement. The WGLC didn't receive many specific email responses, but
there was sufficient discussion on GitHub and in the meeting to confirm consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

At IETF 114, there was concern raised (by Chris Wood) that there should be more formal
analysis performed, akin to the process normally used in CFRG. This document was then
presented at IETF 115 in SAAG for broad discussion of formal analysis as well as to
get specific feedback on this document. The sense of that room was that formal
analysis was not a gating factor that is present for security documents, and the comments
about this document were positive. Separately, an academic formal analysis is ongoing,
but the chairs have decided to progress this document to the IETF and IESG in parallel
with that work.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are many implementations of earlier versions of signatures, and this version
has also received implementation and interop testing, which has been discussed and presented
to the working group. (Note that this is not documented in the document itself.)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document mainly overlaps with security area. It received an early SecDir
review last year, as well as extra reviews in the past month by security area
reviewers (such as Kyle Rose).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of the above apply. The document does add HTTP field registrations, but this
working group is appropriate to review those.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

This document does use ABNF, which has been checked and validated.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written in my opinion, and ready for hand-off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SecDir review has been conducted, as earlier noted.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, as this specifies a standard version of HTTP message signatures
(distinct from previous non-standard versions). The datatracker state and document
state are consistent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors and others have not disclosed any relevant IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors (3) are active in participation.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Current nits are only around normative downrefs, see below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

See https://github.com/httpwg/http-extensions/issues/2317

The following are listed as downrefs, but are part of the downref registry
(https://datatracker.ietf.org/doc/downref/) and should be thus accepted.

  ** Downref: Normative reference to an Informational RFC: RFC 2104
  ** Downref: Normative reference to an Informational RFC: RFC 6234
  ** Downref: Normative reference to an Informational RFC: RFC 8017
  ** Downref: Normative reference to an Informational RFC: RFC 8032

The following is a downref to a document also normatively referenced
in RFC 8292 and should be accepted:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'

The following is a downref that may not have other examples, but the
authors and chairs believe is an acceptable downref:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTMLURL'

The following is a reference that the authors are updating to informative:

  ** Downref: Normative reference to an Informational RFC: RFC 8792

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The normative references are available publicly.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

If the registry can contain non-RFC documents, we should consider adding
the FIPS186-4 and HTMLURL references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to Internet Drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change any RFC status.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registry changes look correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This creates the following new registries:
HTTP Signature Algorithms Registry
HTTP Signature Metadata Parameters Registry
HTTP Signature Derived Component Names Registry
HTTP Signature Component Parameters Registry

All use Expert Review as their process. The authors or other HTTPbis WG contributors
would be good candidates for acting as the experts.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document spent a couple years in the working group, and got feedback from many
contributors, both from people specifically interested in signatures, as well as
the people involved in generic HTTP. It received quite careful review and I sense
it has broad agreement. The WGLC didn't receive many specific email responses, but
there was sufficient discussion on GitHub and in the meeting to confirm consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

At IETF 114, there was concern raised (by Chris Wood) that there should be more formal
analysis performed, akin to the process normally used in CFRG. This document was then
presented at IETF 115 in SAAG for broad discussion of formal analysis as well as to
get specific feedback on this document. The consensus of that room was that formal
analysis was not a gating factor that is present for security documents, and the comments
about this document were positive. Separately, an academic formal analysis is ongoing,
but the chairs have decided to progress this document to the IETF and IESG in parallel
with that work.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are many implementations of earlier versions of signatures, and this version
has also received implementation and interop testing, which has been discussed and presented
to the working group. (Note that this is not documented in the document itself.)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document mainly overlaps with security area. It received an early SecDir
review last year, as well as extra reviews in the past month by security area
reviewers (such as Kyle Rose).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None of the above apply. The document does add HTTP field registrations, but this
working group is appropriate to review those.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

This document does use ABNF, which has been checked and validated.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written in my opinion, and ready for hand-off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SecDir review has been conducted, as earlier noted.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, as this specifies a standard version of HTTP message signatures
(distinct from previous non-standard versions). The datatracker state and document
state are consistent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors and others have not disclosed any relevant IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors (3) are active in participation.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Current nits are only around incorrect normative references, see below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All of these should be informative:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTMLURL'

  ** Downref: Normative reference to an Informational RFC: RFC 2104

  ** Downref: Normative reference to an Informational RFC: RFC 6234

  ** Downref: Normative reference to an Informational RFC: RFC 8017

  ** Downref: Normative reference to an Informational RFC: RFC 8032

  ** Downref: Normative reference to an Informational RFC: RFC 8792

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No, once the incorrect references are all informative.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not change any RFC status.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA registry changes look correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This creates the following new registries:
HTTP Signature Algorithms Registry
HTTP Signature Metadata Parameters Registry
HTTP Signature Derived Component Names Registry
HTTP Signature Component Parameters Registry

All use Expert Review as their process. The authors or other HTTPbis WG contributors
would be good candidates for acting as the experts.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/