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

[Martin Thomson <[e-mail]>]

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.

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

On 25 June 2016 at 21:44, Nick Sullivan <[e-mail]> wrote:
> There are still some open questions about whether the use of the SETTINGS
> frame and the creation of two additional IANA registries is preferable to
> the use of an Extended SETTINGS
> (https://datatracker.ietf.org/doc/draft-bishop-httpbis-extended-settings/)
> frame and the existing TLS Extensions IANA registry. However, I think this
> can be resolved here.

I agree.   For the record, we should have built h2 settings like in
Mike's draft in the first place, but retrofitting it is harder.