Hi Paul, Thanks for the review!
We just submitted -16 addressing your comments, see responses below. We agree essentially on everything, details in this pull request: https://github.com/cose-wg/CBOR-certificates/pull/302 Thanks, Göran From: Paul Wouters <[email protected]> Date: Thursday, 8 January 2026 at 21:55 To: [email protected] <[email protected]> Cc: cose <[email protected]> Subject: AD review draft-ietf-cose-cbor-encoded-cert-15 Hi, I've done my AD review of draft-ietf-cose-cbor-encoded-cert-15 I have a few comments and questions, but I think the most important item is whether we asked the TLS WG what they think about making the C509 TLS Certificate Types RECOMMENDED Y to implement. It seems quite a lift to require all TLS servers would implement C509 at this point in time? The field is documented to mean: If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. Which I would argue matches better with RECOMMENDED N [GS] Agree See the rest of my AD review below, Paul The Abstract is large and the Introduction repeats many things. Can we deduplicate this and make the Abstract smaller and more consise? Please add a sentence: This document updates RFC 6698 in the Abstract. [GS] The Abstract is updated and now includes this text. validityNotAfter: ~time / null, Why can this be null? I thought X.509 certs always have an end date? (reading further, this is explained in 3.1.5) [GS] Right, the parameters are explained in turn in the following subsections. No change made. the octets 0xfe and 0xfd are used instead of 0x02 and 0x03 in the CBOR encoding to represent even and odd y-coordinate, respectively. I would prefer to rewrite this without using the "respectively" construct to help non-native english speakers. [GS] Done, see PR. This does not parse: using of the reserved CBOR tag I assume "of" just needs to be removed? [GS] Correct, fixed here and in other locations using the same phrase. An implementation MAY only support c509CertificateRequestType = 0. This is an odd way of saying, I think, that c509CertificateRequestType = 0 is mandatory to implement. [GS] This is a remnant from when there were fewer options / values. Rewritten as "An implementation MAY only support certain values of c509CertificateRequestType." There seems to be a spelling error in: TBSCertificatdsveRequest Should this be: TBSCertificateRequest ? [GS] Correct, fixed. For example, if the EST server includes a subjectAltName with a partially filled extensionValue, such as iPAddress with an empty byte string, this means that the client SHOULD fill in the corresponding GeneralName value This makes it appeat the EST server can put in "10.0.2" and the client can only pick that range, or "example.com<http://example.com/>" and the client can pick only subdomains from "example.com<http://example.com/>", but it is unlikely that you meant this? Perhaps rephrasing this to avoid this interpretation? [GS] Thanks, we made the example more explicit in the PR. "Brotli [RFC7932]" is not clarified until after "Brotli" has been mentioned a few times already. Please move the "[RFC7932]" clarification to the first instance of the use of "Brotli". [GS] Done. This sentence is unreadable, please rewrite: Any issue to decode or parse a C509 certificate should be handled by the certificate using system as would the issue of parsing the corresponding X.509 certificate. Perhaps: Any problems with decoding or parsing a C509 certificate should be handled exactly as how such errors would be handled for the corresponding X.509 certificate. [GS] Done. Section 9.5, should the text "Name and Identifiers are informal descriptions" maybe be included as a note above the table? [GS] Done. Why is Postal Code defined, but not Postal Address? Is that because Street Address is used? [GS] This was discussed in https://github.com/cose-wg/CBOR-certificates/issues/255 and it was decided to not specify it in CBOR since we didn’t see much room for simplification. Section 9.10. C509 Extended Key Usages Registry A good list of EKUs is: https://docs.digicert.com/zf/trust-lifecycle-manager/define-policies-to-ensure-compliance/certificate-attributes-and-extensions/extended-key-usage.html I happen to know (as an IPsec/IKE expert) that some implementations (like Microsoft) requires EKUs for IPsec which are not defined here. I guess these can be added later. [GS] Yes, they can easily be added later. Section 9.17. TLS Certificate Types Registry This sets the new type to RECOMMENDED. Since this is (currently) very much an IoT related document, I am not sure if it qualifies as something to be set to RECOMMENDED Y, meaning all servers/clients MUST/SHOULD implement this. Has there been a conversation with the TLS WG or the Designated Experts for this Registry? [GS] As proposed above, we agree to change this to RECOMMENDED N.
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
