Subject: [jose] b64 must be signed

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 12:34:28 -0700

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.

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 20:56:47 +0000

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-masked]] 
Sent: Monday, August 10, 2015 12:34 PM
To: Mike Jones; [email-masked]
Subject: b64 must be signed

Consider the following:

And

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.