Dear Working Group,

To confirm our discussion during IETF 123, Mike and I believe there is
sufficient support to demonstrate working group consensus for publication.
Thank you to everyone who participated.

Robert Moskowitz, please provide any feedback you might still have at your
earliest convenience.

Editors, please inform the chairs when you believe you have addressed the
working group's last call feedback.

The chairs will select a shepherd for the draft. If you are interested in
this role, please let us know.

Best regards,
Ivo and Mike (as chairs)

On Tue, Jul 22, 2025 at 9:58 AM Ivaylo Petrov <ivaylopet...@google.com>
wrote:

> 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 <
> goran.selan...@ericsson.com> 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=40google....@dmarc.ietf.org>
>> *Date: *Sunday, 6 July 2025 at 15:25
>> *To: *cose <cose@ietf.org>
>> *Cc: *Cose Chairs Wg <cose-cha...@ietf.org>,
>> draft-ietf-cose-cbor-encoded-cert.auth...@ietf.org <
>> draft-ietf-cose-cbor-encoded-cert.auth...@ietf.org>
>> *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 <ivaylopet...@google.com>
>> 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
>> cose@ietf.org.  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 -- cose@ietf.org
To unsubscribe send an email to cose-le...@ietf.org

Reply via email to