Hi Deb, Again, thanks for your review. Here are the responses to your remaining comments, see inline below with reference to PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.
For overview of the state of the draft, see Editor’s copy<https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html>: Thanks, Göran From: Deb Cooley <[email protected]> Date: Tuesday, 28 April 2026 at 17:14 To: Göran Selander <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Deb Cooley's No Objection on draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT) Thanks for that quick response. The existence of implementations makes me feel better about the situation, including those in the shepherd's write up would have been awesome. I understand how easy it is to miss reviews. I think it was a big win having a PKI guy assigned to this draft as secdir reviewer! Deb On Tue, Apr 28, 2026 at 10:44 AM Göran Selander <[email protected]<mailto:[email protected]>> wrote: Hi Deb, Just a couple of quick reactions, mainly on the general comment, please see inline. More responses to the detailed comments will follow. Thanks, Göran From: Deb Cooley via Datatracker <[email protected]<mailto:[email protected]>> Date: Tuesday, 28 April 2026 at 15:08 To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Deb Cooley's No Objection on draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT) Deb Cooley has entered the following ballot position for draft-ietf-cose-cbor-encoded-cert-18: No Objection <snip> "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’. [GS: The paragraphs are now merged, see PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] 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. [GS: Done, see PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] Section 1, second to last para: I would incorporate this information in #2 above it. (again, a paragraph with a single sentence) [GS: Done, see PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] Section 3.1.4, para 2: Why is the construction of serialNumber in this section vice Section 3.1.2? [GS: 3.1.2 is about the Serial Number field of the certificate. 3.1.4 is about the RDN attribute serialNumber. There is room for disambiguation here, changed the former to “certificateSerialNumber”, see PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] 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? [GS: Typo, should read ‘attribute’, fixed in Editor’s copy<https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html>.] Section 3.1.5: Do you need a reference for 'POSIX time’? [GS: Done, see PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] 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. [GS: Correct, fixed in Editor’s copy<https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html>.] Section 3.1.8 & 3.1.9: Where do these fields originate? [GS: Optional fields in TBSCertificate of X.509, see RFC 5280.] 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. [GS: The former, added in PR#392<https://github.com/cose-wg/CBOR-certificates/pull/392>.] Section 3.3.1, key usage: Isn't key usage normally critical? Wouldn't an example of that be more useful? [GS: Perhaps, but there already an example of a critical extension in this section. Since that would just be a matter of changing the sign of the value, we didn't think all instances were necessary to represent as examples.] 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. [GS: Fixed in PR#389<https://github.com/cose-wg/CBOR-certificates/pull/389>] Section 8.14: Why are SHA-1 algorithms being registered (even if they are marked as 'deprecated')?" [GS: The intent with this document has been to create an encoding for certificates that are “out there”, not to give recommendations about what algorithms etc to use. We have updated the security considerations, see Editor’s copy<https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html>: "The specification makes no recommendations on the use of algorithms, paddings, or other security constructs applied in the encoding of a certificate. In particular, an IANA registration does not imply a recommendation. For example, some deprecated algorithms are assigned code points only for backward compatibility to enable CBOR encoding of existing certificates.”] Thanks, Göran
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
