CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Roman Danyliw Discuss

Discuss (2020-10-20)
Section 2.  Where is the uri (CCDL) syntax/format/data type (used by x5u and x5u-sender) defined?  Is this covered by CBOR tag=32?
Comment (2020-10-20)
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.  This review proposes and poses a few places where clarifying text would be helpful.  Please respond to it.

** Section 1.  Per the github pointer with examples:
-- please add this url as a reference, not an inline url
-- which exact set of references are relevant to this draft?  It isn’t clear how this collection of examples applies.

** Section 2.  Recommend precision on the string vs. integer algorithm identifier.

The first element is an algorithm identifier which is
      an integer or a string containing the hash algorithm identifier.
      The algorithm is registered in the "COSE Algorithms" registry

The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier corresponding to either the Value (integer) or Name (string) column of the algorithm registered in the "COSE Algorithms" registry.

** Table 1.  To line up with the column names of COSE Headers Parameters registry with this table, s/Type/Value Type/

** Section 5.  Recommend pointing to Section 7 of RFC3986 to cover security considerations of URI.

** Section 5.  Per “On the other hand, an oracle can potentially be built based on detecting the network resources which is only done if the signature validation passes.”, I didn’t follow what this means.

** Editorial Nits

-- Section 1.  Editorial.  Multiple typos.
In the process of writing [RFC8152] the working group discussed X.509
   certificates [RFC5280] ad decided that no use cases wher prestented
   that showed a need to support certificates

In the process of writing [RFC8152], the working group discussed X.509
certificates [RFC5280] and found that that no use cases were presented that showed a need to support certificates

-- Section 1.  Editorial.
for example, in the 6TiSCH
   environment [I-D.richardson-enrollment-roadmap], describes a device
   enrollment solution that relies on the presence in the device of a
   factory-installed certificate.  

for example, in the 6TiSCH environment, [I-D.richardson-enrollment-roadmap] describes a device enrollment solution that relies on the presence of a factory-installed certificate on the device.

-- Section 2.  Editorial.  s/be configured use a/be configured to us a/

-- Section 2.  There appears to be a missing transition from describing x5u and Table 1 which applies to all the preceding text.

Magnus Westerlund Discuss

Discuss (2020-10-22)
I think the topic should be fairly easily to resolve one way or another. However, even after having read the reply to Marin's comment I don't think this document is published with the right status. 

- The document defines new CBOR attributes, that is standard track work as it comes out as consensus document from a IETF WG. 
- It does not define or document crypto algorithm just refer to existing ones.
- The charter item might have been reasonable as informational if existing attributes could have been used. With the choice to define new attributes I think this has entered standards track.
- The status of the document I think will also affect the value that IANA might assign to these COSE Header Parameters. 

If there are additional considerations I am happy to learn about them. 

Else, I would propose a change of status to proposed standard and redo the IETF last call.

Benjamin Kaduk Yes

Comment (2020-10-21)
It's still hard to believe we've lost Jim.  Thank you for taking up the
mantle to finish this work.

As Roman noted already, the secdir review had some good points (and
perhaps also some that do not require changes to the text), which
deserves a response.

[The missing examples in the linked github repo have already been noted a
few times so I have nothing further to say about it.]

It's interesting that JOSE does not have an 'x5bag' parameter, though I
don't think that there is a need for this document to do anything in that


   The CBOR Signing And Encrypted Message (COSE) structure uses
   references to keys in general.  For some algorithms, additional
   properties are defined which carry parts of keys as needed.  The COSE

(nit) I'm not sure that "parts of keys" covers all cases; the boundary
between a "key" and various attributes or parameters associated with it
can be fuzzy at times.  Perhaps something like "parameters relating to
keys" would be more encompassing?

Section 2

   required certificate evaluation and processing.  It is also
   reasonable that a constrained device would have the hash of a
   certificate associated with a public key and be configured use a
   public key for that thumbprint, but without performing the
   certificate evaluation or even having the entire certificate.

This implies that the constrained device is not doing the required
revocation checking, which probably merits some form of caveat (a
management system that monitors revocation and updates the device if
needed?).  This is particularly poingnant given the following paragraphs
admonition that "[c]ertificates [...] MUST still be validated".

   a chain length of one as well as longer chains.  If the application
   cannot establish trust in the certificate, that certificate cannot be

The secdir review already noted some potential issues with the blanket
"cannot be used"; another possible rewording would be "the public key
contained in the certificate cannot be used for cryptographic

   x5chain:  This header parameter contains an ordered array of X.509
      certificates.  The certificates are to be ordered starting with
      the certificate containing the end-entity key followed by the
      certificate which signed it and so on.  There is no requirement
      for the entire chain to be present in the element if there is
      reason to believe that the relying party already has, or can
      locate the missing certificates.  This means that the relying

Are the missing certificates required to be contiguous and contain the
root?  That is, is it okay to leave a gap in the middle of the chain?

   [still x5chain]
      This header parameter allows for a single X.509 certificate or a
      chain of X.509 certificates to be carried in the message.

It's slightly surprising that the "chain" structure allows for a single
certificate not in an array container; it might be intuitively more
simple to just always use the array encoding for a chain, even a
one-element chain.  But I'm sure there's some reason to allow it, too,
just not one that I thought of right away.

   x5t:  This header parameter provides the ability to identify an X.509
      certificate by a hash value.  The attribute is an array of two

I suggest using the word "thumbprint" somewhere to motivate the 't' in

Also, we may want to make a pass to check for consistent usage of
"attribute", "parameter", etc. -- I think this is the first time we say
"the attribute is".

      For interoperability, applications which use this header parameter
      MUST support the hash algorithm 'SHA-256', but can use other hash

In light of the following notes, perhaps we should add another sentence
along the lines of "This requirement allows for different
implementations to be configured to use an interoperable algorithm, but
does not preclude the use (by prior agreement) of other algorithms."

   x5u:  This header parameter provides the ability to identify an X.509
      As this header parameter implies a trust relationship, the
      attribute MUST be in the protected attribute bucket.

In light of the secdir reviewer's comments, perhaps "a trust
relationship between the party generating the x5u parameter and the
party hosting the referred-to resource" would help?

      The URI provided MUST provide integrity protection and server
      authentication.  For example, an HTTP or CoAP GET request to
      retrieve a certificate MUST use TLS [RFC8446] or DTLS
      [I-D.ietf-tls-dtls13].  If the certificate does not chain to an
      existing trust anchor, the certificate MUST NOT be trusted unless

I think we should probably clarify that it is the "received" or
"retrieved" certificate (as opposed to the certificate used to
authenticate the (D)TLS connection used to dereference the URI).

      the server is configured as trusted to provide new trust anchors.
      In particular, self-signed certificates MUST NOT be trusted
      without an out-of-band confirmation.

I agree with the secdir reviewer that some rewording/clarification is in
order here.

         | x5u     | TBD2  | uri           | URI pointing to an  |
         |         |       |               | X.509 certificate   |

I agree with Roman that a more explicit statement of where the uri type
is defined (or inline definition) is needed.

   The header parameters are used in the following locations:

I guess draft-ietf-cose-countersign is on the hook for specifying
anything needed about the X.509-related parameter usage?  It looks like
COSE_Countersignature reuses the COSE_Signature sturcture, but I would
not (naively) expect that to also inherit the ability to use these
parameters.  COSE_Countersignature0 does not have any place to stow
metadata, so I guess these parameters are not useful at all there.

In Table 2, I think all the "AES192KW" and "AES256KW" should be "A192KW"
and "A256KW", respectively.

Section 5

I think we need to explicitly pull in (by reference) the security
considerations from RFC 3986, arguably with specific call-out to the
"reliability and consistency" portions.

We might also mention that path validation is an important part of
establishing trust in a certificate and point to RFC 5280.  I don't feel
a huge need to also mention the possibility of constructing alternative
chains, though we could do that as well if desired.

We should probably also have some pro-forma mention of the strength of
the hash used for a certificate thumbprint being a factor in the
security of the system.

Section 6.2

I feel like RFC 8152 (or the bis) ought to be present as a normative
reference; you cannot implement these new parameters outside the context
of a broader COSE implementation.

Barry Leiba Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2020-10-21)
Thanks for taking this on. Please respond to the Gen-ART review.

May Jim rest in peace.

Martin Duke No Objection

Comment (2020-10-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.

Erik Kline No Objection

Comment (2020-10-06)
No email
send info
[[ 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)
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?

Warren Kumari No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-10-20)
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.


Robert Wilton No Objection

Comment (2020-10-19)
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.