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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
