Éric Vyncke has entered the following ballot position for draft-ietf-cose-cbor-encoded-cert-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-cose-cbor-encoded-cert-17 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Ivaylo Petrov for the shepherd's write-up including the WG consensus *BUT* it lacks the justification of the intended status. Other thanks to Ted Lemon, the DNS directorate reviewer: https://datatracker.ietf.org/doc/review-ietf-cose-cbor-encoded-cert-17-dnsdir-telechat-lemon-2026-03-30/ (and I have read the previous email threads with the authors) I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Section 3.3 About "IpAddrBlocks", the whole text is a little unclear to me to be honest, so I may have misread the specification BUT the text `It should be noted that using address differences for compactness prevents encoding an address range larger than 2**64 - 1 corresponding to the CBOR integer max value.` seems really a bad choice for IPv6 addresses as the usual prefix size if 64-bit long. I.e., the encoding cannot cope with 2001:db8::/63. There are no examples in the appendix about this encoding, and this does not help the reader. Also very unclear to me (missing references and how to use): `IPAddressFamily = (AFI: uint, SAFI: uint / null, IPAddressChoice)` The text `as specified in [I-D.ietf-lamps-macaddress-on]` makes the reference normative. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Section 1 Please add a reference to `IEEE 802.1AR (DevID)`. Also add references to `C509 is deployed in, e.g.,...`` ### Section 3.1.8 (and others) What does `Not supported.` mean in this case ? Should the text be explicit and state that if this field exist in the X.509 then no C509 can be generated? (just to be clear) ### Section 3.3 About "Name Constraints" s/where the last octet indicates the number of bits in the *netmask*/where the last octet indicates the number of bits in the *prefix*/ About "IPAddrBlocks", just wondering why not using the 'number of used octets' as it is closer to the usual CIDR/IPv6 prefix notation in `Each AddressPrefix is encoded as a CBOR bytes string (without the unused bits octet) followed by the number of unused bits encoded as a CBOR uint` ? `KeyIdentifier SHOULD be composed of the leftmost 160-bits of the SHA-256 hash of the CBOR encoded subjectPublicKey. Other methods of generating unique numbers can be used.` why a SHOULD as other methods can be used ? This sentence does not seem to follow https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/. ### Section 9 Suggest adding informative reference to the newly created IANA registries *AND* updated existing registries. Somehow like Med Boucadair, I am puzzled by the last paragraph as it is confusing at the best while trying to paraphrase RFC 8126. Let's rather delete it. ### Section A.3.1 Please avoid using real FQDN (e.g., `sni.cloudflaressl.com`) in IETF documents, rather use "example.org" _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
