On Thu, Apr 2, 2015 at 3:46 PM, John Bradley <[email protected]> wrote:
> Without alg we would have a problem with crypto agility. > > At some point algorithms are deprecated and you need a window to move from > one to another. They may both use the same key, such as HMACSHA1 and > HMACSHA256. > > The receiver of a signed object may need to determine from the object: > 1. Who it is from “iss” > 2. The algorithm to use > 3. What key they used “kid”, “jku” or implicit if there is only one key > for a alg. > > It is the application that needs to determine the trust relationship. > > Removing “alg” from the wire level protocol would not be a good idea. > > It however might be better to have lower level crypto libs that don’t have > a view into the trust model only accept keys and algs that are explicitly > passed in rather than splitting the logic into two places. > > What keys, algorithms, and issuers are permissible on given channels is > something that needs to happen outside the low level crypto lib. > > It is also possible that a relying party might receive a token with a kid > alg and sig that all verify perfectly, but if Issuer A is signing the token > and inserting Issuer B in the “iss” and the RP is not checking that the > key retrieved via the kid belongs to issuer B then we also have a problem. > > In looking at the libraries that were able to be tricked into using a RSA > (and probably EC) public key as a HMAC key they seam to be in weakly typed > languages. > The attack worked because the keys were coerced into the needed type. > > I give you full credit for finding this, and am grateful that you are > looking at implementations. > > John B. > Good point about crypto agility, John. I think that's worth investigating further. I think algorithm updates/changes can be achieved via key rotation. Given a "key1" that is defined to use algorithm A: - Create a "key2" that uses algorithm B. - Publish "key2" to all parties planning to receive JWSs. - Switch all relevant devices from signing with "key1" to signing with "key2". - (optional) Publish the fact that "key1" should no longer be accepted. If needed, the only difference between "key1" and "key2" could be that they are defined to use different algorithms -- the underlying key material could be identical. I don't think that would be advisable though; reusing keys between algorithms might give up any benefit of the upgrade (or could completely destroy security if the algorithms have unexpected interactions). Cheers, Tim
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
