[Anima] ANIMA and ACE, IDevID terminology (was: Re: cBRSKI)

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

Hi Michael,
(CC'ing ACE list because what I think will be the larger part of the
thread is hopefully relevant)

>     > 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.

When talking about such processes, can we still use the IDevID term
(even though an IDevID is "stored in a way that protects it from
modification"), or is the use of the term OK because we're not modifying
but replacing it, or do we need to use a more general term, or do we not
care?

>     > * 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.

In the current document, the only ACE reference is in an older version's
asssigned group. And I think that's good, for using-ANIMA-with-ACE is
orthogonal to doing-ANIMA-over-EDHOC.

It just may mean we need another document, unless we cram things
together in one (which, apart from any good-practice discussions, is
hard to convey to the initial reader, who'll need to understand that
they can use either part w/o the other).

> 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.

So, what'd we need?

* Does pinned-domain-pubk work also for COSE keys as used for signed
  CWTs? (If so, is there a key identifier to go with it?)
* Some ACE profiles (eg. ACE-OSCORE, RFC9203) are typically used with a
  symmetric key shared between AS and RS (and that may be the only key
  material). Is it fine from an ANIMA PoV to only have such key
  material? (When such a key is used, it obviously needs to be
  encrypted; at least some methods of ANIMA, eg. EST, can do that).
* (At least) When AS is used with asymmetric tokens, the RS needs to be
  told its audience identifier; I'd guess that'd be a new leaf.
* Once onboarding onto ACE has completed, all the device's identity
  would be ACE (except for the IDevID that's left in place for a factory
  reset). Is that fine with an ANIMA setup?

  I figure that the alternative is to have a dedicated registrar that
  then hands out certificates to the AS that allow the AS to
  (temporarily) speak for the CA, but this probably just shifts the
  questions above down to how those points above would be expressed in a
  certificate. Skipping that middle step would allow implementing
  devices that have ANIMA-style onboarding (cBRSKI with ake-authz,
  maybe), but (eg. using ACE-OSCORE) don't ever need asymmetric
  operations at runtime.

Or do I get the boundaries all wrong, and an ACE device would rather
express the concepts of a voucher in a CWT? (But ANIMA already did all
the hard work, and given such a device likely needs some CORECONF and
thus YANG anyway, reducing extra weight).

If not: Shall we just start a small and sleek document that registers
some values, and evolve it with some help from Mr. Cunningham?

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom