These look fine to me. Deb
On Thu, May 7, 2026 at 11:17 AM Göran Selander <goran.selander= [email protected]> wrote: > Hi Chris, > > We believe we have addressed all received comments on the draft. > > Do you want us to submit a new version? Any other outstanding actions on > our side? > > Thanks, > Göran > > *From: *Göran Selander <[email protected]> > *Date: *Thursday, 7 May 2026 at 11:36 > *To: *Deb Cooley <[email protected]> > *Cc: *The IESG <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] < > [email protected]> > *Subject: *Re: Deb Cooley's No Objection on > draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT) > > Hi Deb, > > Again, thanks for your review. Here are the responses to your remaining > comments, see inline below with reference to PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>. > > For overview of the state of the draft, see Editor’s copy > <https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html> > : > > Thanks, > Göran > > > *From: *Deb Cooley <[email protected]> > *Date: *Tuesday, 28 April 2026 at 17:14 > *To: *Göran Selander <[email protected]> > *Cc: *The IESG <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] < > [email protected]> > *Subject: *Re: Deb Cooley's No Objection on > draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT) > > Thanks for that quick response. The existence of implementations makes me > feel better about the situation, including those in the shepherd's write up > would have been awesome. > > I understand how easy it is to miss reviews. I think it was a big win > having a PKI guy assigned to this draft as secdir reviewer! > > Deb > > On Tue, Apr 28, 2026 at 10:44 AM Göran Selander < > [email protected]> wrote: > > Hi Deb, > > Just a couple of quick reactions, mainly on the general comment, please > see inline. More responses to the detailed comments will follow. > > Thanks, > Göran > > > *From: *Deb Cooley via Datatracker <[email protected]> > *Date: *Tuesday, 28 April 2026 at 15:08 > *To: *The IESG <[email protected]> > *Cc: *[email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]> > *Subject: *Deb Cooley's No Objection on > draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT) > > Deb Cooley has entered the following ballot position for > draft-ietf-cose-cbor-encoded-cert-18: No Objection > > > <snip> > > > "Section 1, para 5: This could easily be deleted as it is repetitive with > the > para above. If it is left in the specification, please look at the sentence > construction (it is indeed only a single sentence) that makes little sense > after the 'e.g,' and then 'or' and then 'and’. > > [GS: The paragraphs are now merged, see PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 1, #1: Please add a note to say that validating the signature on > the > certificate first requires that it is reverted back to the original X.509 > certificate. > > [GS: Done, see PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 1, second to last para: I would incorporate this information in #2 > above it. (again, a paragraph with a single sentence) > > [GS: Done, see PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 3.1.4, para 2: Why is the construction of serialNumber in this > section > vice Section 3.1.2? > > [GS: 3.1.2 is about the Serial Number field of the certificate. 3.1.4 is > about the RDN attribute serialNumber. There is room for disambiguation > here, changed the former to “certificateSerialNumber”, see PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 3.1.4, para 4: Is this 'extension' part of the issuer name, or > part of > what is described in Section 3.1.10? > > [GS: Typo, should read ‘attribute’, fixed in Editor’s copy > <https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html> > .] > > Section 3.1.5: Do you need a reference for 'POSIX time’? > > [GS: Done, see PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 3.1.6: Should 'CBOR simple value' be 'CBOR simple value null'? (it > is > phrased that way in Section 3.1.4 and 3.1.5. > > [GS: Correct, fixed in Editor’s copy > <https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html> > .] > > Section 3.1.8 & 3.1.9: Where do these fields originate? > > [GS: Optional fields in TBSCertificate of X.509, see RFC 5280.] > > Section 3.3, para 3: Does this mean that the actual OID is the same > regardless > of the name? Or that there are multiple registered OIDs for the same > extension? Please clarify if it is the former. If it is the latter, then > specifying which OID is expected will make implementation less complex. > > [GS: The former, added in PR#392 > <https://github.com/cose-wg/CBOR-certificates/pull/392>.] > > Section 3.3.1, key usage: Isn't key usage normally critical? Wouldn't an > example of that be more useful? > > [GS: Perhaps, but there already an example of a critical extension in this > section. Since that would just be a matter of changing the sign of the > value, we didn't think all instances were necessary to represent as > examples.] > > Section 8.1, para 1: I wonder how a DE will determine if a request can be > solved in a 'better in a different way'. 'Better' being very subjective. > > [GS: Fixed in PR#389 > <https://github.com/cose-wg/CBOR-certificates/pull/389>] > > Section 8.14: Why are SHA-1 algorithms being registered (even if they are > marked as 'deprecated')?" > > [GS: The intent with this document has been to create an encoding for > certificates that are “out there”, not to give recommendations about what > algorithms etc to use. We have updated the security considerations, see > Editor’s > copy > <https://cose-wg.github.io/CBOR-certificates/draft-ietf-cose-cbor-encoded-cert.html> > : > "The specification makes no recommendations on the use of algorithms, > paddings, or other security constructs applied in the encoding of a > certificate. In particular, an IANA registration does not imply a > recommendation. For example, some deprecated algorithms are assigned code > points only for backward compatibility to enable CBOR encoding of existing > certificates.”] > > Thanks, > Göran > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
