Skip to main content

CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
RFC 9360


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
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"
Martin Duke
No Objection
Comment (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.
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?
Robert Wilton
No Objection
Comment (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.

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: 

The major issue found by Carsten (missing files in the github repo) should be resolved before publication.

Barry Leiba Former IESG member
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 (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
Some of them have been fully or essentially addressed and could probably
be closed, but a couple seem to still be noteworthy: and 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 ; 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 Vigoureux Former IESG member
No Objection
No Objection (for -07) Not sent