Hi Jim,
I assume you meant to wrote "payload" where you wrote protected. Assuming
that's the case, then yes, you're right. In the first case, you're signing the
payload [65, 66, 67, 68, 69, 70, 71], which is ASCII("ABCDEFG"). In the
second, you're signing the payload [0, 16, 131, 16, 81], which is
BASE64URL_DECODE("ABCDEFG"). Both of the signatures are the same.
I'm fine with your proposal to prevent these collisions by requiring that the
"b64" element be integrity protected, just like "crit" and "zip" must be (and
for similar reasons).
What do others think?
-- Mike
-----Original Message-----
From: Jim Schaad [mailto:[email protected]]
Sent: Monday, August 10, 2015 12:34 PM
To: Mike Jones; [email protected]
Subject: b64 must be signed
B64 needs to be a signed header or there are ambiguous signatures.
Consider the following:
{ "header": {"alg":"HS256", "b64":"false"}, protected:"ABCDEFG" }
And
{"header":{"alg":"HS256", "b64":"true"}, protected:"ABCDEFG"}
I have signed two different contents using the same key and the same algorithm.
These therefore have the same signature value. Since the b64 header is not
protected, an attacker can change between the two contents as they wish.
We have therefore created a collision condition.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
