Hi Göran, Thanks for addressing my comments. The PR looks good to me.
Best, /Marco Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se ________________________________ From: Göran Selander <[email protected]> Sent: Monday, July 21, 2025 9:11 AM To: Marco Tiloca <[email protected]>; Michael Jones <[email protected]>; Ivaylo Petrov <[email protected]>; cose <[email protected]> Cc: Cose Chairs Wg <[email protected]>; [email protected] <[email protected]> Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-cbor-encoded-cert-14 Hi Marco, Thanks for your review! Please see detailed responses inline below. We have tried to address all comments in PR#262 <https://github.com/cose-wg/CBOR-certificates/pull/262> . Please let us know if we missed something. Göran From: Marco Tiloca <[email protected]> Date: Friday, 18 July 2025 at 10:03 To: Michael Jones <[email protected]>, Ivaylo Petrov <[email protected]>, cose <[email protected]> Cc: Cose Chairs Wg <[email protected]>, [email protected] <[email protected]> Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-cbor-encoded-cert-14 Hi Mike and all, I have reviewed the draft and I think it's basically ready. Please find some minor comments below. Best, /Marco ======================================== [Abstract] * The second from last sentence should explicitly say that, because of that extension, this document updates RFC 6698. [GS: We gave the full explanation only in the introduction.] [Section 1] * The introduction should also mention that this document updates RFC 6698 and in what respect. [GS: OK] [Section 3] * It says: > ... the order of elements in arrays are always encoded in the same order as the elements or the ... Should be: > ... the elements in arrays are always encoded in the same order as the elements of the ... [GS: OK] [Section 3.1.4] * s/as CBOR null/as the CBOR simple value null (0xf6) (I suggest the same for other instances of "CBOR null" and "null" throughout the document) [GS: We did this for first occurrence.] [Section 3.1.10] * s/CBOR true/CBOR simple value true (0xf5) (I suggest the same for other instances of "CBOR true" and "true" throughout the document) [GS: We did this for first occurrence.] [Section 6] * It says: > For protocols like TLS/DTLS 1.2, where the handshake is sent unencrypted, ... I guess you refer to the peers' certificates sent unencrypted during the handshake, right? [GS: We now mention certificates.] [Section 8] * It says: > The CBOR profiling of X.509 certificates does not change ... While Section 1 says: > This document does not specify a certificate profile. Here in Section 8, I think you actually mean: > The CBOR encoding of X.509 certificates does not change ... [GS: OK] [Section 9.1] * It says: > All columns are mandatory. I think you mean > It is mandatory to specify content in all the columns. [GS: OK] [Sections 9.1-9.12] * It says: > For values in the interval [-24, 23] the registration procedure is "IETF Review" and "Expert Review". Combined together? That's effectively a new policy "IETF Review with Expert Review", which has to be described here as the combination of the two individual ones from BCP 26. When doing so, it should also be described how and to what extent the early allocation procedure from BCP 100 applies. High-level guidance was noted down in [0], while [1][2][3] are concrete recent cases where combined policies have been defined. A single paragraph should be sufficient, as covering all the sections in question. [0] https://datatracker.ietf.org/doc/html/draft-bormann-gendispatch-with-expert-review [1] https://www.ietf.org/rfc/rfc9668.html#section-8.3 [2] https://www.ietf.org/rfc/rfc9668.html#section-8.3 [3] https://www.ietf.org/rfc/rfc9770.html#section-15.5 [GS: Done] [Sections 9.5-9.12] * It says: > The columns ... are mandatory. I think you mean: > The fields ... are mandatory. [GS: OK] [Sections 9.14-9.18] * s/Change controller: IESG/Change controller: IETF [GS: OK] [Section 9] * s/add media types/add entries (3 instances) * As per [4] and [5], the columns of the registry are - Content Type - Content Coding - Media Type - ID - Reference [4] https://datatracker.ietf.org/doc/html/draft-ietf-core-cf-reg-update-09 [5] https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats [GS: Done] * As per [6]: OLD: application/cose-c509-cert "usage" = "chain" NEW: application/cose-c509-cert;usage=chain OLD: application/cose-certhash "usage" = "c509" NEW: application/cose-certhash;usage=c509 [GS: Done] [6] https://datatracker.ietf.org/doc/html/draft-ietf-core-cf-reg-update-09#section-4.1.4 * Can the last entry actually be added as-is? The media type "application/cbor" does exist, but I am not sure that the Content Type specified in the first column can have a note like "containing a URI". [GS: Media type for application/cbor do exist as well as Content-Format, so we removed this row in the table] [Section 9.21] * "X.509 Public Key Algorithms" seems to be remnant text from somewhere else. [GS: Right, copy-paste error, fixed.] [Nits] * Abstract - s/with over 50%/by over 50% - s/The document/This document * Section 1 - s/significantly which/significantly, which - s/by e.g. encoding/by, e.g., encoding - s/e.g. null/e.g., null - s/with over 50%/by over 50% - s/ecoding/encoding - s/as in 1/as in the first variant above - s/; and a TLS certificate type/; a TLS certificate type - s/, and a C509 file format/; and a C509 file format * Section 3.1 - s/e.g. Appendix/e.g., Appendix * Section 3.1.4 - s/In CBOR all text/In CBOR, all text - s/e.g. emailAddress/e.g., emailAddress - s/'A'-'F' it is/'A'-'F', it is - s/+1 it is for/+1, it is for - s/does not correspond/do not correspond - s/i.e. SpecialText/i.e., SpecialText - s/e.g. in case/e.g., in case * Section 3.1.7 - s/assumes the BIT STRING/assumes that the BIT STRING * Section 3.1.10 - s/means the extension/means that the extension - s/is CBOR int encoded 'extensionID' is specified/is a CBOR int encoded 'extensionID' are specified * Section 3.1.12 - s/assumes the BIT STRING/assumes that the BIT STRING - s/certificates the signatureValue/certificates, the signatureValue * Section 3.2.1 - s/i.e. [ modulus/i.e., [ modulus - s/exponent is omitted and/exponent are omitted and - s/subjectPublicKey consist of/subjectPublicKey consists of * Section 3.2.2 - s/as well as the any leading/as well as any leading * Section 3.3 - s/databases most IDs/databases, most IDs - s/therefore omitted/therefore are omitted - s/is set to ones/are set to one - s/as an uint/as a uint - s/NULL it can/NULL, it can - s/empty string h''/empty byte string h'' (2 instances) * Section 3.4 - s/and uses a/and use a * Section 3.5 - s/see e.g. [RFC7468]/see, e.g., [RFC7468] * Section 6 - s/and use that/and uses that - s/gateway which allows/gateway, which allows - s/overhead, however, measured in energy this/overhead. However, measured in energy, this * Section 8 - s/in this draft/in this document * Section 9 - s/duplicate one that/duplicate one entry that - s/a 1-byte encodings/a 1-byte encoding - s/a 2-byte encodings/a 2-byte encoding - s/have 3-byte encodings/have a 3-byte encoding * Sections 9.1-9.12 - s/ 23] the registration/ 23], the registration - s/values the registration/values, the registration * Section 9.12.1 - s/specify a number/specifies a number - s/, make them suitable/ make them suitable [GS: Nits in a separate commit in PR#262 <https://github.com/cose-wg/CBOR-certificates/pull/262> ] Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
