Hi Rich, and thanks for your review! Responses inline.
David
On Mon, Sep 9, 2024 at 10:29 AM Rich Salz via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Rich Salz
Review result: Has Issues
I don't think anything here is a serious issue, but they would be enough to
raise a DISCUSS in my view.
Concealed doesn't seem like a great name for the mechanism, as nothing about it
is hidden. Perhaps TLS-Export or something along those lines? Although I guess
Sec 8 gives a reasonable rationale.
As much as I appreciate your suggestion, we're going to keep the bikeshed in its
current color. We discussed this at length as a working group and landed on
something that everyone can live with, so we'll stick with that.
Sec 2. "mapping of authorized key IDs to their associated public keys." The
antecedent for "their" should be more clear.
Good point. I removed the word "their":
Figure 1. What do the "(16)" "(i)" "(..)" mean?
As mentioned in the "Conventions and Definitions" section, this is QUIC notation.
Using the same notation for
different numbering schemes is bad.
Can you elaborate on what you meant here? What are the different numbering
schemes?
Sec 3.1, I think using QUIC minimum encoding is not a good idea as it makes
things more complicated, easier for apps to get wrong, (does the exporter code
have to check?). Just use a fixed-size of 2 or 4 bytes.
QUIC encoding was not an issue for any of the four independent implementations.
This can be written in less than ten lines of code in any language. The exporter
doesn't check because the context isn't sent over the wire, it's something the
application passes in to the TLS key exporter function.
Saying SigAlg is in
network-byte order and then referring to the TLS registry might be confusing;
for RSA-PKCS-SHA1 do I sent 02,01 or 01,02?
Can you elaborate on what the confusion here is? If I look at the IANA registry [1],
or at where it's defined in RFC 8446 [2], both list rsa_pkcs1_sha1=0x0201.
Encoding 0x0201 in network byte order is well defined as {0x02, 0x01}.
Sec 5. It would be nice to have an example showing a realm. And nice to have
the private key disclosed so that implementors can use this as a test vector.
Unfortunately test vectors aren't very useful when it comes to TLS exporters,
because the exporter depends on random data from the TLS handshake.
Because of this, we made the conscious decision to not include them.
Given this uses TLS exporting and such, and that this is likely to be in a TLS
library (maybe that's wrong), what was the reasoning for not using TLS
presentation syntax?
This is not implemented inside TLS libraries. All implementations were made
by modifying the HTTP layer without touching TLS code. Hence the use of
QUIC syntax and not TLS, as was done in HTTP/3.
Figure 2. Same point about the (256) notation and question about TLS
presentation syntax
Same answer.
Sec 3.3, to emphasize my notation point, this says all 32 bytes (and it should
be *each* of its 32 bytes), but the data structure is defined in bits.
You're correct, QUIC notation is in bits but prose is generally in bytes.
Sec 4.1, "This can be used to point to a server-side database". That seems to
be implied/mandated by Sec 2 and my comment on it.
Good point. I've fixed this to now say "This is used by the backend to
point to an entry in a server-side database of known keys" and added areference to s6.3:
https://github.com/httpwg/http-extensions/commit/28c5e729bfa293dc2bf5384e5938f63caa84ad2d
Sec 6.2 and Sec 4. ABNF and structured-fields, both in one spec? I guess so,
given the Authorization header field is old-school, but it looks funny.
Totally agree with you there. We discussed this with the HTTPBIS WG, and
it was the only option since Authorization isn't a structured field.
Sec 6.3 So the backend MUST have a database?
Yes. Though we use "database" in the wider sense like "a structured set of
data held in a computer".
Sec 7. Nice.
:-)
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
