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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
