On 3.04.2015 12:39, Anders Rundgren wrote: > On 2015-04-03 10:33, Vladimir Dzhuvinov wrote: >> 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. > > Hi Vladimir, > They are probably quite needed. > > If everything is based on OOB-arrangements you can probably drop a > bunch of parameters. If not don't you need alg to for example deal > with RS256 and RS512 in a reasonable way?
One would need the "alg" for RSA signatures if we have the public RSA key communicated OOB, but the algorithm is omitted. The JWK spec however gives us the optional "alg" parameter to communicate precisely this. So when a JWS is received, the "alg" can be obtained when one looks up the public RSA JWK. The argument is that including "alg" in the JWS header turns out to be redundant in common real-world cases. And if this is true, then we can regard it as optional :) Consider OpenID Connect for example: 1. The provider publishes the public JWK set at a URL, and each key must be given a "kid". 2. The ID token JWS "alg" is set by the "id_token_signed_response_alg" parameter at client registration. For ID token JWE there is "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc". 3. The ID token JWS "kid" header parameter is required to select the JWK for verification. Which "alg" is actually used to validate the ID token - the one from the JWS header or the one obtained at registration? http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation : "The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration." "If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it." The JWS "alg" is not really required by OIDC, but it's there because JOSE says it's mandatory. > By making a things optional you effectively introduce additional > complexity. This is a matter of perspective I believe. Image we looked at things this way: 1. Each application defines a trust model and corresponding process for signing / verification (encryption / decryption). 2. JOSE provides a set of available parameters to pick from. 3. The application defines which ones are required and which not. Let's consider OIDC again: There the "kid" is a required parameter to allow the JWK to be looked up, even though JOSE says it's an optional parameter. The JWT claims spec provides a good analogy: A set of standard claims to pick from, the application then defines which ones are must (e.g. iss, sub, aud, exp in OIDC) and which optional. Vladimir > Anders > >> >> 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 > > > > > _______________________________________________ > 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
