Hello Michael, thanks for the answers and the suggestion to move this onto the list.
Follow-up questions: * On devices where the IDevID can be kept safe from owners, can't the device keep a log locally to the same effect as a MASA log on whether that device has been owned before? It'd appear that tamper-proofness would be the only difference to a logged voucher. (Then again, the MASA might also tamper). > > If an owner can take complete control over a device (like, switch over the > > firmware, as you can do with a PC or a device that contains GPL-3 > > software), would the issuer of such a new firmware also need to provision > > the device with a new IDevID? > > Maybe. Probably be a good idea. The MASA URL would be wrong in the existing > IDevID. RFC8995 provides for the Registrar to have the ability to override > that URL under operator control. That would apply to all devices from that > manufacturer, probably, so it's a big hammer. Replacing the IDevID would be > simpler. > > [...] An owner might be permitted to load whatever code they want, > and depending upon many concerns, that might include getting access to > the IDevID private key, if it is stored on an fTPM or not secured at > all. * If the device can do a full firmware replacement (including the bootloader), even if the IDevID's private key is kept in a secure element, the new firmware could be used to sign[^1] with the IDevID in some scenarios. I think it'd be prudent for such upgrades to remove that IDevID. As IDevIDs are supposed to be immutable (if I read 802.1AR correctly -- probably makes sense for the devices IEEE is considering): Is there a generalization of the IEEE identifiers that also makes sense for constrained but more general-purpose-oriented devices, for which the ANIMA products can still be used? [^1]: Or use the key in any other limited way. * Is there any document that describes (or has an example of) how ANIMA onboarding interacts with ACE's AS? My current -- maybe naive -- assumption is that a voucher in this countext would contain a pinned-domain-pubk which is the public key the AS will use to sign ACE tokens, and the est-domain would indicate the AS URI, but with the pinned-domain-pubk being described in TLS terms (whereas an ACE AS uses COSE keys), this may be skipping a step. BR c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
