Re: [Anima] cBRSKI

[Christian Amsüss <[e-mail]>]

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