Re: Secondary certificates for HTTP servers

Hi Eric,

Reviving the work is exciting, thanks to all the folks picking up the
mantle. I think focusing on the server->client flow is good and useful.

On Thu, Jul 6, 2023 at 12:47 AM Eric Gorbaty <e_gorbaty@apple.com> wrote:

> Hi Ryan,
>
> Thanks for the feedback!
>
> > "A client MUST NOT send certificates to the server” - I don’t think it’s
> needed. I understand you’re focusing on server side certificates, but I
> think it’s fine to leave the door open to client certificates if folks have
> other use cases. Maybe we can change the "SETTINGS_HTTP_SERVER_CERT_AUTH”
> setting to mean the endpoint can *receive* certificate frames, so if a
> server wants to send but not receive these frames, it can set this setting
> to 0.
>
> I do not disagree; we can downgrade the severity of that language or omit
> a requirement for clients to not send certificates, but just not define any
> behavior (if this stays scoped to servers).
> I'm thinking that we still do want endpoints to be able to advertise that
> they can send certificates as well (or, well, that they support the entire
> flow here). That said, we could just decide that SETTINGS_SERVER_CERT_AUTH
> is strictly indicating support for server auth, allowing the possibility of
> SETTINGS_CLIENT_CERT_AUTH or something like that in the future if there was
> interest there.
>

We aren't running out of frame types. It would make things a lot clearer if
we called the frame SERVER_CERTIFICATE (or something similar). Then it's
clear that a server can never receive that frame type. In future if a
client->server solution is desirable then it can have its own frame type.

The spec isn't making it clear to me why you need a setting at all. A
client that doesn't understand the extension frame will ignore it. A client
that does understand the frame might process it. There doesn't seem a
strong need for a server to send a Setting. For example, ORIGIN frame
doesn't use a setting and its interaction is quite similar. I might guess
that its an optimization to avoid sending frames to clients that would
ignore them - is the the Authenticator field bigger than the data in ORIGIN
frames? If that is the motivation it might help to state it more clearly in
the text.

On the note about size, how big does `opaque data returned from the TLS
connection exported authenticator authenticate` tend to be? Can it fit into
a single HTTP/2 frame that has a smaller size constraint than HTTP/3?

These a small technical points, I think HTTP would benefit from something
like the draft proposes and the WG should consider it.

Cheers
Lucas