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. [Section 1] * The introduction should also mention that this document updates RFC 6698 and in what respect. [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 ... [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) [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) [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? [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 ... [Section 9.1] * It says: > All columns are mandatory. I think you mean > It is mandatory to specify content in all the columns. [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 [Sections 9.5-9.12] * It says: > The columns ... are mandatory. I think you mean: > The fields ... are mandatory. [Sections 9.14-9.18] * s/Change controller: IESG/Change controller: IETF [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 * 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 [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". [Section 9.21] * "X.509 Public Key Algorithms" seems to be remnant text from somewhere else. [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 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: Michael Jones <[email protected]> Sent: Tuesday, July 15, 2025 7:47 PM To: Ivaylo Petrov <[email protected]>; cose <[email protected]> Cc: Cose Chairs Wg <[email protected]>; [email protected] <[email protected]> Subject: [COSE] Re: WGLC for draft-ietf-cose-cbor-encoded-cert-14 This is a reminder to the working group that the working group last call is under way. Please reply with your views, even if it’s just to say that you believe the document is ready for publication once the review comments below are addressed. Authors, please respond to the review comments below. Thanks all, -- Mike From: Ivaylo Petrov <[email protected]> Sent: Sunday, July 6, 2025 6:25 AM To: cose <[email protected]> Cc: Cose Chairs Wg <[email protected]>; [email protected] Subject: [COSE] Re: WGLC for draft-ietf-cose-cbor-encoded-cert-14 Posting this here as an individual. The draft fills an important gap and it is generally easy to read. Here are my high level comments and questions: 1. > As the contents of c5b, c5c, c5t, and c5u are untrusted input, the header > parameters > can be in either the protected or unprotected header bucket. The trust > mechanism MUST process any certificates in the c5b, c5c, and c5u parameters as > untrusted input. The presence of a self-signed certificate in the parameter > MUST > NOT cause the update of the set of trust anchors without some out-of-band > confirmation. I would expect something in the security considerations to point back at this, but I didn't see anything. 2. c5b, c5c, c5t, c5u have early allocations. Probably those should be referenced in the draft instead of TBD1... 3. Sec 3.6 Deterministic encoding What happens if the decoder doesn't know the int value for an extensionID? Does this have security implications? 4. The security considerations section feels fairly short. It might be more relevant to discuss elsewhere, but how should an implementation behave when invalid input is provided? For example in sec 3.1.10. Nits: 5. FYI: The formatting of the table in sec 9.4 and a number of others afterwards in the PDF version is broken. 6. s/certificates with over 50%/certificates by over 50%/ 7. s/CBOR ecoding/CBOR encoding/ 8. s/subjectPublicKey consist of only/subjectPublicKey consists of only/ 9. s/as well as the any leading 0x00/as well as any leading 0x00/ 10. s/certSerialNumberm/certSerialNumber/ 11. s/SAFI is not present/SAFI are not present/ 12. s/the unused bits in max IPAddress is set to ones/the unused bits in max IPAddress are set to ones/ 13. s/with the the difference/with the difference/ 14. s/An empty CBOR array indicate/An empty CBOR array indicates/ 15. s/constrained wireless links/constrained wireless link/ 16. For the example HTTPS certificate chains... - the sentence sounds not very clear. 17. s/C509 use dedicated/C509 uses dedicated/ 18. s/Because of difference in size,/ Because of the difference in size,/ 19. s/common key usage digitalSignature/common key usage of digitalSignature/ -- Ivaylo On Fri, Jul 4, 2025 at 5:15 PM Ivaylo Petrov <[email protected]<mailto:[email protected]>> wrote: This note starts a Working Group Last Call (WGLC) for the CBOR Encoded X.509 Certificates (C509 Certificates) specification https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-14.html. The WGLC will run for a bit over two weeks, ending after the Hackathon at IETF 123 on Sunday, July 20, 2025. Please review and send any comments or feedback to the working group at [email protected]<mailto:[email protected]>. Even if your feedback is “this is ready for publication”, please let us know. A note from the authors is also useful. Thank you, -- Ivaylo and Mike, COSE Chairs P.S: I will be providing a review as an individual shortly, but I wanted to start the WGLC sooner rather than later.
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
