Hi Ivaylo, Thanks for your review!
We agree with all the comments and have tried to address them in PR #261<https://github.com/cose-wg/CBOR-certificates/pull/261> (separate commit for the nits): Please let us know if we missed something. Göran From: Ivaylo Petrov <[email protected]> Date: Sunday, 6 July 2025 at 15:25 To: 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 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]
