Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

From: Mike Jones <[email-masked]>
Date: Tue, 13 Oct 2015 23:48:31 +0000

Draft -03 of the JWS Unencoded Payload Option specification addresses the working group last call comments received.  Thanks to Jim Schaad, Vladimir Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments.  Changes were:

*         Allowed the ASCII space character and all printable ASCII characters other than period ('.') in non-detached unencoded payloads using the JWS Compact Serialization.

*         Updated the abstract to say that that the spec updates RFC 7519.

*         Removed unused references.

*         Changed the change controller to IESG.

The specification is available at:

*         https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03

An HTML formatted version is also available at:

*         http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.html

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465 and as @selfissued<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d>.

---

From: "Manger, James" <[email-masked]>
Date: Wed, 14 Oct 2015 13:54:44 +1100

Shouldn't draft-ietf-jose-jws-signing-input-options update RFC 7515 "JWS"? That seems quite important as draft-ietf-jose-jws-signing-input-options changes the meaning of valid JWS messages (new "b64" field that cannot be ignored, but is not listed in "crit"), and allows a bunch of previously invalid chars in JWS Compact Serializations (invalidating the JWS definition of Compact Serialization as a "URL-safe string").

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email-masked]
Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 17 Oct 2015 18:20:51 -0700

James,

I have been thinking about what you are saying in your mail.

1.       I agree with your question about doing an update to RFC 7515.  It
would be perfectly reasonable to mark this draft as doing an update because
it is defining a new header that can be placed in a JWS message.  It is
probably not required but needs to be considered.  It does not invalidate
the 7515 version of JWS as being URL-safe.  It would be recognized if you
are doing this document that the safety would be different.

2.      I think that there should be a recommendation that a "crit"
parameter stated as required (or at least strongly recommended) that lists
the "b64" header parameter in it.  At a minimum there should be a discussion
about the use of the "crit" parameter in this context.

Jim

From: jose [mailto:[email-masked]] On Behalf Of Manger, James
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

Shouldn't draft-ietf-jose-jws-signing-input-options update RFC 7515 "JWS"?
That seems quite important as draft-ietf-jose-jws-signing-input-options
changes the meaning of valid JWS messages (new "b64" field that cannot be
ignored, but is not listed in "crit"), and allows a bunch of previously
invalid chars in JWS Compact Serializations (invalidating the JWS definition
of Compact Serialization as a "URL-safe string").

--

James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Draft -03 of the JWS Unencoded Payload Option specification addresses the
working group last call comments received.  Thanks to Jim Schaad, Vladimir
Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments.  Changes
were:

*         Allowed the ASCII space character and all printable ASCII
characters other than period ('.') in non-detached unencoded payloads using
the JWS Compact Serialization. 

*
https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03

*
http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.ht
ml

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465 and as
@selfissued
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.co
m%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d
47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2
bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d> .

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Oct 2015 21:15:51 +0000

As I see it, explicitly updating JWS isn't necessary, since JWS established the JSON Web Signature and Encryption Header Parameters Registry to allow for additional Header Parameters to be defined, and so implementers are expected to refer to the registry and gracefully handle the possibility of extensions registered there.  The JWS Unencoded Payload Option specification registers such an extension.

As to whether "crit" is required, "crit" is only necessary if an explicit directive is required that the validation must fail if the header parameter is not understood.  However, in this case, if "b64" is not understood and simply ignored, the validation will fail without needing to use "crit", since the signature validation will fail.  Thus, the use of "crit" is unnecessary for "b64".

                                                                -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: RE: JWS Unencoded Payload Option spec addressing WGLC comments

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

*         https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-03&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cwfExLlgEK11IEBTdvKI63EI6xNBi1JTV0KVipTf8JU%3d>

*         http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-03.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nAlXMo6uPDM600pp0Kf1JQliQ4maLZc5eCMKfzCdQ8%3d>

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1465&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=L6oZmQ6tOl1eW%2fmh9zyorKeY4ouQZTGMn4o9Zid5snk%3d> and as @selfissued<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d>.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Oct 2015 15:52:45 -0700

Does making 'crit' not required open one up to the possibility of an attack
along the following lines:

1.       Create a JWS with a b64=true header

2.      Sign it using the b64=false construction

3.      Send it to a validator that does not understand the b64 header.

4.      Claim that the validator should have failed validation and not
performed the signed command

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 21, 2015 2:16 PM
To: Manger, James <[email-masked]>; [email-masked]
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

As I see it, explicitly updating JWS isn't necessary, since JWS established
the JSON Web Signature and Encryption Header Parameters Registry to allow
for additional Header Parameters to be defined, and so implementers are
expected to refer to the registry and gracefully handle the possibility of
extensions registered there.  The JWS Unencoded Payload Option specification
registers such an extension.

As to whether "crit" is required, "crit" is only necessary if an explicit
directive is required that the validation must fail if the header parameter
is not understood.  However, in this case, if "b64" is not understood and
simply ignored, the validation will fail without needing to use "crit",
since the signature validation will fail.  Thus, the use of "crit" is
unnecessary for "b64".

                                                                -- Mike

From: Manger, James [mailto:[email-masked]] 
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>

--

James Manger

*
https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf
.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-03&data=01%7c01%7cMi
chael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f
141af91ab2d7cd011db47%7c1&sdata=cwfExLlgEK11IEBTdvKI63EI6xNBi1JTV0KVipTf8JU%
3d> 

*
http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.ht
ml
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued
.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-03.html&data=01%7c0
1%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f98
8bf86f141af91ab2d7cd011db47%7c1&sdata=5nAlXMo6uPDM600pp0Kf1JQliQ4maLZc5eCMKf
zCdQ8%3d> 

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued
.info%2f%3fp%3d1465&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac28
56449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=L6oZmQ6
tOl1eW%2fmh9zyorKeY4ouQZTGMn4o9Zid5snk%3d>  and as @selfissued
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.co
m%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d
47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2
bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d> .

---

From: "Manger, James" <[email-masked]>
Date: Thu, 22 Oct 2015 11:31:49 +1100

Unfortunately Mike, the signature validation will not fail. By design draft-ietf-jose-jws-signing-input-options mimics RFC7515 in using "bytes before the 2nd dot" as the bytes to sign/verify. Consider a signer choosing the b64=false option from draft-ietf-jose-jws-signing-input-options to sign the 12-byte message "IOU_5000_USD". The header is {"alg":"HS256","b64":false} giving the JWS:
  eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2V9.IOU_5000_USD.xxxxxxxxxxxxxxxxxxxxxxxx

A verifier that only understands RFC7515 JWS interprets this as a normal JWS with an unknown but ignorable header member. The signature is still over eyJ..USD so it still verifies. The verifier then base64url-decodes the IOU.. part to get the validly-signed 9-byte content (in hex) 20 E5 3F E7 4D 34 FD 44  83.
Ouch! One JWS can be interpreted as a signed 12-byte or 9-byte message.

One fix might be to make the b64=false signing input:
  BASE64URL(UTF8(JWS Protected Header)) || '..' || JWS Payload
The two dots ensure the bytes signed when b64=false can never look like bytes signed according to RFC7515.
draft-ietf-jose-jws-signing-input-options should probably do this in addition to setting the crit field (so you can get a meaningful error message of "unsupported variety of JWS", instead of "signature failure" that could have all sorts of causes).

>From RFC7515 JWS, it would be perfectly reasonable to store a collection of compact-serialized-JWSs as comma-separated values - since a RFC7515 compact-serialized-JWS cannot contain a comma. draft-ietf-jose-jws-signing-input-options breaks that perfectly reasonable choice as now an unencoded non-detached JWS can have any bytes and still be called a compact-serialized-JWS. Saying draft-ietf-jose-jws-signing-input-options updates RFC7515 is the minimum required to note this, though that isn't really adequate. A better solution is to not allow an unencoded non-detached message to be called a compact-serialized-JWS: either don't define this combination, or call it something else (eg JWS raw serialization).

--
James Manger

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, 22 October 2015 9:53 AM
To: 'Mike Jones'; Manger, James; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Does making 'crit' not required open one up to the possibility of an attack along the following lines:

4.      Claim that the validator should have failed validation and not performed the signed command

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 21, 2015 2:16 PM
To: Manger, James <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

                                                                -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: JWS Unencoded Payload Option spec addressing WGLC comments

--
James Manger

                                                                -- Mike