Secdir last call review of draft-ietf-httpbis-unprompted-auth-10

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.

Sec 2. "mapping of authorized key IDs to their associated public keys."  The
antecedent for "their" should be more clear.

Figure 1.  What do the "(16)" "(i)" "(..)" mean? Using the same notation for
different numbering schemes is bad.

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

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.

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?

Figure 2. Same point about the (256) notation and question about TLS
presentation syntax

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.

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.

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.

Sec 6.3 So the backend MUST have a database?

Sec 7.  Nice.

Received on Monday, 9 September 2024 17:29:25 UTC