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

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jan 2020 15:33:14 +1100

Hello everyone,

We've discussed mechanisms for signing HTTP messages for some time. At IETF106, this draft was presented in the SECDISPATCH Working Group:
  https://tools.ietf.org/html/draft-richanna-http-message-signatures-00

See also the presentation given there:
  https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-http-signing

In discussion there (and with the relevant ADs), it was felt that the most obvious place for this work to land in the IETF would be in this WG. So, while this specific draft has not been discussed extensively here, we have expressed interest in this topic for quite some time, and it seems appropriate to see if we're willing to take it on.

To that end, this is a Call for Adoption of draft-richanna-http-message-signatures-00. Since there hasn't been extensive discussion yet, we're looking for more confirmation than just absence of objection; we'd like folks to read the document and state explicitly whether they support it as a starting point for a work item.

As with all of our drafts, it will only be a starting point; we're not looking for consensus to publish this draft as-is, just confirmation that this is an area we want to start work in.

In particular, if folks could state whether they're willing to contribute to discussion and review drafts, that would be helpful.

To give time to read and consider the draft, this CfA will be for a longer than usual period; we'll make a decision no earlier than 31 January.

Cheers,

P.S. As a reminder, this isn't a call to start discussing specific issues in the draft; we'll have plenty of time for that later.

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Jan 2020 17:13:57 +1100

I think that if we were going to do this we would need to find a way to better scope the work.  The draft you suggest we adopt does a lot and some of that overlaps with existing work from other IETF groups that are probably better suited to the definition.

I see here canonicalization of (subsets of) HTTP messages, something that probably belongs here.  We might also want to engage with the question of what is signed.  More on both these subjects below.

But this also defines a bespoke signing format, something the IETF has done many times before.  I would prefer that we lean on JWS, COSE, or even CMS when it comes to defining signatures.  In a brief review of the document, I wasn't able to convince myself that the current draft was free from some very simple problems in signature construction.  An analysis of this is a surprisingly difficult thing to do well and we would do well to rely on the work of others here to the greatest extent possible.

Yes, that might change the syntax in ways that are incompatible with deployments, but I don't think that we should take this work on if we aren't allowing for that possibility.  To give a simpler example, using structured headers would be a breaking change, but also a very worthwhile one in my view.

I remain unconvinced that à la carte selection of what to sign is a good strategy in general.  In two ways.  Firstly, an endpoint that validates a signature needs to be careful not to consume unsigned information.  There are likely strategies that can minimize exposure to that risk, but anything we develop would need to consider that.  Secondly, this loose sort of definition means that the format is only ever reliably available in very narrow application domains where it is feasible to perform the necessary analysis on what can and cannot be signed.  For application domains like that, specific profiles with little or no flexibility are possible.  Profiles are likely to be more secure as a result of being able to perform a more bounded and thorough analysis.  Profiles are also more concise.

Similarly, this takes an attitude toward canonicalization for signing that differs from that taken in JWS (and web packaging, for something closer to home).  I suspect that we can't avoid canonicalization here due to the nature of the protocol, but it is a significant complicating factor.  For instance, the draft here doesn't really address the potential for character encoding issues.

The interaction between signing and intermediation is a topic that requires some attention.  This was very much an afterthought in the token binding work and it produced a bunch of problems.  For instance, what if an intermediary adds a cache-control directive when that header field was signed previously?  Or what if endpoints and intermediaries disagree about what can or cannot be modified?

ACME takes a very different approach to signing.  Lessons from that work are probably worth considering, such as the way that the protocol adds anti-replay mechanisms independent of, but interlocking with, the signature mechanism.  Understanding if anti-replay is in scope would be good.

In the end, I concede that there are people out there with a need in this area and that we should probably do this work, but it is a non-trivial enterprise.

Yes, you can read this as me preferring a different approach, maybe one closer to what ACME ended up with, but it shouldn't mean that we shouldn't take on this work.  I acknowledge that the existence of a willing constituency of customers for this greatly outweighs many of these concerns.  I am willing to review the work and hope that the above is construed as constructive input to future iterations.

Procedural question: If we do this, what would we say about the interactions with the web packaging work?  That also aims to sign HTTP $somethings using a bespoke format, but the proposals there take a very different approach.  I would rather avoid another XKCD 927 here.

On Thu, Jan 9, 2020, at 15:33, Mark Nottingham wrote:
> Hello everyone,
> 
> We've discussed mechanisms for signing HTTP messages for some time. At 
> IETF106, this draft was presented in the SECDISPATCH Working Group:
> In discussion there (and with the relevant ADs), it was felt that the 
> most obvious place for this work to land in the IETF would be in this 
> WG. So, while this specific draft has not been discussed extensively 
> here, we have expressed interest in this topic for quite some time, and 
> it seems appropriate to see if we're willing to take it on.
> 
> To that end, this is a Call for Adoption of 
> draft-richanna-http-message-signatures-00. Since there hasn't been 
> extensive discussion yet, we're looking for more confirmation than just 
> absence of objection; we'd like folks to read the document and state 
> explicitly whether they support it as a starting point for a work item.
> 
> As with all of our drafts, it will only be a starting point; we're not 
> looking for consensus to publish this draft as-is, just confirmation 
> that this is an area we want to start work in.
> 
> In particular, if folks could state whether they're willing to 
> contribute to discussion and review drafts, that would be helpful.
> 
> To give time to read and consider the draft, this CfA will be for a 
> longer than usual period; we'll make a decision no earlier than 31 
> January.
> 
> Cheers,
> 
> P.S. As a reminder, this isn't a call to start discussing specific 
> issues in the draft; we'll have plenty of time for that later.
> 
> --

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 9 Jan 2020 11:27:18 +0000

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Jan 2020 16:38:24 -0500

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 <[email-masked]> 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.
> 
> 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
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Jan 2020 16:49:53 -0500

Thank you for all of your points below, they’re thoughtful and well-considered. Just a couple points that I would like to respond too.

To be clear, changing syntax and breaking with existing deployments of the Cavage series is absolutely on the table. Communicating with the existing implementation community and providing guidance forward from the Cavage series to this new work is something that the editors are keenly aware of. If that means using structured headers or something like that, then that’s something we need to decide in the WG. This is where the expertise for that is.

The editors are also deeply familiar with JOSE and the differences from that are, and will continue to be, in our minds going forward. We have some ideas about how we can re-use the JWS algorithms (and maybe even its registry), and we intend to involve many members of the SEC area in this work. That said, I really think the canonicalization of the HTTP request is going to be far and away the hardest part of this work, and that was the general thought at the SECDISPATCH talk with a room full of security experts. JWS made life easy by not doing any canonicalization at all, but that comes at the cost of message rigidity that can’t be counted on at the HTTP layer. 

 — Justin

> On Jan 9, 2020, at 1:13 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 9 Jan 2020 21:57:01 +0000

Thanks for the detailed background Justin.

Lucas

On Thu, 9 Jan 2020, 21:38 Justin Richer, <[email-masked]> wrote:

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 10 Jan 2020 01:40:06 +0000

(Full disclosure: I am the editor of the proposed draft)

Martin raises several important points that will need to be addressed. In my opinion, this should happen within the HTTP working group, so that the right people can be involved in the conversation, and consensus-driven decisions can be made with full understanding of the greater context of HTTP's past, present, and future. It is true that a variety of groups are attempting to solve message signing and adjacent problems within particular contexts, but I think a general purpose solution from this working group would help drive consistency rather than simply be the N+1'th standard.

One quick note on scope/intent: this document is intended to provide a general purpose mechanism that can be leveraged and profiled by other specifications, developed here or in other working groups, or even outside the IETF (e.g., the OpenID Foundation or W3C). It does not describe how to use signatures for X or Y purpose, how to negotiate, distribute, or identify keys, or how to indicate what information from the request the sender must sign in order to be "secure." The answers to these questions vary from use case to use case, and are therefore left to profiling documents to define, as appropriate for their context.

– 
Annabelle Richard Backman
AWS Identity

On 1/9/20, 1:53 PM, "Justin Richer" <[email-masked]> wrote:

    
    
     — Justin

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 10 Jan 2020 12:47:03 +1100

Thanks Annabelle,

I want to acknowledge how much this is engaging with the process with the right intentions.  Having existing deployments when you enter a process like this is always a mixed bag; you get great experience to draw from, but also suffer from some inertia.  We'll just have to work that out as we go.

I'd say that addressing the question of flexibility is my first concern as much of the rest of this is driven by that.  We'll need to lean on your experience and contacts with real deployments for that.

On Fri, Jan 10, 2020, at 12:40, Richard Backman, Annabelle wrote:
> Martin raises several important points that will need to be addressed. 
> In my opinion, this should happen within the HTTP working group, so 
> that the right people can be involved in the conversation, and 
> consensus-driven decisions can be made with full understanding of the 
> greater context of HTTP's past, present, and future. It is true that a 
> variety of groups are attempting to solve message signing and adjacent 
> problems within particular contexts, but I think a general purpose 
> solution from this working group would help drive consistency rather 
> than simply be the N+1'th standard.
> 
> One quick note on scope/intent: this document is intended to provide a 
> general purpose mechanism that can be leveraged and profiled by other 
> specifications, developed here or in other working groups, or even 
> outside the IETF (e.g., the OpenID Foundation or W3C). It does not 
> describe how to use signatures for X or Y purpose, how to negotiate, 
> distribute, or identify keys, or how to indicate what information from 
> the request the sender must sign in order to be "secure." The answers 
> to these questions vary from use case to use case, and are therefore 
> left to profiling documents to define, as appropriate for their context.
> 
> – 
>     Thank you for all of your points below, they’re thoughtful and 
> well-considered. Just a couple points that I would like to respond too.
>     
>     To be clear, changing syntax and breaking with existing deployments 
> of the Cavage series is absolutely on the table. Communicating with the 
> existing implementation community and providing guidance forward from 
> the Cavage series to this new work is something that the editors are 
> keenly aware of. If that means using structured headers or something 
> like that, then that’s something we need to decide in the WG. This is 
> where the expertise for that is.
>     
>     The editors are also deeply familiar with JOSE and the differences 
> from that are, and will continue to be, in our minds going forward. We 
> have some ideas about how we can re-use the JWS algorithms (and maybe 
> even its registry), and we intend to involve many members of the SEC 
> area in this work. That said, I really think the canonicalization of 
> the HTTP request is going to be far and away the hardest part of this 
> work, and that was the general thought at the SECDISPATCH talk with a 
> room full of security experts. JWS made life easy by not doing any 
> canonicalization at all, but that comes at the cost of message rigidity 
> that can’t be counted on at the HTTP layer. 
>     
>      — Justin
>     
>     > I think that if we were going to do this we would need to find a 
> way to better scope the work.  The draft you suggest we adopt does a 
> lot and some of that overlaps with existing work from other IETF groups 
> that are probably better suited to the definition.
>     > 
>     > I see here canonicalization of (subsets of) HTTP messages, 
> something that probably belongs here.  We might also want to engage 
> with the question of what is signed.  More on both these subjects below.
>     > 
>     > But this also defines a bespoke signing format, something the 
> IETF has done many times before.  I would prefer that we lean on JWS, 
> COSE, or even CMS when it comes to defining signatures.  In a brief 
> review of the document, I wasn't able to convince myself that the 
> current draft was free from some very simple problems in signature 
> construction.  An analysis of this is a surprisingly difficult thing to 
> do well and we would do well to rely on the work of others here to the 
> greatest extent possible.
>     > 
>     > Yes, that might change the syntax in ways that are incompatible 
> with deployments, but I don't think that we should take this work on if 
> we aren't allowing for that possibility.  To give a simpler example, 
> using structured headers would be a breaking change, but also a very 
> worthwhile one in my view.
>     > 
>     > I remain unconvinced that à la carte selection of what to sign is 
> a good strategy in general.  In two ways.  Firstly, an endpoint that 
> validates a signature needs to be careful not to consume unsigned 
> information.  There are likely strategies that can minimize exposure to 
> that risk, but anything we develop would need to consider that.  
> Secondly, this loose sort of definition means that the format is only 
> ever reliably available in very narrow application domains where it is 
> feasible to perform the necessary analysis on what can and cannot be 
> signed.  For application domains like that, specific profiles with 
> little or no flexibility are possible.  Profiles are likely to be more 
> secure as a result of being able to perform a more bounded and thorough 
> analysis.  Profiles are also more concise.
>     > 
>     > Similarly, this takes an attitude toward canonicalization for 
> signing that differs from that taken in JWS (and web packaging, for 
> something closer to home).  I suspect that we can't avoid 
> canonicalization here due to the nature of the protocol, but it is a 
> significant complicating factor.  For instance, the draft here doesn't 
> really address the potential for character encoding issues.
>     > 
>     > The interaction between signing and intermediation is a topic 
> that requires some attention.  This was very much an afterthought in 
> the token binding work and it produced a bunch of problems.  For 
> instance, what if an intermediary adds a cache-control directive when 
> that header field was signed previously?  Or what if endpoints and 
> intermediaries disagree about what can or cannot be modified?
>     > 
>     > ACME takes a very different approach to signing.  Lessons from 
> that work are probably worth considering, such as the way that the 
> protocol adds anti-replay mechanisms independent of, but interlocking 
> with, the signature mechanism.  Understanding if anti-replay is in 
> scope would be good.
>     > 
>     > In the end, I concede that there are people out there with a need 
> in this area and that we should probably do this work, but it is a 
> non-trivial enterprise.
>     > 
>     > Yes, you can read this as me preferring a different approach, 
> maybe one closer to what ACME ended up with, but it shouldn't mean that 
> we shouldn't take on this work.  I acknowledge that the existence of a 
> willing constituency of customers for this greatly outweighs many of 
> these concerns.  I am willing to review the work and hope that the 
> above is construed as constructive input to future iterations.
>     > 
>     > Procedural question: If we do this, what would we say about the 
> interactions with the web packaging work?  That also aims to sign HTTP 
> $somethings using a bespoke format, but the proposals there take a very 
> different approach.  I would rather avoid another XKCD 927 here.
>     >

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Jan 2020 21:05:53 -0800

Hi,

I support this work.

Martin raised the issue of "à la carte selection of what to sign" as well
as related concerns around intermediaries:

"The interaction between signing and intermediation is a topic that
requires some attention... For instance, what if an intermediary adds a
cache-control directive when that header field was signed previously?"

That is the strength of proposals along these lines. The endpoints decide
which fields to sign, and the amount of intermediary mangling to be
tolerated. In some cases, they will sign everything and tolerate no
mangling or additions. Another example: a strict and complete signing
approach would not tolerate an edge server adding an "X-Forwarded-For"
header, but this proposal allows for it.

thanks,
Rob

On Thu, Jan 9, 2020 at 5:50 PM Martin Thomson <[email-masked]> wrote:

> Thanks Annabelle,
>
> I want to acknowledge how much this is engaging with the process with the
> right intentions.  Having existing deployments when you enter a process
> like this is always a mixed bag; you get great experience to draw from, but
> also suffer from some inertia.  We'll just have to work that out as we go.
>
> I'd say that addressing the question of flexibility is my first concern as
> much of the rest of this is driven by that.  We'll need to lean on your
> experience and contacts with real deployments for that.
>

---

From: Roberto Polli <[email-masked]>
Date: Fri, 10 Jan 2020 17:28:49 +0100

Hi @all,

IMHO it's time for a spec for  signingin http requests/responses
usable as a building block
for a non-repudiation framework for REST APIs.

I investigated on both webpack and cavage and
the first output is the `digest-headers` I-D and its `usage in
signature` section:

-  https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-digest-headers.md#usage-in-signatures

About implementors, if we address the above use-cases we could try to involve
interested folks from public sector (the European Union will probably
start working on API standards).
This will open the door to many implementors.

Finally, replies to previous email follows.

Mark said:
> [...] if folks [are] willing to contribute [..] review drafts [..].
I'm in. Preliminary comments from various people are on this gdoc
http://bit.ly/384sZdF

Annabelle said:
>  a general purpose solution from this working group would help drive consistency rather
Agree.

Martin said:
> [parts of draft-richanna]  overlaps with existing work from other IETF groups [..]
> what would we say about the interactions with the web packaging work?
This is a central point. Some of the changes in draft-cavage-11
come from WEBPACK (eg. the `created`, `expires` parameters).
I think more from WEBPACK could be used in draft-richanna.
See:
- https://github.com/w3c-dvcg/http-signatures/pull/37

Martin said:
> canonicalization of (subsets of) HTTP messages, probably belongs here
Agree.

Martin said:
> [...draft-richanna..]  defines a bespoke signing format
> [..] I would prefer [..] JWS, COSE, or even CMS
About JWS / COSE, see https://github.com/WICG/webpackage/issues/237
About CMS: can you do a proposal based on that?

Martin said:
> I wasn't [..convinced..] that the
>  draft was free from some very simple problems in signature
> construction.  An analysis of this is a surprisingly difficult [..]
A comparison with WEBPACK would be a good starting point.

Martin said:
> à la carte selection of what to sign [ may not be ] a good strategy.
IMHO signature validity boundaries analogous to `iat`,`exp`,`aud`,`iss`
should always be present.
Compulsory fields can be easily added in draft-richanna though.
See eg. https://github.com/w3c-dvcg/http-signatures/issues/66

Annabelle said:
> [draft-richanna .. ] does not [..] indicate what information [..]
> the sender must sign in order to be "secure."
Not sure about that. My experience with draft-cavage implementors make
me lean on
Martin's objections.

Martin said:
> The interaction between signing and intermediation
> [..] requires some attention.
IMHO signatures should ensure integrity
and I am not sure we have to support all possible
intermediation transformation. We can sort it out though.

Justin said:
> changing syntax and breaking with existing deployments
> of the Cavage series is absolutely on the table.
That's inevitable. We can't be secure and backward compatible.

If you read 'till there I owe you a beer :)

Peace,
R.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 13 Jan 2020 22:26:54 +0000

Thanks for the feedback, Roberto. Regarding what information must be covered by the signature, I'm not opposed to mandatory signature metadata fields. What I'm more concerned with is avoiding strict requirements that specific protocol elements be included (e.g., "MUST sign the Date header field" or "MUST sign the effective request URI"). Very few of these elements can be made mandatory without cutting out support for large swathes of use cases and deployment environments. This is really best left to profiling specifications (e.g., a version of RFC6750 for proof-of-possession tokens) and/or deployments (e.g., a web service that requires signing the elements that are relevant to its API).

That said, the guidance in digest-headers is a good example of conditional requirements that may be worth including (e.g., "if you include Digest, you MUST also include...").

– 

On 1/10/20, 8:30 AM, "Roberto Polli" <[email-masked]> wrote:

    Hi @all,

    

    
    
    Agree.

    Agree.

    

    
    
    Peace,
    R.

---

From: Manu Sporny <[email-masked]>
Date: Mon, 20 Jan 2020 11:57:29 -0500

On 1/8/20 11:33 PM, Mark Nottingham wrote:
> extensive discussion yet, we're looking for more confirmation than 
> just absence of objection; we'd like folks to read the document and 
> state explicitly whether they support it as a starting point for a 
> work item.

I support the adoption of this work into the HTTP WG and support the use
of draft-richanna as a starting point.

My organization, Digital Bazaar, has used draft-cavage-* (which is the
basis for draft-richanna-*) extensively, has written multiple
implementations, and maintains the test suite. We will update our
implementations to track changes made by the HTTP WG and will endeavour
to convince the *22 other implementations* to also update their
implementations. More about this in a separate email.

Certain specifications that the W3C Decentralized Identifier Working
Group (DID Authentication over HTTP) and W3C Credential Community Group
(Authorization Capabilities, Encrypted Data Vault Authorization over
HTTP) may eventually depend on require the completion of this work as
well. Experimental implementations for work that builds on top of
draft-cavage-* already exists. The HTTP WG should not let those
specifications nor timelines impact its timeline on this work item, but
should be aware of that potential dependency if the work is adopted.

I'm currently in the process of mobilizing all the other implementers to
provide input on the Call for Adoption since many of them are probably
unaware that the call is happening now (that's on me, I've been delayed
in getting those emails out).

Finally, a huge thanks to Annabelle and Justin for picking up the baton
and running with this!

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

---

From: Henry Story <[email-masked]>
Date: Mon, 20 Jan 2020 23:02:18 +0100

Dear editors,

> On 9 Jan 2020, at 05:33, Mark Nottingham <[email-masked]> wrote:
> 

I support the call for adoption.

I have been active in the decentralised authentication space for
over 10 years. I came to this around 2008 by noticing that one could retrofit TLS Client certificates with a decentralised identity system
initially called foaf+ssl [-1] and later called WebID-TLS [0], to help
build secure decentralized social networks. 

It always was clear that TLS client certificates were not perfect
but the hope was that the TLS community would over time be able 
to improve the client certificate authentication. 

https://www.w3.org/2005/Incubator/webid/spec/tls/

These communities had other priorities. 

Furthermore the problem with client TLS certificates are numerous:
 * they don’t fit well with HTTP/2.0 and break the layering
 * the certificates are in ASN.1, an old pre-web format
 * for the uses of decentralised hyper-apps that need to
 fetch data from many different servers, this posed the risk
 of users being overwhelmed with certificate requests
 (Though this could have been solved by allowing users to
  set policies)
 * …

5 years ago with the JS-Crypto API having gained traction
and having become aware of draft-cavage-http-signatures-05
I implemented it in the prototype Solid server [1]
and wrote a client library that could save the keys
to local storage and authenticate by passing a WebID URL in
the keyId [2] field. The logic is very similar to WebID-TLS 
and just as simple but it fits much better the HTTP-2.0
architecture.

I wrote up a first sketch of a draft of such an authentication
protocol in September 2019, 

https://github.com/solid/authentication-panel/blob/master/HttpSignature.md

Because the client UI is not integrated into the browsers as with TLS,
a lot of the functionality will need to developed as libraries. One 
thing that will be needed is what I initially called a LauncherApp but
that can be thought of as a KeyChain, that could control the credentials 
and keys for all the users apps [3].

I have been less active in the past 3 years programming as I 
somehow ended up doing a PhD on all of this with the aim of 
developing a security logic to ground this.

If you are interested you can see my second year report here
http://co-operating.systems/2019/04/01/PhD_second_year_report.pdf

In summary my early experience with HTTP-Signature was very good.
It is simple and flexible and seems to be a good candidate for a
decentralised authentication framework.

Henry

If I had a suggestion it would be to consider allowing the keyId
field to be a URI, either relative (one could think of it being that
now) or absolute.

[-1] https://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf
[0] https://www.w3.org/2005/Incubator/webid/spec/tls/
[1] https://github.com/read-write-web/rww-play/blob/dev/app/rww/auth/HttpAuthentication.scala
[2] https://github.com/read-write-web/rww-scala-js/blob/akka.js/src/main/scala/rww/store/KeyStore.scala
[3] https://github.com/solid/authorization-and-access-control-panel/blob/master/Proposals/LauncherApp.md

---

From: Orie Steele <[email-masked]>
Date: Mon, 20 Jan 2020 17:08:20 -0600

First time contributing like this, worry if replying like this breaks the
counting mechanism, it seemed nicer than hitting the mailing list
directly...

I done enterprise software development since 2008, including SOA, SOAP,
WSDL, and the newer stuff like Blockchain, GraphQL, Smart Contracts, and
Linked Data Signatures, etc...

I have used HTTP Signatures to configure Oracle Cloud resources
programmatically:

-
https://docs.cloud.oracle.com/iaas/Content/API/Concepts/signingrequests.htm

As well as Authorization Capabilities for Encrypted Data Vaults:

- https://w3c-ccg.github.io/zcap-ld/

Here is a link to the blog post and demo which uses HTTP Signatures from
the client web browser to the edv server (as well as DIDs):
https://medium.com/transmute-techtalk/encrypted-data-vaults-c794055b170e

I have also used HTTP Signatures to implement integrations between DIDs and
activity pub, though those were all tech spikes (unpublished), it was based
on this blog post:
https://hacks.mozilla.org/2018/11/decentralizing-social-interactions-with-activitypub/

My experience with HTTP Signatures has been good.

I'm mostly interested in contributing to defining how HTTP Signatures can
be used with Decentralized Identifiers and Verifiable Credentials, as we
already have implementations of these integrations which we are seeking to
strengthen through contribution to a robust standards development process.

Regards,

OS

ᐧ

On Mon, Jan 20, 2020 at 4:06 PM Henry Story <[email-masked]> wrote:

> over 10 years. I came to this around 2008 by noticing that one could
> retrofit TLS Client certificates with a decentralised identity system
> [1]
> https://github.com/read-write-web/rww-play/blob/dev/app/rww/auth/HttpAuthentication.scala
> [2]
> https://github.com/read-write-web/rww-scala-js/blob/akka.js/src/main/scala/rww/store/KeyStore.scala
> [3]
> https://github.com/solid/authorization-and-access-control-panel/blob/master/Proposals/LauncherApp.md
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>

---

From: Manu Sporny <[email-masked]>
Date: Tue, 21 Jan 2020 11:01:45 -0500

Hi all,

I've been the primary author of the draft-cavage-http-signatures-* I-D
for the past 8+ years. That draft is what
draft-richanna-http-message-signatures is based on. I thought it might
be helpful to give this group a brief history on the last 8 years of
work that led up to this recent Call for Adoption.

The work started back in the pre-2010s when Mark Cavage was at Amazon
and involved in securing HTTP API calls in their infrastructure and
between their customers and their infrastructure (AWS). The problem that
he was dealing with at the time was all of the massive amounts of shared
secrets (API keys) that companies were flinging around the Internet and
all of the security concerns (and break ins) related to the practice of
managing millions of customer shared secrets to secure your
infrastructure. The most straightforward solution was to use asymmetric
keys and digital signatures of some kind. He put together a library that
did this and Digital Bazaar (my company) discovered the library and
started using it. His (and others) work at Amazon would eventually
become the way AWS customers sign AWS API requests[1] to this day.

Digital Bazaar was interested in solving the same problem for our
customers and software systems. We felt like shared secrets were a dead
end and were already looking into building what would become W3C
Verifiable Credentials and W3C Decentralized Identifiers. That is, a new
decentralized PKI system that would need a way for clients and servers
to authenticate with each other without necessarily depending on the CA
system. This was also back in the day when Let's Encrypt didn't exist
and we had a need to digitally sign content travelling over plain 'ol
HTTP (no TLS)... because some our customers (individuals in developing
nations) couldn't afford TLS certs at scale. Fundamentally, we were
looking for a way to secure an ad-hoc peer to peer network built on top
of HTTP without the cost associated with TLS.

Around 2012, I approached Mark Cavage and asked him if he'd be okay with
us putting together an I-D for more or less what his software library
did at the time. He agreed, noting that he didn't want any part of the
standards making process due to the glacial speed at which it
progressed. It only took us 8 years to get here, so I have no idea why
Mark had such a skeptical view on the speed of the standards making
process! :P

In 2013, I put together the first I-D for HTTP Message Signatures[2] and
did my best to keep it in sync w/ the two implementations at the time.
Mark subsequently moved onto Joyent and then Oracle deploying the HTTP
Message Signature solution at those organizations. He noted that whether
the organization picked up the technology or not had far more to do with
internal politics than technical merit. That said, those organizations
still use the mechanism to this day.

Then, not much happens between 2013-2017. Most of the folks I end up
speaking to at W3C and IETF note things like "TLS already exists, why do
you need this?" and "Let's Encrypt makes it cheap to own a certificate,
why do you need this?" and "Why don't you just use a JWT payload"...
which have become the standard off-the-cuff responses to why not to do
HTTP Message Signatures. So, for four years, we just learned from our
implementations, updated the specification, addressed attack vectors
that we (and others) were concerned about and would pick up the
standards track stuff if people ever started pulling on the specification.

... and then some European Banking API standards groups picked it up and
deployed it to millions of people in production because it met a need
that they had - they wanted to secure client to server communication
using digital signatures at the HTTP layer. There was a sharp uptick in
implementations. We pleaded with folks to not deploy to production, to
help us with the spec and test suites and getting it through IETF...
which was met with responses to the effect of: "Nah, we've tested it, it
works for us, we're deploying it". Due to the secretive nature of
banking in general, it was impossible to get more information without
being in the inner circle.

I made a trip to IETF 98 in Chicago (late 2017) to see what we could get
started, had a few chats with Mark Nottingham, Martin Thomson, Lucas
Pardue, and Jim Schaad about the possibility of bringing it into the
HTTP WG. Each was supportive (and I'm thankful to each of them for being
welcoming. A small minority of others (from large organizations) were
not, due to some of the design decisions the specification made, and I
didn't personally have the bandwidth to fend off the inevitable deluge
of attacks from those others while trying to take the various
specifications that we were involved in at W3C through that process. So
the decision was made to just sit on the HTTP Message Signatures
specification (and keep updating it) until there was a stronger pull on
the spec. There were around 12 implementations of the spec at this
point... no one had any clue if they interoperated with one another
because we still hadn't written a test suite.

In this time, the W3C Verifiable Credentials work and the W3C
Decentralized Identifier (DID) work was well under way. We were using
HTTP Message Signatures to perform authorization to these software
systems called Encrypted Data Vaults. We were also using HTTP Message
Signatures to do DID-based authentication. We were also using HTTP
Message Signatures to secure HTTP APIs. The approach worked and was
simpler than pulling in the entire JOSE/COSE stack or using JWTs or JWS.
Implementations were fairly easy to put together. Developers seemed to
be happy with the design choices for HTTP Message Signatures.

Fast forward to late 2019 - Mastodon and Pleorma implements and pushes
some variant of HTTP Message Signatures out to its million plus users
and uses it for federated messaging, there are now 20 implementations,
there is a test suite, but only a handful of implementers care to run
against it because many of them are just using their library internally
(while other companies are using their library externally). People are
creating their own bespoke things at W3C that kinda sorta does what HTTP
Message Signatures does but in an incompatible way... there are multiple
Proof of Possession specs popping up... and many are yelling at us to
finish the work at IETF (unpaid, of course). :)

Annabelle, Justin, and I ended up on a random call in some random
standards group late last year to provide some updates on doing proof of
possession. We started talking and here we are. Justin presented the
spec to where he felt it needed to be presented at IETF (and clearly did
a great job, because here we are). Annabelle volunteered to be Editor,
and I'm very thankful for that because the spec has suffered from having
a part-time, overworked editor for years. I'm happy to support by
providing spec text, a communications channel to all the implementers,
and an explanation for why the spec is constructed in the way that it is
and the design decisions that have gone into the spec up to this point.

Hope that helps give folks some context wrt. where the HTTP Message
Signatures spec came to be, some of the history we'll have to be aware
of, and potentially where it might go as a result.

-- manu

PS: I just typed this out and fired it off, no proof reading, my
apologies for it's length and any errors. I'm pressed for time but
wanted to get /something/ out to the group.

[1]https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
[2]https://datatracker.ietf.org/doc/draft-cavage-http-signatures/00/

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Jan 2020 12:23:08 -0500

Manu, thanks very much for telling your story!

To add just a bit to the story from my perspective:

The working group call mentioned below was in fact the Financial-Grade API Working Group in the OpenID Foundation, which was looking at the landscape of different signature mechanisms out there for their use cases. As you can see from Manu’s story below, the financial industry has been using various forms of HTTP Message Signing over the years as a point solution, and the family of incompatible approaches is concerning to a group like FAPI that’s trying to standardize across different groups. That’s why the group invited Manu, Annabelle (who represented AWS Sigv4, their proprietary internal successor to Cavage’s original work), myself (representing the signature method we developed in the OAuth WG years ago), and others on this call. In parallel, I had already been pursuing the goal of a general purpose HTTP Signature Method  around the time of the call, and subsequent conversations with Manu, Mark N, Annabelle, and others gave us the current approach to the path forward with the HTTP WG that I think has the best chance of succeeding.

My goal in my presentation at SECDISPATCH was not just to bring the existing Cavage doc into a working group, but to hopefully solve HTTP Message Signatures for a wide array of use cases using all of the different tools and experience at hand today. I am going to need this work for security token presentation and key binding, both in OAuth 2.0 and in the new work that’s happening in TxAuth. Annabelle’s draft is, I believe, a good starting point for a lot of work going forward. 

I’m really excited to be part of the editorial team and think we’ve got a great opportunity to make something that is useful and impactful for many people on the internet today and in the future. 

 — Justin

> On Jan 21, 2020, at 11:01 AM, Manu Sporny <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Sebastien Rosset (serosset)" <[email-masked]>
Date: Wed, 29 Jan 2020 21:47:35 +0000

I am in favor of this draft as a starting point for further discussions. I am also willing to contribute to review drafts.
Sebastien Rosset

---

From: Jonathan Gallimore <[email-masked]>
Date: Thu, 30 Jan 2020 20:27:45 +0000

We support the adoption of this work into the HTTP WG and support the use
of draft-richanna as a starting point. We’re willing to participate in
discussions and review drafts.

We’ve made use of this specification as part of securing
business-to-business transactions for our clients.

Additionally, we have created an Open Source, Apache Licensed
implementation of the specification for Java:
https://github.com/tomitribe/http-signatures-java, and we make use of the
specification in our API Gateway product: https://tribestream.io/ to sign
messages between the Gateway and Microservice endpoints (see
https://tribestream.io/guide/en/api-gateway/http-sign-guide/current/ for
more detail).

We’re grateful to the specification authors and looking forward to further
collaboration as this specification continues to evolve.

Kind Regards

Jon

On Wed, Jan 29, 2020 at 9:53 PM Sebastien Rosset (serosset) <
[email-masked]> wrote:

> I am in favor of this draft as a starting point for further discussions. I
> am also willing to contribute to review drafts.
>
> Sebastien Rosset
>

-- 
Jonathan Gallimore
http://www.tomitribe.com

---

From: Roberto Polli <[email-masked]>
Date: Fri, 31 Jan 2020 17:10:24 +0100

Dear Mark and Annabelle,

Il giorno gio 9 gen 2020 alle ore 05:37 Mark Nottingham
<[email-masked]> ha scritto:
> As with all of our drafts, it will only be a starting point; we're not looking for consensus
> to publish this draft as-is, just confirmation that this is an area we want to start work in.

do we need further discussion on the adoption?

While I think that it would be appropriate to address the issues
raised by Martin eg
in regards to the interactions with webpackage before adoption,
my opinion is that adopting now is better than never adopting.

Have a nice day,
R.

---

From: Manu Sporny <[email-masked]>
Date: Fri, 31 Jan 2020 18:03:57 -0500

On 1/8/20 11:33 PM, Mark Nottingham wrote:
> draft-richanna-http-message-signatures-00.

I've received a few puzzled requests from implementers about
difficulties involved in joining to support the work (they work for
large corporations and can't get approval to join and support the call
for adoption in the time it takes their lawyers to respond... and may
never get approval -- I've told them that if they can't find a way to
respond and participate, the WG won't be able to take their input into
account).

Some have responded positively, but were concerned about responding the
wrong way (and I haven't been able to get back to them to tell them how
to respond the right way due to travel / other WG involvement pressures).

At this point, I do think it's important to point out that Mastodon,
which has over a million people on their network has implemented the
spec and was interested in supporting the call for adoption, but has yet
to get their vote in. Link to Github is here:

https://github.com/tootsuite/mastodon/issues/12914

I know that's a weak show of support w/o a complete write up... and I
know that most on this list already know this... but just mentioning
that there are more supporters of this call for adoption than have
responded on this mailing list.

-- manu