Re: Serialization#draft-ietf-httpbis-message-signatures-00

Hi Anders,

Thanks for your feedback. 

The proposed approach in the draft is to have a signature that can be serialized into an HTTP header, defined within the specification. If another spec wants to use this normalization and signature method and package the results differently, then it’s free to do so, but I don’t think that’s going to be a concern here.

The editors are looking at different signing methods and how we can use them with this specification. There are a lot of different algorithms for signing content out there, with different keys and limitations, and we need to figure out what and how we can support different things. We’ve still got some foundational cleanup and deeper issues to get through first, but that topic will come back up in the future. The authors are very familiar with JWS and are looking ways it might fit with this work.

 — Justin

> On Jul 17, 2020, at 3:52 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Dear List,
> Making signed HTTP requests serializable (in a reasonable way) is as far as I can tell not a part of the current agenda.
> 
> FWIW, here is a [very] raw proposal for how this could be accomplished:
> - Build on JWS compact mode.
> - Put a hash and attributes of the of signed HTTP header data (you're the experts on this part) in the JWS Protected Header as an extension.
> - Put the payload in the JWS Payload element using the standard base64url encoding.
>   Optionally use the JWS "typ" Protected Header element to specify MIME type of the payload
> - Use the completed JWS compact string as the sole HTTP Body element
> 
> For JSON-formatted data there is yet another possibility: combine https://www.rfc-editor.org/rfc/rfc8785.html with "in-line/detached" JWS ( https://tools.ietf.org/html/rfc7515#appendix-F):
>   {
>      "anyJsonElement": "something",
>          .
>          .
>      "signature":"eyJblahblahblah..blahblahblah"
>   }
> 
> In both cases the HTTP Body element contains the serializable signed data.  Verifying signed HTTP header data is though not possible to perform after leaving the HTTP environment.  OTOH, for systems that actually depend on serialization, using HTTP headers as data carriers doesn't appear as a recommendable approach.  In my own work which heavily builds on counter-signatures for digital contracts, URL and current time are therefore represented in the JSON payload by "requestUrl" and "timeStamp" respectively.
> 
> Thanx,
> Anders
> 
> 
> 
>

Received on Thursday, 23 July 2020 20:25:33 UTC