Hi Michael Thank you for your time.
Agreed that MASA is the signing authority and the draft is meant to convey that the owner can influence the choice by way of parameterized inputs to the MASA APIs. So, owner can be presented with a 'security profile selector' input via the MASA external APIs and when the owner provides the PDC and the selector input values, MASA can then go ahead and create the voucher with appropriate security profile settings (after verification and validation) for the device. Hope it clarifies and I can modify the draft text to better convey the same. Thanks Srihari On 30/05/23, 9:35 PM, "Michael Richardson" <[email protected] <mailto:[email protected]>> wrote: Hi, I'll read your I-D, but: Srihari Raghavan \(srihari\) <[email protected] <mailto:[email protected]>> wrote: > 2. This allows the owner to change and > customize the security posture of the device dynamically and securely > and under scale. 3. This lets the owner to selectively enable or > disable each of the underlying security parameters that make up the > security posture of the device. Hi, RFC8366 Vouchers are signed by the MASA, not the owner, so this doesn't follow. We do desperately need a configuration backup/restore mechanism that can be audited and trusted, and this does need to be wrapped up into onboarding, but I don't think it can be done WITHIN the voucher, which is what I'm guessing you have done. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] <mailto:[email protected]> http://www.sandelman.ca/ <http://www.sandelman.ca/ >| ruby on rails [ _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
