Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

On Sun, Jul 24, 2016 at 12:56:31PM +0200, Martin Thomson wrote:
> On 24 July 2016 at 12:34, Ilari Liusvaara <> wrote:
> > I think one needs to also sign and MAC over any implicit parameters
> > that are shared over multiple authentications. E.g. Supported end-
> > certificate signature algorithms.
> My understanding of SIGMA is that the MAC needs to cover the identity
> and other properties, but the signature only has to cover the key
> shares (or shared key).  Thankfully we don't need to worry about that
> distinction because of the way that TLS 1.3 and EMS cause everything
> to depend on everything else: keys depend on identity and negotiation
> parameters as much as the MAC does.

I thought the easiest way is to multi-tap hashes (in the same style
TLS 1.3 does), which impiles that the both cover the same things
(modulo MAC also covering the signature)...

And if MAC needs to cover the "implicit" properties, it means you
need to be able to include those into computations.

> Either way, I am increasingly of the opinion that we should ask for
> this facility from the TLS working group.  There are subtleties to
> this that are easy to get wrong and good analysis is crucial.

I think before that, one should plan the interface to HTTP/2 and
some rough ideas for what information is passed.

- Are the requests transferred as header blocks or binary blobs
  (I presume responses are binary blobs)?
- At least which parameters are present for each request?
- What of above parameters are shared over multiple requests?
- How many flights are allowable (I presume 1 request + 1 response,
  but this should be explicit)?
- If typed auxillary data (e.g. OCSP staple or SCT staple) can be
  passed back or not?

This is to know what to request, so one avoids nasty surprises
of having hard time figuring out how to pluck the result into

And I think certificate use control should be separate mechanism,
operating over proven certificates in client->server direction.


Received on Sunday, 24 July 2016 11:19:04 UTC