Re: [COSE] AD evaluation of draft-ietf-cose-x509-06

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Barry Leiba <[e-mail]> 
Sent: Friday, August 28, 2020 12:33 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD evaluation of draft-ietf-cose-x509-06

Hi, all.  I'm taking this document over at Ben Kaduk's request, so as to get it moving more quickly, given Ben's workload.  There are two items in my review below that I think I want to resolve before starting last call: the MTI comment in Section 2, and the question about Table 2 in Section 3.

— Section 1 —

   In the process of writing [RFC8152] discussions were held on the
   question of X.509 certificates [RFC5280] and if there was a needed to
   provide for them.  At the time no use cases were presented that
   appeared to have a sufficient need for these attributes.

Typo: “needed” -> “need”.  But, really, I would just merge the two sentences:

NEW
   In the process of writing [RFC8152] the working group discussed X.509
   certificates [RFC5280] and decided that no use cases were presented that
   showed a need to support certificates.
END
[JLS] done

— Section 2 —

   It is not necessarily expected that constrained devices themselves
   will evaluate and process of X.509 certificates

Then, this is intended to be used in one direction: constrained devices might have certs built in, but a constrained device will not
*receive* a cert from a server, for example… right?  The examples in Section 1 are consistent with that, but it might be good to say it explicitly.

[JLS]  I think change addresses that
	
It is not necessarily expected that constrained devices themselves will evaluate and process of X.509 certificates:  it is perfectly reasonable for a constrained device to be provisioned with a certificate which it can then provide to a relying party - along with a signature or encrypted message - on the assumption that the relying party is not a constrained device, and is capable of performing the 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.

[/JLS]

      For interoperability, applications which use this header parameter
      MUST support the hash algorithm 'SHA-256', but can use other hash
      algorithms.

I appreciate the need for an MTI alg here, but what does it really mean for me to say that my temperature sensor “supports SHA-256”, but that everything it sends uses SHA-512?  How does that help interoperability?

[JLS]  If you have not agreed with others that this is what you are doing, then it does not help interoperability.  However, I am also loathe to say that you MUST use this algorithm and only this algorithm.  My expectation is that people are more likely to use SHA-256/64 rather than SHA-256 in this case as the shorter thumbprint means less bytes on the wire.  I don't know what else could be said here.

      This will normally be the situation when self-signed certificates
      are used.

I wonder whether some readers will misread this as saying that self-signed certs will normally be used here.  Maybe, “Self-signed certificates are more likely to appear in this parameter than in the others.” ?

[JLS] No, this is what I really meant "In particular, self-signed certificates MUST NOT be trusted without an out-of-band confirmation."

   *  COSE_Signature and COSE_Sign0 objects, in these objects they
      identify the certificate to be used for validation the signature.

   *  COSE_recipient objects, in this location they identify the
      certificate for the recipient of the message.

Nit: I would use colon or semicolon instead of comma in both of these.
And the first should say "validating", rather than "validation".

[JLS] Done.

— Section 3 —

   There is no definition for the certificate bag as the same
   attribute would be used for both the sender and recipient
   certificates.

Nit: there needs to be a comma after “bag”.
[JLS] done

One thing I’m not sure about here is why there’s no need to have “x5bag” in Table 2 in order to register the ECDH algorithms (in Section 4.2).
[JLS] The reason is that the same x5bag would be used for both purposes.  Since this is just a random collection of certificates it can hold both certificates containing key agreement public keys as well as signature public keys.

— Section 4.1 —

   IANA is requested to register the new COSE Header parameter in

Nit: “parameters”

— Section 5 —

   A new self-signed certificate
   appearing on the client cannot be a trigger to modify the set of
   trust anchors, instead a well defined trust-establishment process is
   required.

Nit: I had a bit of trouble parsing this, and I think it needs different punctuation, or, better, just a change from “instead” to “because”.

[JLS] I don't have any ideas of what is better.  This may now tie better back to the text above in section 2.

   Before using the keys in a certificate, they MUST be checked as
   described in the COSE algorithms document
   [I-D.ietf-cose-rfc8152bis-algs].

I think the MUST here makes rfc8152bis-algs normative.  I see that the document shepherd also thought that, but I don’t really follow the argument about why not.

[JLS] I think that what I am trying to say just does not match what people are reading here.  I have changed this to read:

        Before using the key in a certificate, the key MUST be checked against the algorithm to be used and any algorithm specific checks need to be made.


Jim



--
Barry