IETF Last Call Review of draft-ietf-cose-cbor-encoded-cert-16
review-ietf-cose-cbor-encoded-cert-16-secdir-lc-bonnell-2026-02-09-00

Section 3.1.4
s/extension value/attribute value/

Section 3.2.2
The ECDSA signature encoding process can reference RFC 9053, section 2.1.

Section 3.3

The ASN.1 definition of id-pkix-ocsp-nocheck indicates the value will always be
NULL, so "If the extension value is NULL" is not needed. Instead, the same text
used for "Precertificate Signing Certificate" can be used.

"Precertificate Signing Certificate" is not the name of the extension, but is
rather a certificate for a signer of pre-certificates. I suggest using
"Precertificate Critical Poison" instead.

Section 8.

"The CBOR encoding of X.509 certificates does not change the security
assumptions needed when deploying standard X.509 certificates but decreases the
number of fields transmitted, which reduces the risk for implementation
errors." Is this true? The number of fields in a C509 certificate appears to be
the same as a X.509 certificate. If anything, the C509 specification appears to
be more complex than ASN.1-based X.509 due to the variable encoding of elements
in certain situations to minimize size.

"The gateway solution described in Section 6 requires unencrypted certificates
and is not recommended." I think this needs to be fleshed out, because it
assumes that certificates are secret information. In scenarios where
certificates are not secret, it is unclear whether this SHOULD NOT is relevant.

It would be good if there is an explicit MUST that certification path
processing (as defined in RFC 5280, section 6) be performed on C509
certificates before they can be considered trusted.

Section 9.13

The "Compressed subjectPublicKey" comment is potentially confusing, especially
for the EC Public Key types, as it might be read as a statement that compressed
point encoding is used for the coordinates.