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

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 <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Martin Duke <martin.h.duke@gmail.com> wrote:
>> 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?
> 
> 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.
> 
>> 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?
> 
> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose