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

From: Jim Schaad <[email-masked]>
Date: Mon, 14 Sep 2020 18:16:23 -0700

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: Friday, August 28, 2020 12:33 PM
To: [email-masked]
Cc: [email-masked]
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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Sep 2020 21:23:30 -0400

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-masked]> wrote:

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Sep 2020 13:27:21 -0400

Hi, Jim.
Just leaving the items that aren't fully settled:

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

I'm not sure how to say it either, but I don't think what's there
really addresses interoperability.  I think you understand what I'm
getting at, yes?

Possibly it just doesn't make sense to have an MTI algorithm, and
instead have text advising about interop issues with regard to the
hash algo.

Maybe just put a "cref" note in about this issue, and let people who
review it cogitate about it -- maybe we'll get some ideas.

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

That text sounds useful, yes; thanks,

Barry

---

From: Jim Schaad <[email-masked]>
Date: Thu, 17 Sep 2020 11:30:47 -0700

I just posted the new version.

As you suggested below, I have punted the MTI issue to see what we get as a response.  By default I think we just close our eyes and live with the current text.

Jim

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: Thursday, September 17, 2020 10:27 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: AD evaluation of draft-ietf-cose-x509-06

Hi, Jim.

> means less bytes on the wire.  I don't know what else could be said 

I'm not sure how to say it either, but I don't think what's there really addresses interoperability.  I think you understand what I'm getting at, yes?

Possibly it just doesn't make sense to have an MTI algorithm, and instead have text advising about interop issues with regard to the hash algo.

Maybe just put a "cref" note in about this issue, and let people who review it cogitate about it -- maybe we'll get some ideas.

Barry