Re: [Editorial Errata Reported] RFC9421 (8103)

I have reviewed the text and can confirm that this errata is correct: the wrong component name is used in three examples in the security considerations section as reported.

- Justin
________________________________
From: RFC Errata System <rfc-editor@rfc-editor.org>
Sent: Sunday, September 15, 2024 12:23 AM
To: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>
Cc: taka@authlete.com <taka@authlete.com>; richanna@amazon.com <richanna@amazon.com>; ietf@justin.richer.org <ietf@justin.richer.org>; msporny@digitalbazaar.com <msporny@digitalbazaar.com>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: [Editorial Errata Reported] RFC9421 (8103)

The following errata report has been submitted for RFC9421,
"HTTP Message Signatures".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8103

--------------------------------------
Type: Editorial
Reported by: Takahiko Kawasaki <taka@authlete.com>

Section: 7.5.3

Original Text
-------------
Several parts of this specification rely on the parsing of Structured
Field values [STRUCTURED-FIELDS] -- in particular, strict
serialization of HTTP Structured Field values (Section 2.1.1),
referencing members of a Dictionary Structured Field (Section 2.1.2),
and processing the @signature-input value when verifying a signature
(Section 3.2).  While Structured Field values are designed to be
relatively simple to parse, a naive or broken implementation of such
a parser could lead to subtle attack surfaces being exposed in the
implementation.

For example, if a buggy parser of the @signature-input value does not
enforce proper closing of quotes around string values within the list
of component identifiers, an attacker could take advantage of this
and inject additional content into the signature base through
manipulating the Signature-Input field value on a message.

Corrected Text
--------------
Several parts of this specification rely on the parsing of Structured
Field values [STRUCTURED-FIELDS] -- in particular, strict
serialization of HTTP Structured Field values (Section 2.1.1),
referencing members of a Dictionary Structured Field (Section 2.1.2),
and processing the @signature-params value when verifying a signature
(Section 3.2).  While Structured Field values are designed to be
relatively simple to parse, a naive or broken implementation of such
a parser could lead to subtle attack surfaces being exposed in the
implementation.

For example, if a buggy parser of the @signature-params value does not
enforce proper closing of quotes around string values within the list
of component identifiers, an attacker could take advantage of this
and inject additional content into the signature base through
manipulating the Signature-Input field value on a message.

Notes
-----
"@signature-input" should be changed to "@signature-params". There is one such error in both the first and second paragraphs of Section 7.5.3.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC9421 (draft-ietf-httpbis-message-signatures-19)
--------------------------------------
Title               : HTTP Message Signatures
Publication Date    : February 2024
Author(s)           : A. Backman, Ed., J. Richer, Ed., M. Sporny
Category            : PROPOSED STANDARD
Source              : HTTP
Stream              : IETF
Verifying Party     : IESG