On Tue, Sep 17, 2024 at 1:20 PM Ilari Liusvaara <[email protected]> wrote:
> > In case of signed JWT, the very first thing that needs to be parsed out > is "iss". > > ... Which is a bit problematic. > > Yeah, I somewhat intentionally did not mention iss, because yeah, it is a bit problematic, and forces the "authorization decision passed down to downstream system" as a pattern. > > Unfortunately, that runs into problems with pre-hashing. > > Currently, that only gets problematic for RSA, but supporting pre-hashed > ML-DSA would also introduce the problem there. > > ECDSA has essentially fixed prehash (ok), and EdDSA in COSE/JOSE does > not support pre-hashing. > > > ... And as observation: This as polymorphic as it gets. > I'm not sure I follow. The hash function used with a signature scheme is part of the signature scheme as well, and so the public key should allow you to derive that information. Several common public key serialization formats unfortunately do not properly include the hash function, maybe that is what you are referring to? Or do you have a system where the decision which hash function to use is taken independently of the decision of which key to use? In that case, yeah you have lots of incompatibilities, especially in the case of ML-DSA where the hash function is fixed to SHAKE256, and has to be prefixed with a hash of the public key, but I'm not sure why the algorithm has to be part of the token to enable this use case. -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
