Subject: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 07 Oct 2020 10:26:48 -0700

Martin Duke has entered the following ballot position for
draft-ietf-cose-x509-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I see that it's in the charter as such, but I have no idea why this is
otherwise an Informational RFC, as it extends a Standard RFC and has some
normative language in it for interoperability.

I am not a fan of the passive voice in Section 2:
"Certificates obtained from any of these methods MUST still be validated."

Who has to validate it? It sounds like we are not requiring constrained devices
to do this validation, so the document really ought to pin the responsibility
on the system.

---

From: Ivaylo Petrov <[email-masked]>
Date: Sun, 11 Oct 2020 19:29:04 +0300

Hello Martin,

Thank you for your comments! I am not sure if you are aware, but I am going
to be handing some editorial changes to this document until publication. I
will also try to answer your questions inline.

> https://datatracker.ietf.org/doc/draft-ietf-cose-x509/

[IP]: From my point of view this has been a decision made during the last
rechartering. You can see it in the current charter [1] or this email [2].
One possible reason for that decision is that initially the draft contained
hash algorithms as well, which if I understand correctly are usually
published in informational drafts. To the best of my knowledge no one has
voiced concerns about this document being Informational. If anyone has more
context, please chime in.

> to do this validation, so the document really ought to pin the

[IP]: My understanding is that the recipient should have enough information
to obtain and validate the certificate, while the sender might not have the
complete certificate. For example, one possibility is that only part of the
certificate chain is sent and the message recipient needs to validate
the certificate (possibly using pre-provisioned certificates for building
the complete certificate chain), in order to know if it can trust it.
Another example is a sender that only has a hash of the certificate along
with the private key. In this case the recipient is expected to be able to
obtain the correct certificate and validate the message using the
appropriate key, probably verifying that the certificate is not revoked,
etc. Would the following wording work better for you?

Recipients MUST validate the certificate obtained from any of the following
four methods.

[1]: https://datatracker.ietf.org/doc/charter-ietf-cose/
[2]: https://mailarchive.ietf.org/arch/msg/cose/YE8-De30lEk52p9bY9oxB74x0BE/

Thanks,
Ivaylo

---

From: Martin Duke <[email-masked]>
Date: Mon, 12 Oct 2020 07:50:50 -0700

Hi Ivaylo,

Thank you very much for taking on this document after the dreadful news.

Your proposed sentence is an improvement, but I'm not sure how it combines
with the earlier sentence "It is not necessarily expected that constrained
devices themselves will evaluate and process of X.509 certificates". Is
"evaluate and process" a different action than "validating" it?

Or is the suggestion here that the constrained device is given a
certificate to authenticate itself that it does not bother to verify, but
hosts that connect to it *would* validate the certificate?

Martin

On Sun, Oct 11, 2020, 09:29 Ivaylo Petrov <[email-masked]> wrote:

> Hello Martin,
>
> Thank you for your comments! I am not sure if you are aware, but I am
> going to be handing some editorial changes to this document until
> publication. I will also try to answer your questions inline.
>
> On Wed, Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker <
> [email-masked]> wrote:
>
> [IP]: My understanding is that the recipient should have enough
> information to obtain and validate the certificate, while the sender might
> not have the complete certificate. For example, one possibility is that
> only part of the certificate chain is sent and the message recipient needs
> to validate the certificate (possibly using pre-provisioned certificates
> for building the complete certificate chain), in order to know if it can
> trust it. Another example is a sender that only has a hash of the
> certificate along with the private key. In this case the recipient is
> expected to be able to obtain the correct certificate and validate the
> message using the appropriate key, probably verifying that the certificate
> is not revoked, etc. Would the following wording work better for you?
>
> Recipients MUST validate the certificate obtained from any of the
> following four methods.
>
>
>
>>
>>
>>
>>
> [2]:
> https://mailarchive.ietf.org/arch/msg/cose/YE8-De30lEk52p9bY9oxB74x0BE/
>
>
> Thanks,
> Ivaylo
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Oct 2020 17:32:03 -0400

> "evaluate and process" a different action than "validating" it?

Validating is a well defined, complex process (RFC6125, etc.) involving path validation, etc.
Evaluate might mean something less, such as extracting the public key and
comparing against some known value.  We don't expect any of that.

    > hosts that connect to it *would* validate the certificate?

Yes, generally, that is what a lot of us have in mind.

The constrained device has a credential, if in the form of an IDevID or
LDevID certificate, then it would use this specification to places it into
the COSE object as a blob.

It has the private key side in a format that is more convenient for
processing (perhaps even in a secure enclave of some kind) which it uses to
sign.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ivaylo Petrov <[email-masked]>
Date: Tue, 13 Oct 2020 16:54:16 +0200

Thanks, Michael! That is also my understanding.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 19 Oct 2020 10:45:35 -0700

This is true, right? The relying party (the receiver) always has to validate the certificate chain up to a trust anchor even if it is a constrained device. The sender only has to insert certificates into the header, not validate, even if it is a non-constrained device. This is true of CMS, TLS and so on. There is nothing new or unique here right?

For example, if a constrained device is verifying code signatures, trusted boot chains or SUIT manifests, it has to fully validate the certificate chain up to a trust anchor. 

This paragraph is true for some use cases like CWT and Attestation, but not all use cases.

   It is not necessarily expected that constrained devices will fully
   support the evaluation and processing of X.509 certificates, it is
   perfectly reasonable for a certificate to be assigned to a device
   which it can then provide to a relying party along with a signature
   or encrypted message, the relying party not being a constrained
   device.

It is the requirements and design of the end-end system that determines what the constrained device has to do or not do, not the design of these headers. Probably it is an overreach to discuss end-end system designs. Maybe it is just better to remove this paragraph?

LL

> On Oct 12, 2020, at 2:32 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Oct 2020 08:58:15 +0200

> It is the requirements and design of the end-end system that determines what the constrained device has to do or not do, not the design of these headers. Probably it is an overreach to discuss end-…

The constrained device can delegate most of its tasks (“what is has to do”) to a (sufficiently trusted) less-constrained one (the only tasks that it cannot delegate are the ones needed to properly establish and maintain trust into that device and the communication with it).
The paragraph mostly serves as a reminder of how the task delegation pattern can alleviate the concerns that led to the original COSE not having X.509-related primitives.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 20 Oct 2020 10:05:30 -0700

> On Oct 19, 2020, at 11:58 PM, Carsten Bormann <[email-masked]> wrote:
> 

Hi Cartsen,

As someone who is not involved in Ace and some of the other work on constrained devices, with this explanation, the paragraph seems more out of place and misleading .
- It doesn’t inform or provide needed background info as to usage and design of cose-x509 (delegation issues are the same and even more important for regular x.509).
- It doesn’t say anything about delegation to a cloud or such, so it’s unclear what it is talking about
- Maybe it reminds some people that already know about architecture for delegation chain validation; not sure reminders for those in the know are useful
- The security considerations section for delegation of chain validation would be substantial

All that said, I don’t think the paragraph is so awful it I would say it must be deleted, but think the document would be better if it was (or it was expanded and moved to an appendix, or better yet some constrained device architecture / cook book document).

LL

---

From: Martin Duke <[email-masked]>
Date: Sat, 31 Oct 2020 13:56:03 -0700

I would be happy if it the paragraph in question was rewritten to be
clearer, perhaps using the words in the exchange between me and Michael.
Really, simply replacing the passive voice in the sentence with active
pretty much forces you to be clear about who is doing what.

On Tue, Oct 20, 2020 at 10:06 AM Laurence Lundblade <[email-masked]>
wrote:

> >> It is the requirements and design of the end-end system that determines
> what the constrained device has to do or not do, not the design of these
> headers. Probably it is an overreach to discuss end-end system designs.
> Maybe it is just better to remove this paragraph?
> >
> > The constrained device can delegate most of its tasks (“what is has to
> do”) to a (sufficiently trusted) less-constrained one (the only tasks that
> it cannot delegate are the ones needed to properly establish and maintain
> trust into that device and the communication with it).
> > The paragraph mostly serves as a reminder of how the task delegation
> pattern can alleviate the concerns that led to the original COSE not having
> X.509-related primitives.
>
> Hi Cartsen,
>
> As someone who is not involved in Ace and some of the other work on
> constrained devices, with this explanation, the paragraph seems more out of
> place and misleading .
> - It doesn’t inform or provide needed background info as to usage and
> design of cose-x509 (delegation issues are the same and even more important
> for regular x.509).
> - Maybe it reminds some people that already know about architecture for
> delegation chain validation; not sure reminders for those in the know are
> useful
> All that said, I don’t think the paragraph is so awful it I would say it
> must be deleted, but think the document would be better if it was (or it
> was expanded and moved to an appendix, or better yet some constrained
> device architecture / cook book document).
>
> LL
>
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Oct 2020 23:03:25 +0100

> On 2020-10-31, at 21:56, Martin Duke <[email-masked]> wrote:
> 
> I would be happy if it the paragraph in question was rewritten to be clearer, perhaps using the words in the exchange between me and Michael. Really, simply replacing the passive voice in the sentence with active pretty much forces you to be clear about who is doing what.

Like:

Certificates obtained from any of these methods MUST still be validated.
➔
Parties that intend to rely on the assertions made by a certificate
obtained from any of these methods still need to validate it.

?

(Note that I changed the RFC 2119 MUST into a statement of fact, which is orthogonal to the question of who the actor of the validation is.)

Grüße, Carsten