Ballot for draft-ietf-cose-cbor-encoded-cert
Yes
No Objection
No Record
Summary: Has enough positions to pass.
I'm balloting no obj, but there are substantial comments to address. I did consider abstaining, see my 'general comment' near the top of my ballot. Thanks to Corey Bonnell for their secdir reviews. I agree with many points in their review, and I would like to see their comments addressed. Thanks to Chris Inacio for deferring this draft for a telechat cycle, it is a complex draft for which I needed the extra time. General: While one can claim that CBOR encoded certs eliminate the need for ASN.1 implementation, that only works if the C509 cert can only be CBOR encoded. As it stands implementations now need both CBOR and ASN.1 depending on what certificates are being used. Instead of reduced complexity, there is now double the complexity. In addition, the choices that can be made for various field selections also increase the complexity, which under normal circumstances reduces interoperability. Sadly there is only one prototype implementation currently. I'll be curious to see what the uptake is for this idea as it stands. Section 1, para 5: This could easily be deleted as it is repetitive with the para above. If it is left in the specification, please look at the sentence construction (it is indeed only a single sentence) that makes little sense after the 'e.g,' and then 'or' and then 'and'. Section 1, #1: Please add a note to say that validating the signature on the certificate first requires that it is reverted back to the original X.509 certificate. Section 1, second to last para: I would incorporate this information in #2 above it. (again, a paragraph with a single sentence) Section 3.1.4, para 2: Why is the construction of serialNumber in this section vice Section 3.1.2? Section 3.1.4, para 4: Is this 'extension' part of the issuer name, or part of what is described in Section 3.1.10? Section 3.1.5: Do you need a reference for 'POSIX time'? Section 3.1.6: Should 'CBOR simple value' be 'CBOR simple value null'? (it is phrased that way in Section 3.1.4 and 3.1.5. Section 3.1.8 & 3.1.9: Where do these fields originate? Section 3.3, para 3: Does this mean that the actual OID is the same regardless of the name? Or that there are multiple registered OIDs for the same extension? Please clarify if it is the former. If it is the latter, then specifying which OID is expected will make implementation less complex. Section 3.3.1, key usage: Isn't key usage normally critical? Wouldn't an example of that be more useful? Section 8.1, para 1: I wonder how a DE will determine if a request can be solved in a 'better in a different way'. 'Better' being very subjective. Section 8.14: Why are SHA-1 algorithms being registered (even if they are marked as 'deprecated')?
Thanks for the work done in this document and for addressing my previous blocking and non-blocking comments. https://mailarchive.ietf.org/arch/msg/cose/PR2QT5WGx6Eb3LtU6whdWYXHktI/ (for archive)
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/
Thanks to the authors and the WG for their work on this document. Please find below some comments and some clarifications sought to help improve the document. 1) In some of the IANA sections, e.g., section 8.6, there is a "Comments" field and those actually reference normative specifications. Not being someone familiar with this area, I am unable to determine if "Comments" mean "Specifications" or something else. In any case, does "comments" seem the right title for the column if it has mainly normative specifications? 2) There is some text under IANA considerations in section 8.15.1 that seem not related to or suitable for that section and instead should be perhaps elsewhere in the document. Please cross-check. 3) Issues with references? - RFC2247 and GSMA-SGP.22 are listed as informative reference, but are not referenced anywhere. - RFC6962 and RFC8398 referenced normatively has been obsoleted by RFC9162 and RFC9598 respectively. - RFC1274 referenced informatively has been obsoleted by RFC4524. - draft-ietf-lamps-rfc7030-csrattrs has been published as RFC9908; also please cross-check that it is not normative along the lines of RFC7030 I note that the shepherd write-up indicates 5 authors while the document actually has 6. This is just to bring to the attention of the responsible AD as it exceeds the normally expected number.
# IESG review of draft-ietf-cose-cbor-encoded-cert-18 CC @MikeBishop ## Comments ### IANA This document seems to have unresolved IANA issues. Have next steps been determined? ### Section 8.1, paragraph 1 ``` The expert reviewers for the registries defined in this document are expected to ensure that the usage solves a valid use case that could not be solved better in a different way, that it is not going to duplicate an entry that is already registered, and that the registered point is likely to be used in deployments. They are ``` These things are vague enough to give me concern; not quite DISCUSS-level, but I worry that we're inviting appeals from registrants who disagree with the reviewer on the "best" preferred solution. ### Section 8.6, paragraph 1 How does "If OID is present" reconcile with "OID [is] mandatory"? ### Section 8.6, paragraph 1 Is the goal that all elements of some existing registry are assigned mapped values here? If so, synchronization becomes a concern, and adding a column to that registry might be preferable. If it's independent and just linked to that other registry by OID, this is probably the best we can do. ### Too many authors The document has six authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ### Missing references No reference entries found for these items, which were mentioned in the text: `[bytes]`. ### DOWNREFs DOWNREF `[RFC7299]` from this Proposed Standard to Informational `RFC7299`. (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and also seems to not appear in the DOWNREF registry. Reference only appears to be for a registry reference.) ### IP addresses Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges: `23.106.104.0`, `2.5.29.15`, `2.5.29.37`, `2.5.4.41`, `2.5.4.11`, `2.5.4.8`, `23.109.0.0/16`, `2001:7f9:ffff:ffff:ffff:ffff:ffff:ffff`, `2.5.4.12`, `2.5.29.30`, `2.5.4.20`, `23.111.63.255`, `2.5.29.14`, `2.5.4.43`, `2.5.29.32`, `2.5.4.4`, `2.5.4.6`, `2.5.29.54`, `2.5.29.31`, `23.106.119.255`, `22.82.0.0/16`, `2.5.4.15`, `2.5.29.35`, `2.5.29.46`, `1.3.101.113`, `2.5.4.97`, `2002:8:0:ffff:ffff:ffff:ffff:ffff`, `2.5.4.17`, `2001:bff:ffff:ffff:ffff:ffff:ffff:ffff`, `23.111.16.0`, `2.5.4.42`, `2.5.4.65`, `1.3.101.111`, `1.3.101.110`, `2.5.29.18`, `2.5.4.3`, `2.5.4.7`, `2.5.4.44`, `2.5.4.5`, `2.5.29.19`, `2.5.4.46`, `2.5.4.9`, `2.5.29.9`, `2.5.29.36`, `2.5.4.54`, `23.83.112.0/20`, `1.3.101.112`, `2.5.29.17`, `2.5.29.33`, and `2.5.4.10`. ## Nits 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. ### Typos #### Section 3.3, paragraph 42 ``` - CBOR uint. With the exception of the first ASId, the ASid is - ^ - encoded as the difference to the previous ASid. - ^ + CBOR uint. With the exception of the first ASId, the ASId is + ^ + encoded as the difference to the previous ASId. + ^ ``` #### Section 3.8, paragraph 1 ``` - In TLS and DTLS, the subject of trusted authory may be sent to the + In TLS and DTLS, the subject of a trusted authority may be sent to the + ++ ++ ``` #### Section 7, paragraph 5 ``` - handled exactly as how such errors would be handled for the - ---- ``` ### Section 8.23, paragraph 1 ``` This document registers the following entry in the "SMI Security for ^^ ``` ### Uncited references Uncited references: `[RFC2247]`, `[RFC1274]`, `[RFC6960]`, `[X.520]`, `[RFC6962]`, `[RFC3161]`, and `[GSMA-SGP.22]`. ### Outdated references Reference `[RFC6962]` to `RFC6962`, which was obsoleted by `RFC9162` (this may be on purpose). Reference `[RFC8398]` to `RFC8398`, which was obsoleted by `RFC9598` (this may be on purpose). Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may be on purpose). Reference `[RFC1274]` to `RFC1274`, which was obsoleted by `RFC4524` (this may be on purpose). Document references `draft-ietf-lamps-RFC7030-csrattrs`, but that has been published as `RFC9908`. ### Grammar/style #### Section 3.3, paragraph 26 ``` encoded as an int. The policyQualifierId is encoded as an CBOR ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 3.3, paragraph 38 ``` and for IPv6 addresses, the field MUST contain 17 octets, where the last octet indicates the number of bits in the prefix. As an ``` While it's clear after a moment how to parse, consider ending the sentence after "17 octets" and starting a new sentence, "In both cases, the last...." #### Section 3.3, paragraph 55 ``` e calculated over ~C509Certificate. Thus C509CertData contains all data neces ^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Thus". #### Section 3.5, paragraph 5 ``` ay be sent to the peer to help it selecting the certificate chain, as in the ^^^^^^^^^ ``` The verb "help" is used with an infinitive. #### Section 4.4, paragraph 12 ``` the remaining text strings are minimal in size. Therefore, the further size r ^^^^^^^^^^^^^^^ ``` This wording could be more concise. #### Section 6.2, paragraph 2 ``` t could not be solved better in a different way, that it is not going to dup ^^^^^^^^^^^^^^^^^^ ``` Consider replacing this phrase with the adverb "differently" to avoid wordiness. #### Section 6.2, paragraph 3 ``` eview with Expert Review" are made on a "IETF Review" basis per Section 4.8 o ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 8.20, paragraph 3 ``` erences [CAB-Code] CA/Browser Forum, "CA/Browser Forum, "Baseline Requiremen ^ ``` Unpaired symbol: """ seems to be missing. #### Section 8.20, paragraph 3 ``` gning/>. [CAB-TLS] CA/Browser Forum, "CA/Browser Forum, "Baseline Requirement ^ ``` Unpaired symbol: """ seems to be missing.
Hi John, Göran, Shahid, Joel, and Martin, Many thanks for the well-written document. Excellent work. Thank you for the discussion and changes made in [1] to address comments in my previous ballot [2]. I appreciate that consistency is followed by the authors vs the resolution to a similar DISCUSS for RFC9668, but some of that text smells like updating the rules in RFC7120. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cose-cbor-encoded-cert-17&url2=draft-ietf-cose-cbor-encoded-cert-18&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/cose/m6QDwcY8SkSDtsUuLaJLOA-OfLY/
Thank you to Russ Housley for the GENART review. Thank you for addressing my DISCUSS and COMMENT feedback. === ** Section 1. Editorial. Implementors can get familiar with CBOR by using the CBOR playground [CborMe]. It is not clear what the value of this text for an archival document.