Comments on draft-ietf-httpbis-http2-secondary-certs-04

[Watson Ladd <[e-mail]>]

Dear all,

I'm concerned about changing the format of the certificate frame payload
based on the unsolicited flag. Instead I would prefer that we reserve
request id 0 for unsolicited frames. This way there is only one possible
format, versus 2. It's a very minor quibble, but I strongly feel things
should be as simply parseable as possible.

Secondly the draft seems to hold open the possibility of having multiple
certificate fragments being assembled at once. This seems like a misfeature
to me.

Thirdly the CERTIFICATE frame context in the certificate frame starts with
the request-id but is otherwise unconstrained. I'm not entirely sure why
the older approach of having the request specify it was a bad idea, but
perhaps it was a bad idea for reasons I haven't learned yet.

Then it seems both '*' and '_' are treated as wildcards in the Required
Domains extension. It's not clear to me why one or both would be required.

I still am not clear on the joint versus separate authoritative issue (is
it a question of simultaneity)  and why that implies clients MUST NOT
assume colocation in the future. Even if joint authorization existed, it
might change for a future connection.

Section 6.4 seems a little strong to me: it's unlikely that $CDN will claim
control of all origins it could claim authority over on a connection, but
more likely that it does so for ones in subrequests, link headers etc.

Section 6.5 seems to imply that the set of certificates can shrink as a
request is being processed. It's a bit surprising to me: I thought there
would only be one transition as the USE_CERTIFICATE frame arrives and is
processed, for any potential CERTIFICATE_REQUIRED relevant to the stream.
The fact that these frames are no longer on the stream but on stream 0
might be fooling me as to the ordering.

The second half of section 6.5 says clients don't know if the ambient
authority of a freely useable certificate will be honored. True, but I
imagine a server would request a certificate explicitly if needed instead
of reject the request assuming it had seen all of them. I would suggest a
SHOULD for servers requesting certificates explicitly when accessing
protected resources. Do people have real usecases/ sufficiently complex
configurations where this won't work?

Sincerely,
Watson Ladd