[Gen-art] Re: draft-ietf-cose-cbor-encoded-cert-16 ietf last call Genart review

[Göran Selander <[e-mail]>]

Russ,

Thanks for your review. We incorporated all comments, as well as the two "additional thoughts" in -17.

Göran

From: Russ Housley via Datatracker <[e-mail]>
Date: Wednesday, 28 January 2026 at 21:00
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: draft-ietf-cose-cbor-encoded-cert-16 ietf last call Genart review

Document: draft-ietf-cose-cbor-encoded-cert
Title: CBOR Encoded X.509 Certificates (C509 Certificates)
Reviewer: Russ Housley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cgoran.selander%40ericsson.com%7C21973145df00487d5d9308de5ea7dfcf%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639052272266748447%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nWWxhCJLzjc%2FyoLz38307yxnykCdytrq0ylfq2kihDI%3D&reserved=0<https://wiki.ietf.org/en/group/gen/GenArtFAQ>>.

Document: draft-ietf-cose-cbor-encoded-cert-16
Reviewer: Russ Housley
Review Date: 2026-01-28
IETF LC End Date: 2026-02-10
IESG Telechat date: unknown


Summary: Ready with Nits


Major Concerns:  None


Minor Concerns:

Section 1: The two types of C509 certificates (CBOR encoding of DER-
encoded X.509 certificates and natively signed C509 certificates) is
discussed at the beginning of the introduction and the end of the
introduction.  It would be more desirable to talk about this in only
one spot.

Section 1 says:

   The use of CBOR also reduces code complexity, code
   size, memory usage, and CPU usage.

This is not true for the case where C509 carries a signature on the
X.509 certificate.  Please add some qualification.

Figure 5: It would be good to see an ML-DSA certificate in this table.
The public key and signature will not compress, so the comparison will
help implementeres determine whether C509 is worth the time to write
the code.


Nits:

General: s/DER encoded/DER-encoded/ (many places)

General: s/Weierstraß/Weierstrass/ (for string search in other RFCs)

Section 1: s/We recommend implementors to get used/Implementors can get used/

Section 3: s/DER encoded [RFC5280] X.509 certificates/
            /DER-encoded X.509 certificates [RFC5280]/

Section 6: s/DER encoded RFC 2986 CertificationRequestInfo/
            /DER-encoded CertificationRequestInfo [RFC2986]/


Additional Thoughts:

1.  Section 4: It would be easy to add support for the attribute
specified in RFC 9883.  If ML-DSA and ML-KEM achieve wide deployment
outside the Web PKI, support for this CSR attribute will be needed.  I do
not want to delay approval of this document, bit is looks like this would
be a straightforward addition.

2.  There is an Internet-Draft for otherName that contains a MAC address
going through the LAMPS WG.  Based on Section 3.1.4 that has special logic
for EUI-64, this may be of value to some implementers.  We can get an early
assignment of the OID is there is interest in adding support for this new
otherName form to this document.  If so, it may deserve some language in
Section 3.3.