Document Style updates for Signatures #2105
Conversation
|
|
||
| When the `Accept-Signature` field is used in an HTTP Response message, the field indicates that the server desires the client to sign its next request to the server with the identified parameters, and the target message is the client's next request. The client can choose to also continue signing future requests to the same server in the same way. | ||
| The message to which the requested signature is applied is known as the "target message". When the Accept-Signature field is sent in an HTTP request message, the field indicates that the client desires the server to sign the response using the identified parameters, and the target message is the response to this request. All responses from resources that support such signature negotiation SHOULD either be uncacheable or contain a Vary header field that lists Accept-Signature, in order to prevent a cache from returning a response with a signature intended for a different request. |
There was a problem hiding this comment.
I think the SHOULD should be a MUST if this is a security concern.
There was a problem hiding this comment.
@mnot I believe you had a reason that this can't be a MUST, right?
There was a problem hiding this comment.
Is it a security concern or an interoperability one?
I'm not strongly against MUST, but wonder why it's a requirement at all - mentioning caching is fine, but making it a requirement is akin to saying 'Messages MUST be well-formed'.
There was a problem hiding this comment.
I do think there are some security implications -- if I'm requesting a signed response but I'm getting a cache hit for the signature then I'm going to have a higher level of confidence in the incorrect result than I would have otherwise. It's only a security risk if the cached signature is valid for a different message -- but that's more a case of the signature not covering an appropriately large amount of the message.
But I think this can even be addressed by recommending use of the created field on the signature parameters and letting the validator figure it out. I'm fine with it being listed as a consideration but removing the normative requirement here. I'll be the first to admit I'm not an expert on cache semantics and will defer to those who are.
There was a problem hiding this comment.
Left this text as is, since the text in question was not actually changed from a previous version. We can potentially add a recommendation for how to handle cache in a future PR.
Co-authored-by: Yaron Sheffer <yaronf@gmx.com> Co-authored-by: Annabelle Backman <richanna@amazon.com>
This updates the document to comply with the style guides:
This does not (yet) modify the registry initial contents from tables to dictionary lists because I'm not sure how to format those for adding multiple
entries at once.