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?
By making a things optional you effectively introduce additional complexity.
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
