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

From: John Mattsson <[email-masked]>
Date: Wed, 24 Feb 2021 09:35:18 +0000

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