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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> wrote:

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