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

[Roberto Polli <[e-mail]>]

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
> than simply be the N+1'th standard.
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.