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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
