CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates
draft-ietf-cose-x509-08

Summary: Has enough positions to pass.

Benjamin Kaduk Yes

Comment (2021-01-20)
(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

Comment (2020-12-31)
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

Yes (2020-12-29)
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.