Re: Concrete format for signed responses

On Tue, Dec 5, 2017 at 2:23 PM Andy Green <andy@warmcat.com> wrote:

>
>
> On 12/06/2017 05:19 AM, Jeffrey Yasskin wrote:
> > Hi all,
> >
> > I've published
> >
> https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html
> > to follow up on
> > https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html
> > with a concrete proposal for the Signature header.
>
> Sorry if this was already discussed, but do you know about JWS / JWK?
>
> https://tools.ietf.org/html/rfc7515
> https://tools.ietf.org/html/rfc7517


When I've asked Chrome's security folks about JWS (and CMS and COSE),
they've advised that I stay far away from the general formats. We want to
keep implementations simple in order to reduce their bug counts, so we'd
need to profile the general format, but then we don't get to take advantage
of existing implementations. At most, we take advantage of any security
thinking that went into the JWS spec itself, but there are enough mistakes
in JWS that this doesn't help.

ACME uses them
>
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/



> So there are an increasing number of implementations of this.
>
> There seems to be a lot of crossover with what you're trying to do there
> (encode key type and parameters).
>

Kinda:
1. JWS makes the mistake of letting the attacker control the verification
algorithm. Since the key and its type are already known to the verifier,
there's no need to encode the type in the signature.
2. Only one or two parameters defined in JWS overlap with the ones I
need: x5t#S256 and possibly crit. x5u is close, but I believe it doesn't
include the SCT and OCSP stapling that we'll want before trusting the
certificates.

Jeffrey