Re: Call for Adoption: draft-richanna-http-message-signatures

Speaking as one of the editors of the proposed I-D and the speaker in the linked video:

The “drama” happened largely because a number of groups made direct normative requirements on a document that they didn’t have input in — they saw the I-D and that it solved their problem, and so used it as is. Some breaking changes were introduced in -11, including some frightening intro text that said, quote:

   WARNING: DO NOT IMPLEMENT THIS SPECIFICATION AND PUSH THE CODE INTO
   PRODUCTION.  THIS VERSION OF THE SPECIFICATION IS ONLY FOR
   EXPERIMENTAL IMPLEMENTATIONS.
That kind of intro is scary, especially to people who didn’t realize the state of the I-D (which is to say, independent and potentially volatile). Members of the wider internet community that had been using the draft took that as a signal that it was too unstable to track over time, so they pegged to -10. Managing this kind of expectation and churn is one of the reasons we want to bring this document into a formal standard process instead of the detached community that it’s been in for years.

There will be some people who stay on Cavage-10 after this becomes a WG draft, and even after this becomes an RFC. Just like there are those today who are on pre-10 drafts of Cavage. They are working in their own silos, and the old drafts solve their problem so there is little motivation to move their code to something new right now. And that’s especially true if it’s an I-D that can change at any time. But there’s a lot more weight behind an RFC, and that is the kind of thing that can lead to general-purpose libraries and support in general projects that developers can leverage instead of custom internal code. After all, if you can turn on an Apache module or a Java Servlet Filter that just implements RFC-HTTP-Signatures, why wouldn’t you use that?

The editors are seeing Cavage-12 as the starting point for work, not its end state. Not everyone agreed with the changes in -11 (and -12), but it would be disingenuous to have a starting document that didn’t at least incorporate those even if we decide to back them out completely. There’s a lot of discussion in the proposed I-D about that kind of thing, like the hs2019 signature method and the way that it lets you canonicalize differently from other signature mechanisms, and some alternatives to that. So there’s also a good chance that a lot of the community that balked at -11 and -12 will be interested in coming along with a new draft from this group, especially once things start to stabilize. They didn’t pick Cavage-10 because it was perfect, but because it was there, and kinda the only thing there.

The relationship between this and Digest is also important. My own use cases require protection of the entity body, so being able to cover that in the signature through Digest or something like that is vital to me.

  — Justin

> On Jan 9, 2020, at 6:27 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 
> Hi Mark,
> 
> A video of the presentation at SECDISPATCH is also available on YouTube. IETF106-SECDISPATCH-20191119-1710 at the 50 minute mark, direct link:
> https://youtu.be/CYBhLQ0-fwE?t=3006 <https://youtu.be/CYBhLQ0-fwE?t=3006>
> 
> I think it makes sense to discuss in the HTTP WG, I would be willing to review and contribute. I think its important to figure out how this approach differs from other signing methods mentioned previously, and to document/articulate that in a way that is accessible to the wider community.
> 
> There is a relationship between Digest header and signatures, having some way to discuss this coherently may be beneficial.
> 
> From the presentation, slide 11 titled "Cavage Signature Drama":
> 
> > * Editors of draft publish major updates in draft -11
> > * Everyone using it freaks out and pegs to draft -10
> 
> draft-richanna-http-message-signatures clearly states that it is based on draft-cavage-http-signatures-12. Do we have a sense of the appetite for implementers to pick up any evolution of this specification basis, or is draft-cavage-http-signatures-10 too sticky?
> 
> Cheers
> Lucas
> 
>