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

[Martin Thomson <[e-mail]>]

On 28 June 2016 at 03:39, Ilari Liusvaara <[e-mail]> wrote:
> Well, basically IMO the needs for client-server direction are:
>
> 1) Client to select the certificate set on per-request basis (including
>    selecting the empty set).
> 2) Not to have to eat extra RTT for per-request control (as having to
>    do that would be a perverse incentive).
> 3) Server to indicate that more certs are needed.
> 4) Client to be able to refuse server's request for extra certificate.
>
> The set selection in 1) is obviously client-specific. E.g. Curl and
> Firefox will do it in rather different ways.
>
> An optimization would be for client to signal that the certificate set
> it sent for request is closed: Any request to extend it will be denied
> (the set will probably be empty, but not necressarily).
>
> Capability to unilaterially send certificates would obviously
> complicate things, as one would need to handle wild guesses about
> capabilities of the server.
>
>
> For the server-client direction:
>
> 1) Ability for server to push a new certificate unilaterially, and
>    have the names appear in authority set.
>
> IMO, no need to be ever able to remove names from that set or to
> temporarily disable entries.

This is a good summary of the requirements.  The question we are
struggling with is whether orthogonality of the two solutions is
possible.  Assembling all the pieces for the client to server
direction is challenging, but once you have those pieces, maybe you
don't want a whole different set of mechanisms for the reverse
direction.