Ballot for draft-ietf-cose-cbor-encoded-cert
Discuss
Yes
No Objection
No Record
Ballot deferred by Christopher Inacio on 2026-04-13.
Summary: Needs a YES. Has 2 DISCUSSes. Needs 7 more YES or NO OBJECTION positions to pass.
# É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.
## 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"
Hi John, Göran, Shahid, Joel, and Martin,
Many thanks for the well-written document. Excellent work.
I have two points to check. I flagged some few nits and minor edits that I will send to the authors in a PR.
# IETF Review with Expert Review
CURRENT:
All assignments according to "IETF Review with Expert Review" are made on a "IETF Review" basis per {{Section 4.8 of RFC8126}} with "Expert Review" additionally required per {{Section 4.5 of RFC8126}}.
and
the registration procedure is "IETF Review with Expert Review".
I remember that Carsten edited draft-bormann-gendispatch-with-expert-review, but do we have a stable reference where such policy is defined?
# The WG may be closed: not sure how this guidance will age
CURRENT:
In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of {{RFC7120}}.
# Is this already deployed there or these are deployment targets? CURRENT: C509 is deployed in, e.g., in-vehicle and vehicle-to-cloud communication, Uncrewed Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS) “is deployed” won’t age well in an RFC, btw. # Please consider adding a reference CURRENT : the CBOR encoding can in many cases reduce the size of RFC7925 profiled certificates by over 50%. # Any reason why this is repeated here? CURRENT: The procedure for early IANA allocation of "standards track code points" defined in {{RFC7120}} also applies. Cheers, Med
Many thanks for the write-up. Appreciated. My observation is that while the shepherd writeup claims nothing noteworthy when running idnits, but when i run idnits (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-17.txt) i end up with a long laundry list of observations. Maybe worthwhile to run through the list and explain why they are deemed not meaningful/relevant and add this context in the write-up? One of those idnits observations is that there may only be v4 examples and no v6 examples? G/