Subject: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 10:58:18 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-x509-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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
regard.

Abstract

   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
   used.

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
operations".

   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
"x5t".

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
      algorithms.

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.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 21 Oct 2020 12:54:44 -0700

> On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> "x5t”.

Using “thumbprint” makes sense to me, though it was changed from thumbprint to fingerprint in March <https://github.com/cose-wg/X509/commit/32c2bf2b2411250f6d9232b43ae0813ac9d88a44>. 

Is it the common understanding that this “x5t” identifies the end-entity cert like subjectKeyIdentifier does for CMS <https://tools.ietf.org/html/rfc5652#section-5.3>? I can’t imagine what else it would identify, but it seems saying this explicitly would be helpful. CMS certainly is explicit and detailed on this.

> "the attribute is”.

I believe the correct term is “header parameter”. This was settled on for draft-ietf-cose-rfc8152bis-struct and Jim made a number of changes to cose-x509 to use that term back in March (same PR as referenced above). However, “attribute” is still used a lot and probably all those uses should be “header parameter”.

LL

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Oct 2020 13:27:53 -0700

> Using “thumbprint” makes sense to me, though it was changed from thumbprint to fingerprint in March <https://github.com/cose-wg/X509/commit/32c2bf2b2411250f6d9232b43ae0813ac9d88a44>. 

My point was more that we're effectively tied to the "x5t" symbol for JOSE
parity, and even if we want to call the thing it carries a "fingerprint",
we should still use the word "thumbprint" once to explain the mnemonic
value of the 't'.

> Is it the common understanding that this “x5t” identifies the end-entity cert like subjectKeyIdentifier does for CMS <https://tools.ietf.org/html/rfc5652#section-5.3>? I can’t imagine what else it…

That's what I assumed, but probably worth a mention (one could, of course,
identify a CA by fingerprint as well).

> I believe the correct term is “header parameter”. This was settled on for draft-ietf-cose-rfc8152bis-struct and Jim made a number of changes to cose-x509 to use that term back in March (same PR as…

That sounds right for everything except the -sender variants, which are
"header algorithm parameter"s.  (I had to look it up and check again while
reviewing the document.)

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 21 Oct 2020 13:50:09 -0700

> On Oct 21, 2020, at 1:27 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> value of the 't’.

Makes sense.

> identify a CA by fingerprint as well).

The identification of the CA(s) would be in the X.509 certs in the Subject Key Identifier or such. Don’t think x5t would ever identify a CA (unless the cert is both an end-entity and CA cert).

I worry a little about ambiguity if you receive a COSE with an x5chain, an x5bag and an x5t.  In particular x5t and x5chain both identify the end-entity cert. Which has precedence? Since the point of x5chain is to avoid the work of cert path construction, I’d say that if it is present, use that. If x5chain processing fails, the whole processing fails. If every (constrained node) implementation must fall back to cert path construction using x5bag, then there would be no savings in using x5chain.

LL