Subject: [COSE] Comments on draft-ietf-cose-x509-01

From: John Mattsson <[email-masked]>
Date: Fri, 22 Mar 2019 09:07:01 +0000

Very well-written and well needed document. My comments on x5u are likely things that should also be discussed in the security considerations. 

I think the x5u text should be divided into the two quite different use cases:

-  If the certificate is tied to an existing trust anchor, I see no security differences between sending x5chain in unprotected compared to sending a URL in unprotected and fetching the cert with an unprotected HTTP GET. In both cases an attacker can modify the information. In this case I think the requirements to send in protected and to use HTTPS can be removed.

- If x5u is used to provide a new trust anchor, there is as stated strong requirements on the connection to the certificate distributer (integrity protection, authentication, configured as trusted). I do however not see why the x5u URL needs to be sent in protected. unprotected seems to work equally fine.

I would like to a header parameter for CWT as well

   "cwt:  This header attribute contains an CWT"

"Revocation info?"

   OCSP stapling would be nice. Something like

   "ocsp:  This header attribute contains one or more OCSP tokens"

	COSE_OCSP = bstr / [ 2*ocsp_token: bstr ]

   alternatively the OCSP tokens could be sent in the COSE_X509 array

Nits:

   6tish -> 6TiSCH

   'sha256' -> SHA-256.

   OLD "The structure is the same as 'x5bag'."
   NEW "The structure is the same as 'x5chain'."

Cheers,
John

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Mar 2019 11:01:12 +0100

> -----Original Message-----
> From: COSE <[email-masked]> On Behalf Of John Mattsson
> Sent: Friday, March 22, 2019 10:07 AM
> To: [email-masked]
> Subject: [COSE] Comments on draft-ietf-cose-x509-01
> 
> Very well-written and well needed document. My comments on x5u are
> likely things that should also be discussed in the security
considerations.
> -  If the certificate is tied to an existing trust anchor, I see no
security
> differences between sending x5chain in unprotected compared to sending a
> URL in unprotected and fetching the cert with an unprotected HTTP GET. In
> both cases an attacker can modify the information. In this case I think
the
> requirements to send in protected and to use HTTPS can be removed.
> 
> - If x5u is used to provide a new trust anchor, there is as stated strong
> requirements on the connection to the certificate distributer (integrity
> protection, authentication, configured as trusted). I do however not see
why
> the x5u URL needs to be sent in protected. unprotected seems to work
> equally fine.

If I change the URL that is unprotected, then it would look for and use a
different certificate.  If this is a self-signed certificate then you may
trust the distributer, but the signer is now different.

I don't have the time at the moment, but I would suggest going through the
JOSE mailing list where we hashed out the same argument in terms of always
requiring https when using a  URL.

Jim

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