Update signature input methods and requirements#1411
Conversation
jricher
force-pushed
the
specialty-fields
branch
from
4b213b5 to
8f7f4ce
Compare
… of relying on re-creation
| In order to allow signers and verifiers to establish which content is covered by a signature, this document defines content identifiers for data items covered by an HTTP Message Signature. | ||
|
|
||
| Some content within HTTP messages may undergo transformations that change the bitwise value without altering meaning of the content (for example, the merging together of header fields with the same name). Message content must therefore be canonicalized before it is signed, to ensure that a signature can be verified despite such innocuous transformations. This document defines rules for each content identifier that transform the identifier's associated content into such a canonical form. | ||
| Some content within HTTP messages can undergo transformations that change the bitwise value without altering meaning of the content (for example, the merging together of header fields with the same name). Message content must therefore be canonicalized before it is signed, to ensure that a signature can be verified despite such intermediary transformations. This document defines rules for each content identifier that transform the identifier's associated content into such a canonical form. |
There was a problem hiding this comment.
Message content must therefore be canonicalized before it is signed
@jricher I won't use must in non-normative form. There may be contexts where parties prefer to have evidences of transforming proxies too.
There was a problem hiding this comment.
Thanks, I missed that non-normative must when I made the other editorial changes here.
The fact that some parties want to have evidence of transformation of some things is exactly why you specify what NEEDS to be signed when applying this specification. The start of that language was included in #1419
| The following sections define content identifiers, their associated content, and their canonicalization rules. | ||
| Content identifiers are defined using production grammar defined by {{!RFC8941}} section 4. | ||
| The content identifier is an `sf-string` value. The content identifier | ||
| type MAY define parameters which are included using the `parameters` rule. |
There was a problem hiding this comment.
Where is the parameters rule defined?
There was a problem hiding this comment.
It's defined in RFC8491: https://www.rfc-editor.org/rfc/rfc8941.html#section-3.1.2-4
We need to have a more formal import of the ABNF rules in this document, but that hasn't been done yet.
| ## Dictionary Structured Field Members | ||
|
|
||
| An individual member in the value of a Dictionary Structured Field is identified by the lowercased field name, followed by a semicolon `":"`, followed by the member name. An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in Section 4.1.2 of {{!StructuredFields=I-D.ietf-httpbis-header-structure}} on a Dictionary containing only that member. | ||
| An individual member in the value of a Dictionary Structured Field is identified by using the parameter `key` on the content identifier for the header. The value of this parameter is a the key being identified, without any parameters present on that key in the original dictionary. |
There was a problem hiding this comment.
@jricher as discussed during IETF-109 this feature is still very problematic.
There was a problem hiding this comment.
I don't necessarily disagree but I wanted to at least make it consistent with the rest of the syntax. An upside is that we don't NEED this functionality in the same way that we used to (with the new @signature-params speciality field), and it's also more straightfoward to apply than it was before.
| ## Specialty Content Fields | ||
|
|
||
| The signature's Creation Time ({{signature-metadata}}) is identified by the `*created` identifier. | ||
| Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content. |
There was a problem hiding this comment.
It is not clear whether content found in an HTTP header can be further included in the signature.
There was a problem hiding this comment.
Content found in an HTTP header can be included in the signature by adding the header to the signed content, which is described in its own section.
| Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content. | ||
|
|
||
| Its canonicalized value is an `sf-integer` containing the signature's Creation Time expressed in "Unix time". | ||
| To differentiate speciality content identifiers from HTTP headers, specialty content identifiers MUST start with the "at" `@` character. This specification defines the following specialty content identifiers: |
There was a problem hiding this comment.
Use specialty for consistency
There was a problem hiding this comment.
"speciality" is a typo on my part that I didn't notice! It actually took me a few reads to find the problem here. :)
|
|
||
| Expiration Time: | ||
| : A timestamp representing the point in time at which the signature expires. An expired signature always fails verification. A signature's Expiration Time MAY be undefined, indicating that the signature does not expire. | ||
| : A timestamp representing the point in time at which the signature expires, represented as an integer. An expired signature always fails verification. A signature's Expiration Time MAY be undefined, indicating that the signature does not expire. |
There was a problem hiding this comment.
signature always expire ;) better would be to say that it's unknown.
There was a problem hiding this comment.
I don't think that's actually the case. A signature may be perpetual depending on the use case. The amount of time that's passed might limit how much I'm willing to trust it, though. Especially for something like an HTTP message request!
4 participants
Update the signature input method to always require the signature parameters to be covered.
Redefine all fields like
@request-targetas specialty input fields (non-headers) and allow extension by registry.Define signature parameters using structured field semantics.
Define canonicalization rules more directly.