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

["Richard Backman, Annabelle" <[e-mail]>]

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...").

– 
Annabelle Richard Backman
AWS Identity
 

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

    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.