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 protected]]
Sent: Thursday, 22 October 2015 9:53 AM
To: 'Mike Jones'; Manger, James; [email protected]
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:
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 protected]] On Behalf Of Mike Jones
Sent: Wednesday, October 21, 2015 2:16 PM
To: Manger, James
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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 protected]]
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: 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 protected]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email protected]<mailto:[email protected]>
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.
* 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<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>
An HTML formatted version is also available at:
*
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>.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
