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

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2020 15:33:13 -0400

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

— 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.

      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?

      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.” ?

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

— 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”.

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).

— 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”.

   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.

-- 
Barry