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

Thanks for the detailed background Justin.

Lucas

On Thu, 9 Jan 2020, 21:38 Justin Richer, <jricher@mit.edu> wrote:

> 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
>
> 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
>
>
>
>