Christian Amsüss <[email protected]> wrote: > * 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).
It certainly could do that. and remote attestation might mean you'd trust
what it tells you.
However, in some scenarios, the amount of space available might not be a
lot, and also in some models "factory reset" really means deleting EVERYTHING.
The MASA audit log also could be subject to various witness processes, such
as time stamping.
>> [...] 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?
Yes, I agree: replacing the IDevID makes a lot of sense if the control over
the software-update trust anchor changes.
> * 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.
Yeah, that makes sense to me.
I think that ace-ake-authz intended to describe things in terms of ACE.
The AS == Registrar, I think.
Or, perhaps the AS uses a key that the local CA (mediated by the Registrar as
a trust anchor, /cacerts) has blessed in some way. How that works is TBD.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
