The evidence is that the alg / alg+enc parameters are not critical and required in all cases, and therefore redundant, and could be declared optional.
Could they be scrapped altogether? To me that's a different question, which requires investigation to be confident that no valid case is missed where their presence is actually needed. That the alg / alg+enc parameters are currently specified as mandatory apparently confuses people into thinking "alg" should be the prime determinant when processing received JWS / JWE objects. Applications should actually specify this prime determinant, i.e. the header parameters to include to enable the recipient to verify / decrypt the object. For OpenID Connect that is "kid" for example. I agree with John that "kid" goes not guarantee correct implementations. But to me that's a different concern, and I don't think we can use that as an argument for / against the mandatory use of alg. I'm grateful Tim brought this up, to illustrate the importance of letting the application determine the actual required JOSE parameters, and how this may translate to better and safer implementations. I'm a bit sad that we haven't fully realised this, at some earlier stage, now that JOSE is almost final and is widely deployed. But I hope this could still flow into the new binary encodings and are being developed now. Cheers, Vladimir On 3.04.2015 00:19, Tim McLean wrote: > 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 -- Vladimir Dzhuvinov :: [email protected]
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
