Subject: [COSE] draft-ietf-cose-x509-08 status

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jan 2021 09:56:55 -0500

Chairs,

There are some non-blocking comments from Ben Kaduk on this version.
Will there be document changes to address them, or do you want to go
forward with version -08?

Barry

---

From: Göran Selander <[email-masked]>
Date: Fri, 29 Jan 2021 15:27:27 +0000

Chairs and AD,

As was raised in the latest in the latest COSE virtual interim, there is at least one Github issue related to x5u that is not resolved according to some people in the WG:

https://github.com/cose-wg/X509/issues/31

I also agree with the issue that it is not clear what the trust relationship is and why integrity protection is needed when fetching the certificate in this case, which is not the case for the other COSE header parameters x5t, x5bag, x5chain defined in this draft. For these header parameters it is assumed that the certificate is verified, and that suffices to determines if it is trusted. If trust relations are relevant here, it seems also missing in this description the trust relationship between the party hosting the referred-to resource and party requesting the certificate.

I'm sorry that this comment comes very late. Further comments below should also have been raised much earlier, but at least I did not pay attention to before Laurence highlighted this issue.

Other comments on the x5u text:

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

Why can't a CoAP be protected by OSCORE?

"The referenced resource can be any of the following media types:

      *  application/pkix-cert [RFC2585]

      *  application/pkcs7-mime; smime-type="certs-only" [RFC8551]"

To enable more efficient coding and avoid implementation of pkcs7, could we also allow media type application/cbor containing a COSE_X509, as defined in the same section?

Göran

On 2021-01-29, 15:57, "COSE on behalf of Barry Leiba" <[email-masked] on behalf of [email-masked]> wrote:

    Chairs,

    Barry

    _______________________________________________
    COSE mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/cose

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 30 Jan 2021 14:54:40 +0200

On Fri, Jan 29, 2021 at 03:27:27PM +0000, Göran Selander wrote:
> Chairs and AD,
> 
> As was raised in the latest in the latest COSE virtual interim, there
> is at least one Github issue related to x5u that is not resolved
> according to some people in the WG:
> 
> I also agree with the issue that it is not clear what the trust
> relationship is and why integrity protection is needed when fetching
> the certificate in this case, which is not the case for the other COSE
> header parameters x5t, x5bag, x5chain defined in this draft. For these
> header parameters it is assumed that the certificate is verified, and
> that suffices to determines if it is trusted. If trust relations are
> relevant here, it seems also missing in this description the trust
> relationship between the party hosting the referred-to resource and
> party requesting the certificate.

To me there seems to be multiple problems:

- As certificate used can affect interpretation, not just validity
  (especially so for signatures), the sender needs to bind the
  certificate used. This impiles x5t, x5bag and x5chain need to go
  into protected bucket.
- HTTPS is transport encryption, so HTTPS URL do not bind fetched
  resource. So x5u needs to be paired with x5t, but could itself
  be in unprotected bucket.
- The text seems to suggest that specially configured HTTPS server
  could assert COSE trust anchors. I do not think it is appropriate
  to use transport encryption for such purpose.
- I think in X.509, it is possible for issuing certificate to affect
  interpretation of its subordinates. But I hope that very few pieces
  of software implement this insanity. In presence of such influence,
  x5t would not be sufficient.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Sat, 30 Jan 2021 09:54:11 -0500

>  x5t would not be sufficient.

Since the certificate is signed, it can be bound by including an identifier from the certificate in the protected part message.  The subject key identifier is one way to do this.  That is, the whole certificate does not need to be in the protected bucket.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Jan 2021 17:10:16 -0500

> certificate used. This impiles x5t, x5bag and x5chain need to go into
    > protected bucket.

I don't understand.
The certificates are signed.  They carry their own validity.

If an attacker can substitute a different set of certificates that lead to a
valid signature then we have a bigger problem.

Putting them into the protected bucket means that they can not be removed if
a transmitter or entity storing them knows that the validator already has them.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 31 Jan 2021 23:23:20 +0100

> The certificates are signed.  They carry their own validity.

My hunch is that in some of the applications there is an intention that the source re-certifies the certificates, substituting for the signature on the certificate.
(But why send a certificate then instead of just the TBS part?)

Grüße, Carsten

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 31 Jan 2021 22:54:57 +0000

I do not get the “re-certify the certificate” part. 

Regards,
Uri

> On Jan 31, 2021, at 17:24, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Feb 2021 00:23:21 +0100

> I do not get the “re-certify the certificate” part. 

In the Web PKI, the assumption is that every participant knows all root certificates and updates that set eagerly.
In the IoT world, that doesn’t work.

So people are looking at alternative ways of validating a certificate.
If there is a big brother/little brother relationship, the little brother may look to the big brother to validate the certificate for it.
To relay this validation (let’s call it a voucher), big brother could create its own certificate out of (or for!) the certificate in question.
But it may be more lightweight to protect the voucher as data in an authenticated connection (say, TLS), or as part of an authenticated object (say, COSE).

Grüße, Carsten

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 1 Feb 2021 04:24:56 +0000

>    In the IoT world, that doesn’t work.

OK, so there's no shared Root CA. Fine.

>    So people are looking at alternative ways of validating a certificate.

It seems obvious that if you do not share the PKI chain, you cannot validate a certificate - and it is unclear why would you want to?

>    If there is a big brother/little brother relationship, the little brother may look to the big brother to validate the certificate for it.

That's fine.

>    To relay this validation (let’s call it a voucher), big brother could create its own certificate out of (or for!) the certificate in question.

Creating a "voucher" *for* another cert? So, you send *both* the original cert that is mostly useless (because the recipient cannot validate it), *plus* your validation record? Why not create a new cert, including what's relevant from the original cert being validated?

>    But it may be more lightweight to protect the voucher as data in an authenticated connection (say, TLS), or as part of an authenticated object (say, COSE).

How is this different from "big brother" generating a new (light-weight, if needed) certificate, based on its own judgment and what's in the "old" certificate?

Thanks

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Feb 2021 08:07:35 +0100

> Creating a "voucher" *for* another cert? So, you send *both* the original cert that is mostly useless (because the recipient cannot validate it), *plus* your validation record?

The recipient may need to forward that certificate to third parties, which do the traditional validation.

> Why not create a new cert, including what's relevant from the original cert being validated?

Well, that all depends on what a “certificate” is for you.
The industry uses the term as an abbreviation for “RFC5280 certificate” (calling them X.509 certificates all the while).
And many in the industry believe that “you need certificates to be secure”, when in reality they mean specific aspects of those.

The voucher can be situated (i.e. valid in a specific context — obvious when that context is a TLS connection), which an “X.509 certificate” can’t.

> How is this different from "big brother" generating a new (light-weight, if needed) certificate, based on its own judgment and what's in the "old" certificate?

See above.  But yes, many of the vouchers will be certificates in a wider sense, and having the mechanics to create them is part of what makes these vouchers interesting.

But there is an interesting twist here:

X.509 certificates say “A said that X’s key is K”.
If you like A, that makes the certificate valid.

A voucher by B says “B believes that A saying that X’s key is K is valid”.
So the identity of A is visible.
(Note that this is different from “B believes that anything that A is saying is valid”, which is the essence of Web PKI.)

A “new certificate” would be limited to “B said that X’s key is K”, which is not something B might want to say.

Grüße, Carsten