CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
draft-ietf-cose-x509-09
Yes
Paul Wouters
No Objection
Warren Kumari
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
Note: This ballot was opened for revision 07 and is now closed.
Paul Wouters
Yes
Erik Kline
No Objection
Comment
(2020-10-06 for -07)
Not sent
[[ nits ]] [ section 1 ] * "ad decided" -> "and decided" * "wher prestented" -> "were presented" [ section 2 ] * "evaluate and process of X.509 certificates" -> "evaluate and process X.509 certificates" * "configured use" -> "configured to use" * "registry The" -> "registry. The"
Murray Kucherawy
No Objection
Comment
(2020-10-21 for -07)
Sent
I would like to add my thanks to Jim Schaad for this document, and for all of his other contributions to the IETF. -- Section 1 includes a GitHub URL where the reader can find examples. Is this acceptable as a permanent reference? Section 2: * "... will evaluate and process of X.509 certificates ..." -- remove "of"? * "... and be configured use ..." -- add "to"? * The first paragraph of the "x5t" bullet seems to have a couple of sentences smashed together at the end. * Has the note about the AD Review comments in this section been resolved?
Roman Danyliw
(was Discuss)
No Objection
Comment
(2020-12-31 for -08)
Sent for earlier
I would like to recognize Jim Schaad’s tremendous contribution to the IETF as author, implementer, mentor and leader. Thank you to the Charlie Kaufman for the SECDIR review and the updates based on it are appreciated. Thanks for addressing my DISCUSS and COMMENT feedback.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment
(2020-10-20 for -07)
Sent
Strange feeling to review this Jim Schaad's document... Thank you Carsten for the IoT directorate review at: https://datatracker.ietf.org/doc/review-ietf-cose-x509-07-iotdir-telechat-bormann-2020-10-19/ The major issue found by Carsten (missing files in the github repo) should be resolved before publication. -éric
Barry Leiba Former IESG member
Yes
Yes
(2020-12-29 for -08)
Not sent
On switching to Proposed Standard from Informational, only one comment came in during IETF Last Call, and it was favourable.
Benjamin Kaduk Former IESG member
Yes
Yes
(2021-01-20 for -08)
Sent
(I posted a PR on github to fix a few editorial nits.) There are some issues still in the open state at https://github.com/cose-wg/X509/issues Some of them have been fully or essentially addressed and could probably be closed, but a couple seem to still be noteworthy: https://github.com/cose-wg/X509/issues/30 and https://github.com/cose-wg/X509/issues/31 cover related issues, relating to the "trust relationship" between signer and host of URI (that we say needs to be authenticated), and whether there are similar considerations relating to other header parameters. The answer seems to be that "yes, there are sometimes such considerations", and it would be okay to document them if we have a concise explanation. That COSE mandates x5u appear in the protected headers is a divergence from JWS, but it would feel out of place to attempt to amend JWS in this document; the other header parameters can appear either in the protected or unprotected buckets, which allows for pretty much all use cases. JWS does have some text relating to header parameters that must be integrity protected "if the information that they convey is to be utilized in a trust decision", which is vague enough that it may not actually be helpful to replicate that terminology. (We did not seem to have immediate agreement on what it meant when this topic was discussed in the WG.) There is perhaps just one remaining point in https://github.com/cose-wg/X509/issues/29 ; whether we should be more explicit that 'x5t' refers to the end-entity cert. I'd be okay with doing so, but it doesn't feel particularly critical.
Alissa Cooper Former IESG member
No Objection
No Objection
(2020-10-21 for -07)
Sent
Thanks for taking this on. Please respond to the Gen-ART review. May Jim rest in peace.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -07)
Not sent
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Not sent
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2021-01-19 for -08)
Sent
Thanks for addressing the status of this document.
Martin Duke Former IESG member
No Objection
No Objection
(2020-10-07 for -07)
Sent
I see that it's in the charter as such, but I have no idea why this is otherwise an Informational RFC, as it extends a Standard RFC and has some normative language in it for interoperability. I am not a fan of the passive voice in Section 2: "Certificates obtained from any of these methods MUST still be validated." Who has to validate it? It sounds like we are not requiring constrained devices to do this validation, so the document really ought to pin the responsibility on the system.
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -07)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2020-10-19 for -07)
Sent
I would like to thank Jim Schaad for this document and all his other work at IETF. My only minor comment is that I was surprised by the name "x5bag", which in computing terms I generally understand to be defined as a data structure that is like a set but it can contain duplicate values (also known as a multiset). It wasn't clear to me that was the intended purpose here, but I seem to recall that 'bag' might take a slightly different meaning in security circles? Either way, it might be helpful to specify both for the x5bag and x5chain whether or not duplicate certificates are allowed to be present. Regards, Rob