Signing Empty / Absent Headers

[jricher]

Currently, an empty header can be included, but an absent header can't be guaranteed.

Proposal: add a boolean parameter for header field identifiers to mark a specific field as "not present" in the target message. Its value is an empty string. (Or should it be some special flag?)

If the verifier finds any header value with that name in the target message, throw an error.

[martinthomson]

My understanding of the design was that the signature covered the message you receive. This would be a departure from that in that it encodes the value associated with the field into the signature description.

I see that the current algorithm fails with an error if a field is listed but absent from the message. You could change that easily enough and encode absent fields¹. Then, if you want to prevent the inclusion of a field, you would list it in Signature-Input but not include that field in the message.

Note that fields that are present but empty are not absent. These can be encoded already.

Footnotes

1. One simple way to encode an absent field is to include the field name on an empty line. That is, omit the colon, space, and value. That should be easily distinguishable. ↩

[martinthomson]

Copying from the PR where @jricher says:

After review of the previous discussion following the interim, I still think this is something we should not add.

I am strongly against the proposed alternative of having a signer include a covered component that does not exist by using the same syntax as a covered component that does exist, and having that process create a valid signature.

After that discussion and some consideration, I find I agree with the conclusion here. We shouldn't build in the ability to sign an absence.

If you want something absent, then not signing it is sufficient. This is primarily because not signing something should -- ideally -- ensure that the recipient who depends on that signature will treat these extra pieces of the message as absent when it comes to processing messages. Even if they have been added, they are not signed and should not alter how the message is processed by the recipient. See Section 8.1 of RFC 3275 and subsections (reading the titles should suffice) for a succinct treatment of that.

I was originally of the view that an approach where you have a specification of what is signed that is fixed no matter what the message is would be useful. For instance, if you believe that signing the X field is important, it might be useful to include that in Signature-Input even in cases where messages don't include the X field. But I'm OK with having signers adapt the value of Signature-Input to the specific message they are signing. There are hazards in that approach in terms of implementation complexity and robustness, but it is not much more than the specification already demands of implementations.

(I still disagree with the second sentiment, but we can happily continue to disagree on that point without consequence, because it is moot.)

[jricher]

I think that we've incorporated the warnings on the need to cover important elements with a signature in the security considerations: https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-10.html#name-insufficient-coverage

Unless there's significant pull to do otherwise, I'm going to plan to close this issue and the associated PR with no action in the next week.