Thanks for the response, Jim. I’m taking a few days of vacation and will get to a response on Thursday. Please remind me mid-day Thursday, your time, if you don’t hear from me by then.
b On Mon, Sep 14, 2020 at 9:16 PM Jim Schaad <[email protected]> wrote: > > > > > -----Original Message----- > > From: Barry Leiba <[email protected]> > > Sent: Friday, August 28, 2020 12:33 PM > > To: [email protected] > > Cc: [email protected] > > 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 > > > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
