[COSE] Re: WGLC for draft-ietf-cose-cbor-encoded-cert-14

[Ivaylo Petrov <[e-mail]>]

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 <[e-mail]>
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 <ivaylopetrov=[e-mail]>
> *Date: *Sunday, 6 July 2025 at 15:25
> *To: *cose <[e-mail]>
> *Cc: *Cose Chairs Wg <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *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 <[e-mail]>
> 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
> [e-mail].  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.
>
>