- From: Justin Richer <jricher@mit.edu>
- Date: Wed, 7 Apr 2021 09:05:59 -0400
- To: ietf-http-wg@w3.org
We’ve just pushed a new version of the signature spec. The main changes this time are around how the algorithm is chosen by participants. Previously, there was a required “alg" field that had limited values with most of them had been marked deprecated by the source I-D except for one value “hs2019” which effectively meant “ignore the alg field and do whatever the key tells you to”. We’ve now changed the expected logic around the protocol such that the signer and verifier can now choose and communicate the algorithm in use in a variety of ways: - If something’s been pre-configured, use that (ie, a signer/verifier only ever does one kind of alg and throws out the rest as errors) - If something’s stated in the “alg” field, look it up in a registry and do what its definition says - If you can figure out from the key material, do that This last step in particular allows us to quite nicely subsume other signing methods like JWS from JOSE, and we have a section detailing how to do JOSE-style algorithms. There is no “alg” value that maps to the JOSE algorithms though — we aren’t replicating the registry and we aren’t importing it either. But if your key is, say, a JWK with an “alg” field then you’ve got all the parts you need in JOSE-land to figure out what algorithm it’s supposed to be. And yes, we explicitly disallow alg:none. The registered algorithms are much more explicit now for both signature and verification, leaving less for developers to just “figure out”, hopefully. We’ve also replaced all the values that were used in the source I-D’s with more specific values. This has the nice side effect of not having a namespace collision with existing implementations of the source I-D’s that are out in the wild. The precedence order might be up for debate in the above list and I played with it when making the edits, so I’d like feedback on that. I would personally like this to be a very deterministic ordering but I’m not positive we can really get there. This change set should close a lot of issues in the draft, which we’ll be going through as people get a chance to read through the latest draft and decide what all still works. Also, my apologies for the formatting in RFCdiff — I didn’t notice the long unwrapped lines in -02 so that’s thrown things off in the side-by-side comparison that expects everything to be 72char wide. Thanks to everyone who’s commented and discussed on the drafts so far! — Justin > On Apr 7, 2021, at 8:49 AM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the HTTP WG of the IETF. > > Title : Signing HTTP Messages > Authors : Annabelle Backman > Justin Richer > Manu Sporny > Filename : draft-ietf-httpbis-message-signatures-03.txt > Pages : 38 > Date : 2021-04-07 > > Abstract: > This document describes a mechanism for creating, encoding, and > verifying digital signatures or message authentication codes over > content within an HTTP message. This mechanism supports use cases > where the full HTTP message may not be known to the signer, and where > the message may be transformed (e.g., by intermediaries) before > reaching the verifier. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-03.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-message-signatures-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > >
Received on Wednesday, 7 April 2021 13:06:13 UTC