On Tue, Sep 17, 2024 at 11:35:39AM -0700, Sophie Schmieg wrote: > The main principle is to assume that everything in the token is crafted > specifically to lie to you, unless you have been able to confirm it came > from an honest party. > This means that until you have verified the signature, any data in the > token can only be used for the verification if you are entirely indifferent > to which of the possible values it presents. This is unfortunately a bit > more complicated than just saying "do not trust the header", but "do not > trust the header" is a good first approximation.
In case of signed JWT, the very first thing that needs to be parsed out is "iss". ... Which is a bit problematic. > For the algorithm header field, I am not aware of any reason to have that > in the token (other than the fact that it historically has been there). To > see why, we first need to look at the public key: The public key can never > be part of the token, since it is trivial to create a token with a valid > signature if the attacker gets to choose the public key, they can just > create the public key themselves. But conceptually speaking, the public key > includes the algorithm already, a RSA key, a ECDSA key, and a ML-DSA key > are not interchangeable after all. So if a token says it uses ECDSA as > algorithm, but the public key that is supposed to be used for verification > is a ML-DSA key, the token is clearly malformed, making the algorithm field > a field that only ever has information that is either superfluous (you > already knew it has to be ML-DSA because that is your public key's key > type) or invalid (the algorithm field does not align with the public key). > Therefore including the algorithm in the token is never useful. 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. > But it gets worse, if the application is implemented in the wrong way, it > will take the algorithm field of the token as authoritative and essentially > reinterpret_cast the public key bytes to the type the header field > suggested. It seems like there is some internal key format involved, because different COSE/JOSE key types have different fields that make up the actual key, number of such fields can vary, and there can be fields that are not part of actual key. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
