Thanks for the document update. I have issued the IETF Last Call. Paul
On Sun, Jan 25, 2026 at 3:15 PM Göran Selander <[email protected]> wrote: > 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" and the client can pick only subdomains > from > "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]
