> On Oct 19, 2020, at 11:58 PM, Carsten Bormann <c...@tzi.org> wrote: > > On 2020-10-19, at 19:45, Laurence Lundblade <l...@island-resort.com> 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). - 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 _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
