This is addressed in new security considerations text in draft -04.  Thanks 
again for thinking through this case.

                                                            -- Mike

From: Jim Schaad [mailto:[email protected]]
Sent: Thursday, October 22, 2015 7: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

Reply via email to