Ballot for draft-ietf-cdni-uri-signing
Note: This ballot was opened for revision 21 and is now closed.
Francesca Palombini Yes
Thank you for the work on this document. One more comment to add to those of my fellow ADs: please align the claim description and the section name for the Client IP (cdniip) claim (description in IANA section 6.6.1 is "CDNI IP Address"). Francesca
Alvaro Retana No Objection
Erik Kline (was Discuss) No Objection
Thanks for addressing my earlier concern.
John Scudder No Objection
Lars Eggert No Objection
Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/ppG3onLlgjXu_hULqu3LVQPq0iY). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1.2. , paragraph 3, nit: > e way in the initial steps #1 and #2 but the later steps involve multiple CD > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 2. , paragraph 2, nit: > gistry claim name is specified in parenthesis below) are used to enforce the > ^^^^^^^^^^^^^^ Did you mean "in parentheses"? "parenthesis" is the singular. Section 2.1. , paragraph 6, nit: > If the received signed JWT contains a Expiry Time claim, then any JWT subse > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 2.1.7. , paragraph 2, nit: > rejected if sourced from a client outside of the specified IP range. Since th > ^^^^^^^^^^ This phrase is redundant. Consider using "outside". Section 2.1.8. , paragraph 2, nit: > , and mobile clients switching from WiFi to Cellular networks where the clie > ^^^^ Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi Alliance.). Section 2.1.15. , paragraph 4, nit: > ed URIs would require to be valid for a at least 30 minutes, thereby reducing > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 220.127.116.11. , paragraph 6, nit: > s generated, the model is not broken and the User Agent can successfully ret > ^^^^ Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). Section 3.3. , paragraph 2, nit: > orm verification, regardless of whether or not the URI is signed. Type: Bool > ^^^^^^^^^^^^^^ Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". These URLs in the document can probably be converted to HTTPS: * http://www.iso.org/standard/65274.html * http://www.iana.org/assignments/jwt * http://pubs.opengroup.org/onlinepubs/9699919799/
Martin Duke No Objection
Murray Kucherawy No Objection
The IANA Considerations section creates two registries under Specification Required rules. RFC 8126 recommends that the defining document include advice to the designated experts (thank you for volunteering, by the way) about how to evaluate new submissions, but none are included here. Are any appropriate? This seems to be my pet peeve this week, but I'm wondering about most of the SHOULDs in this document. Why aren't they MUSTs? Or in the alternative, could we include some guidance about when an implementer might legitimately choose to deviate from what the SHOULD says to do? I support Roman's DISCUSS position about Section 1.3.
Robert Wilton No Objection
Roman Danyliw (was Discuss) No Objection
Thanks for addressing by DISCUSS and COMMENT feedback on the original ballot on -21. Also, thanks to Brian Campbell and other OAuth WG members for the discussion on the reuse of the same jti claim value when signing different JWT content (i.e., what constitutes “different data object(s)”) across multiple CDNs.
Éric Vyncke (was Discuss) Abstain
Thank you for fixing all my previous COMMENTs in the -22 revision and addressing parts of my previous DISCUSS by using “NOT RECOMMENDED” in section 2.1.10 in the -24 revision. I am afraid that I still do not see the value of having cdniip in this document, but, as I do not want to block this document, I am balloting ABSTAIN. The section 7 (security considerations) is still very light on the IP address sharing. I would welcome some applicability statements on the use of cdniip. -éric == DISCUSS (kept for archive) == -- Section 2.1.10 -- About "Client IP (cdniip) claim", I really wonder whether this could be used in real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public" IPv4 addresses that could select different public IPv4 addresses if badly designed. How will it work with dual-stack UAs where some connections could be over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data) UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN or CSP are upstream of the CGN) ? Also, "If the received signed JWT contains a Client IP claim" uses singular rather than "one or several" I also noted that Section 7 (security considerations) puts some restrictions on the usefulness of cdniip. I would welcome some applicability statements on the use of cdniip.
(Barry Leiba; former steering group member) Yes
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you (new for -26) for finalizing the switch to "MUST NOT" redistribute symmetric keys! Thank you for lowering the prominence of the cdniip claim/functionality, it is much appreciated. Thank you as well for updating the examples; I am too crunched for time to attempt to revalidate them before the AD cutover, but am happy to see that they were updated. I also appreciate the additional text covering the JWT "iss" usage and reinforcing that a key used to sign JWTs (regardless of whether it is identified using "iss") must be delivered in trusted configuration (i.e., not in-band). I would have preferred to see this point reiterated in the Security Considerations, as much of the new text is in the description of the usage of the "iss" claim (which one might expect to be irrelevant if the claim itself is not being used), but that is no longer a Discuss-level point based on the updates elsewhere in the document.
(Deborah Brungard; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection