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

[Ilari Liusvaara <[e-mail]>]

On Mon, Jun 27, 2016 at 12:06:43PM +1000, Martin Thomson wrote:
> On 24 June 2016 at 17:28, Ilari Liusvaara <[e-mail]> wrote:
> >
> > What I don't like is MUST not send USE_CERTFICATE without
> > CERTIFICATE_REQUIRED. This forces client that wants to maintain
> > the required control in order to safely mux across authoriteies to
> > eat extra RTT for every request (yes, it would be guessing without,
> > but likely highly accurate guessing[1]).
> 
> This is something I'm not entirely happy with myself.  Hopefully we
> can find some way that we can define an interaction that doesn't
> require both the extra round trip AND the complexity.  As Cory notes,
> this is more complex than ideal.

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.

> > Also, with regard to certificate chains, there are still loads of
> > certificate chains that contain PKCS#1v1.5 signatures, and there will
> > likely be for forseeable future[2].
> 
> That's fine.  But we are explicitly not saying what is permitted in
> the certificate chain, we are only saying what *this* protocol can
> carry.  (In my opinion, saying that signature_algorithms also applies
> to signatures on certificates is a mistake in TLS; and we we don't
> need to replicate that.)

Oh, looks like I misinterpretted it then...

And yeah, what is acceptable for end-entity signature and certificate
chain are two different things.

Also, the legacy constraints are different (where one can use modern
stuff and limit the combinations for EE signature, there is lot worse
stuff still out there with CA certs and signatures).


-Ilari