On Thu, Nov 13, 2025 at 01:43:19PM +0000, Sipos, Brian J. wrote: > Tiru, > > I am in favor of option 1 (AKP) because it is consistent and to me the > most understandable.
What are the operational issues of using AKP here? > You say in your description “a key cannot be reused” but that is > somewhat vague, it does not distinguish between the key material > and the COSE_Key object. It is indeed possible for a key set to repeat the same key with multiple different algorithms. However, dealing with that — including the case where the key is not repeated! — is quite a bit of complexity. Or implementation could just alias the algorithms, at cost of being interoperability hazard. > COSE_Key is about external representation of these data. If an > implementation or user chooses to internally represent things > differently that is fine. And if a use case requires multiple logical > COSE_Key containing the same `pub`/`priv` key material (and same > `kid`) with different `alg` I think that is also fine, and consistent > with all current definitions (even `kid` is not required to be unique > within an entity or domain per RFC 9052). I do not think either is fine. - Internal representation that ignores explicit MTI restrictions in key is interoperability hazard. - Dealing with repeated keys is quite a bit of complexity that would be best avoided. > I’m sure there are edge cases to this, but I don’t see a problem with > using AKP. Yes, there are more edge cases. Using AKP would also cause issues with JOSE-HPKE/COSE-HPKE. Both need pretty much the same KEM key types, but: - JOSE-HPKE does not work with AKP. - While using AKP keys for HPKE on sender side is fine, it is not fine on receiver side. I only noticed the latter issue when trying to add AKP support to COSE-HPKE test code. In the end, I ended up with both also supporting OKP, and aliasing the algorithms. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
