Ballot for draft-ietf-cose-x509
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
[[ 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"
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?
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.
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
On switching to Proposed Standard from Informational, only one comment came in during IETF Last Call, and it was favourable.
(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.
Thanks for taking this on. Please respond to the Gen-ART review. May Jim rest in peace.
Thanks for addressing the status of this document.
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.
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