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. > On Apr 2, 2015, at 2:49 PM, Tim McLean <[email protected]> wrote: > > On Thu, Apr 2, 2015 at 11:39 AM, Breno de Medeiros <[email protected] > <mailto:[email protected]>> wrote: > > Ins't the point here that libraries should _not_ work out of the box until > some kind of trust configuration is provided? alg:none can be perfectly > acceptable if the channel is trusted, for instance. > > I agree. Basically, what I'm saying is: > - that trust configuration should include which algorithm meant to be used. > - if there is a complete trust configuration, then the `alg` field is not > needed (since it is already known). > > In many libraries, the implementer did not realize that the choice of > algorithm should be part of the trust configuration, causing them to use and > trust the `alg` field. Since it's not needed, why lead implementers astray? > > Cheers, > Tim > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
