Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

From: John Mattsson <[email-masked]>
Date: Wed, 10 Mar 2021 18:13:44 +0000

Hi,

I got some comments from Göran and updated the PR based on Göran's comments. The suggested pull request will be presented on the COSE WG meeting on Friday.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Wednesday, 24 February 2021 at 10:35
To: cose <[email-masked]>
Subject: Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

Hi,

At the last interim Ben asked me to make a first attempt at summarizing the discussion and conclusions in the issue tracker, the list, and during the interim. I just made a pull request (PR) doing that.

https://github.com/cose-wg/X509/pull/35

The PR aims to aims to address issues #29 #30 #31 #33 based on the dicussion on the list and during the last interim. The solution is to use x5t together with the other parameters as suggested by Russ:

- Added to x5bag, x5chain, and x5u that integrity protection in COSE is requiured unless it is known that the CA did proof-of-possession.
- Added that integrity protection can be achieved by combining x5t with x5bag, x5chain, or x5u.  
- Added explanation that sending x5bag or x5cahing in unprotected allows an intermediary to remove or add certificates.
- Added clarification that x5t refer to an end-entity certificate.
- Added media type application/cbor for a COSE_X509 chain.
- Added that when the end-entity certificate is intergrity protected by COSE, URI protection is not needed.
- Security consideration on why integrity protection of the end-entity certificate is required is there was no proof-of-possession.
- Security consideration on identity protection.

I think this addresses all the related use case and security issues.
 - If the requirement are followed, it is secure.
 - No changes required to existing secure deployments.
 - It is still possible to send x5bag and x5chain in uprotected.
 - No extra overhead is required when used in EDHOC.
 - When used in EDHOC, plain unprotected CoAP can be used.

I tried to make the changnes so that no existing secure deployment need to change their implementation. Could otherwise discussed if integrity protection should be a MUST, but that would change existing implementaions (which is they do proof-of-possession are already secure).

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Mar 2021 21:02:46 +0100

> - Added media type application/cbor for a COSE_X509 chain.

Why is that the right media type?
(We have specific ones for everything else, no?)

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Thu, 11 Mar 2021 07:33:40 +0000

Yes it probably better to register a new media type. E.g.:

application/cose-x509-chain

Let's discuss tomorrow.

Cheers,
John

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Date: Wednesday, 10 March 2021 at 21:03
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Fri, 12 Mar 2021 07:35:32 +0000

New comment from Laurance on GitHub pointing out that proof-of-possesion
is not enough. I think this point to that COSE integrity protection of the end-entity certificate needs to be MUST.

Cheers,
John

  This doesn't address the case where a CA correctly and intentionally
  issued two certs for the same key with different characteristics (e.g.,
  key use, expiration, other extensions) and the attacker swapped them.

  Maybe this: "When any field in a certificate beyond the key (e.g., key
  use, expiration, other extensions) is used in security decisions by the
  receiver, the COSE header containing or referencing the certificate
  should be in the protected bucket"."

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Thursday, 11 March 2021 at 08:33
To: Carsten Bormann <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

Let's discuss tomorrow.

Cheers,
John

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Date: Wednesday, 10 March 2021 at 21:03
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] Pull-request addressing issues #29 #30 #31 #33 in draft-ietf-cose-x509-08

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 12 Mar 2021 10:02:10 -0800

I wouldn’t say MUST, just highly recommended. If there is consensus for MUST I won’t object considering that the cost of protection is low for all the uses I can imagine.

LL

> On Mar 11, 2021, at 11:35 PM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Mar 2021 16:35:34 -0500

John Mattsson <john.mattsson=[email-masked]> wrote:
    > New comment from Laurance on GitHub pointing out that
    > proof-of-possesion is not enough. I think this point to that COSE
    > integrity protection of the end-entity certificate needs to be MUST.

I think that the example is incorrect.

If we have to protect End-Entity certificates, then we can just put in public
keys and save hundreds of bytes.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-