Benjamin Kaduk <ka...@mit.edu> wrote:
> On Mon, May 01, 2023 at 12:09:03PM +0200, Christian Amsüss wrote:
>> 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?
> I don't have much of an opinion on this at the moment but could
> probably be convinced that using IDevID is ok.
I wanted to wait for other opinions.
I begin to wonder if we should do our own 802.1AR. The document is 90%
references to IETF RFCs, many of them old or vague. Another half is a
pseudo-API, which nobody uses.
I don't really understand the concerns that Ben and Christian have raised.
>> * 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?)
> COSE key identifiers ('kid') are not exactly what you would typically
> call a "key identifier" in unconstrained spaces. In particular, they
> are just for optimizing lookup over trial decryption, and you have to
> associate your authorization data with the full key entry, not with the
> 'kid'. COSE 'kid' are not globally unique, and you might run into a
> lot of places using kid of '0' and relying on context to infer which
> one is meant.
pinned-domain-pubk pins a specific public key, in the case of "pubk", but
*value* the COSE kid is not really involved *at all*
pinned-domain-pubk-sha256 pins by SHA256 hash, but for 256-bit ECDSA keys, that
might
not be much of an actual savings.
>> * 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).
> It makes me nervous, but just because of the normal shared-key threat
> model. (It is the group-shared threat model since you may have more
> than one instance of AS for ANIMA purposes, but it's probably okay to
> have "AS1 attacks AS2" as out of scope since the AS is assumed to be
> trusted.)
symmetric keys could be used with constrained vouchers, from the MASA to the
Pledge. They couldn't be used in the other direction, where the Registrar,
having no relationship with the Pledge, needs to validate the IDevID.
I wouldn't want to do this though, and I see no advantage, only extreme risk.
>> * (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?
> Without the full context of the preceding thread, it's hard to be sure
> I understand properly, but I think yes, ANIMA expects LDevID for
> onboarded devices, so if you're building ACP using ACE crypto it should
> be fine.
I see no reason the (provisional)[D}TLS connection between Pledge and Registrar
can't be used to initialize a symmetric key for OSCORE. Apply a suitable key
exporter.
The Registrar becomes (or communicates with) the AS.
If you are using EDHOC, then a suitable key was already created by EDHOC.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
