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

I support adoption of this draft and will consider implementing it for
serving multiple domains over the same HTTP/2 connection.

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.

Nick

On Sat, Jun 25, 2016 at 11:16 AM, Nick Sullivan <nick@cloudflare.com> wrote:

>
> That was actually the previous state -- in BA, the working group decided
> to merge them before the CfA, since they use the same frames in opposite
> directions.  I don't feel too strongly either way, though I tend to prefer
> the merged version simply because otherwise you spend the whole second
> draft defining how to use the same frames in a different way.
>
> -----Original Message-----
> From: Cory Benfield [mailto:cory@lukasa.co.uk]
> Sent: Friday, June 24, 2016 1:29 AM
> To: Mark Nottingham <mnot@mnot.net>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: Call for Adoption: Secondary Certificate Authentication in
> HTTP/2
>
>
> > On 24 Jun 2016, at 01:41, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > <https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
> >
> >
> > We've discussed carrying certificates and related artefacts in HTTP for
> a long time. This draft from Mike and Martin is an evolution of several
> previous approaches.
> >
> > Please state whether you support adoption, and ideally why. Expressions
> of interest in implementation would also be very helpful.
>
> This draft seems like it does address several of the concerns that have
> been raised about certificates in HTTP/2.
>
> My biggest concern with it is that this is a *massive* draft that appears
> to address several related but independent concerns at once. I’m not
> immediately sure that that’s the best approach with this: is there any
> value in breaking this draft up until multiple drafts, each of which
> addresses a single concern? At the very least we could have two: one for
> the AltSvc case of multiple origins on one connection, and one for the
> client certificate case.
>
> Cory
>