On Tue, Sep 16, 2025 at 02:00:26PM -0400, Simo Sorce wrote: > On Tue, 2025-09-16 at 12:25 -0500, Orie wrote: > > ... > > In general, a single key shall be used for only one purpose (e.g., > > encryption, integrity authentication, key wrapping, random bit generation, > > or digital signatures). > > ``` > > I would like to note that NIST has a bad habit of inserting operational > considerations into standards, and then people end up interpreting them > as implementation requirements. > > I believe this is on such case, where they are NISTsplaining how the > operator should behave and this text should not be taken to mean that > implementations should make it impossible (or even hard) to use a key > for multiple purposes (but it is perfectly ok for implementations to > provide the operator with ways of restricting key usage at their > discretion).
And in this case, it is not even using the key for multiple purposes, but for a single purpose. Even an extended definition (clearly more strict than the one NIST is using) would still consider those to be the same purpose. Furthermore, it is not good idea to blindly apply "best practices" (see Chesterton's Fence), there are many many examples of doing that leading to very poor results. In case of "one purpose" requirement, it is the risks of different algorithms or programs interacting in troublesome ways. That is not applicable here, because it is all the same algorithm and program. (As to multi-program interactions, imagine having to decrypt something encrypted using your EdDSA signature key...) > While I do think that reducing risk is a generally good idea, I think > this should be left higher in the stack, because time and again when > lower level libraries or standards are too rigid what actually happens > is that people end up messing it up badly in the upper layer by > applying "workarounds". And even if those "workarounds" do not end up causing security issues, those might very well end up causing interop issues. Even worse, sometimes those "workarounds" get put inside low-level code for proper interop landmine. > I think AKP falls short here because it *forces* the application > instead of simply providing an indication that most libraries will > follow but can be relaxed with a simple configuration option. Furthermore, JOSE does not mandate using JWK (nor does COSE mandate COSE_Key). Such requirements would interact very poorly with using X.509 properties (even if that only seems applicable for signatures). Thus, even if JOSE (and COSE) only has single-Algorithm, the libraries still need to process generic ML-KEM... Except when the libraries omit that, and it eventually turns into a problem. -Ilari _______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
