Hi Göran, Thanks for addressing my comments. Your PR looks good to me!
Thanks, Ivaylo On Mon, Jul 21, 2025 at 8:58 AM Göran Selander <[email protected]> wrote: > 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]> > 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]. 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]
