CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates
Summary: Has enough positions to pass.
Benjamin Kaduk Yes
(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.
Alvaro Retana No Objection
Erik Kline No Objection
Comment (2020-10-06 for -07)
[[ 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"
Martin Duke No Objection
Comment (2020-10-07 for -07)
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 No Objection
Murray Kucherawy No Objection
Comment (2020-10-21 for -07)
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?
Robert Wilton No Objection
Comment (2020-10-19 for -07)
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
Roman Danyliw (was Discuss) No Objection
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)
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
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Zaheduzzaman Sarker No Record
(Barry Leiba; former steering group member) Yes
On switching to Proposed Standard from Informational, only one comment came in during IETF Last Call, and it was favourable.
(Alissa Cooper; former steering group member) No Objection
No Objection (2020-10-21 for -07)
Thanks for taking this on. Please respond to the Gen-ART review. May Jim rest in peace.
(Deborah Brungard; former steering group member) No Objection
No Objection ( for -07)
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
No Objection (2021-01-19)
Thanks for addressing the status of this document.