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

[Michael Jones <[e-mail]>]

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