Subject: Re: [jose] JWS Signing Input Options initial working group draft

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 4 Sep 2015 12:56:33 +0100

Though this restriction would probably not apply if the content is 
detached, not sure it makes a practical sense, but it appears it should 
work in case of JWS JSON where a detached payload is treated differently 
by individual signature functions...

Thanks, Sergey
On 21/08/15 17:33, Sergey Beryozkin wrote:
> I guess the b64 value would simply have to be the same in all the
> protected headers if it is a multiple signature container...
>
> Thanks, Sergey
> On 21/08/15 16:21, Sergey Beryozkin wrote:
>> As far as JWS JSON is concerned - would it be restricted to a container
>> with a single signature only (flattened or with the single element
>> signatures array) ?
>>
>> Thanks, Sergey
>>
>> On 21/08/15 14:09, Sergey Beryozkin wrote:
>>> Hi Mike
>>>
>>> The JWS JSON example at
>>>
>>> https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-01#section-4.2
>>>
>>>
>>>
>>>
>>> shows elements in the wrong order, according to
>>>
>>> https://tools.ietf.org/html/rfc7515#section-7.2.2
>>>
>>> the 'payload' should go first...
>>>
>>> thanks, Sergey
>>>
>>> On 10/08/15 21:01, Sergey Beryozkin wrote:
>>>> Hi Mike
>>>> Thanks for the clarification, indeed it all makes sense now (I would
>>>> like to think a bit more about JWT as JWS JSON, will send a separate
>>>> email if anything relevant comes to mind).
>>>>
>>>> Cheers, Sergey
>>>> On 10/08/15 16:40, Mike Jones wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Actually, the JWT restriction to only using the compact serialization
>>>>> is already in the JWT spec itself.  The last sentence of the first
>>>>> paragraph of the introduction at
>>>>> http://tools.ietf.org/html/rfc7519#section-1 says "JWTs are always
>>>>> represented using the JWS Compact Serialization or the JWE Compact
>>>>> Serialization".  The new text in the JWS Unsigned Payload Option spec
>>>>> just adds the restriction that JWTs are to continue to use RFC7515 as
>>>>> written - base64url encoding the JWT claims as they always have been -
>>>>> for interop purposes.
>>>>>
>>>>> That doesn't mean that other applications can't use JWS to sign
>>>>> detached unencoded JSON payloads with the "b64":false option using
>>>>> either JWS serialization.
>>>>>
>>>>> Does that address what you were thinking about or do you still have
>>>>> concerns?
>>>>>
>>>>>                 -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Beryozkin [mailto:[email-masked]]
>>>>> Sent: Monday, August 10, 2015 2:39 AM
>>>>> To: Mike Jones; [email-masked]
>>>>> Subject: Re: [jose] JWS Signing Input Options initial working group
>>>>> draft
>>>>>
>>>>> Hi, thanks for adding the JWS JSON (flattened serialization) example,
>>>>>
>>>>> I thought the earlier text was also clear about having to use the
>>>>> detached payloads in case of JWS Compact.
>>>>>
>>>>> Re the new JWT restriction.
>>>>>
>>>>> I know JWT is meant to be used primarily in OAuth2 contexts as a token
>>>>> or grant (or as one of token or grant property) representation and
>>>>> hence it is JWS Compact.
>>>>>
>>>>> But I wonder, should this particular text effectively block the
>>>>> possible future use of JWT in (JWS JSON) message payloads...
>>>>>
>>>>> Cheers, Sergey
>>>>> On 10/08/15 05:21, Mike Jones wrote:
>>>>>> You can't use an unencoded non-detached JSON payload using the JWS
>>>>>> Compact Serialization because it uses characters that aren't
>>>>>> URL-safe, such as "{".  For that reason, the spec now makes it clear
>>>>>> that JWTs cannot use the "b64":false option.
>>>>>>
>>>>>> You *can* use JSON payloads with the JWS JSON Serialization.  Any
>>>>>> double-quote characters in the JSON would have to be quoted -
>>>>>> typically using \" - so that the double-quotes don't terminate the
>>>>>> "payload" value.  See the new section
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8171fb874a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FdTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d
>>>>>>
>>>>>>
>>>>>>
>>>>>> for more on character restrictions in unencoded payloads.
>>>>>>
>>>>>>                 -- Mike
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: jose [mailto:[email-masked]] On Behalf Of Sergey
>>>>>> Beryozkin
>>>>>> Sent: Saturday, July 25, 2015 3:01 AM
>>>>>> To: [email-masked]
>>>>>> Subject: Re: [jose] JWS Signing Input Options initial working group
>>>>>> draft
>>>>>>
>>>>>> Hi, can you please add an example showing a b64 header affecting JWS
>>>>>> JSON payload ? I can imagine how it will look like but it is good to
>>>>>> see an example that can be tested locally...
>>>>>>
>>>>>> Cheers, Sergey
>>>>>> On 23/07/15 19:17, Mike Jones wrote:
>>>>>>> The initial working group version of JWS Signing Input Options has
>>>>>>> been posted.  It contains no normative changes from
>>>>>>> draft-jones-jose-jws-signing-input-options-00
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fself-issued.info%2f%3fp%3d1398&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zQrvoO4fBOa1nUomMVoBT862ELgRpuIQ%2fBaV17ijH7Y%3d>.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let the working group discussions begin!  I particularly call your
>>>>>>> attention to Martin Thomson's review at
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i
>>>>>>>
>>>>>>> e
>>>>>>> tf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html%2c&data=
>>>>>>>
>>>>>>> 0
>>>>>>> 1%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7
>>>>>>>
>>>>>>> e
>>>>>>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9gxWRy
>>>>>>>
>>>>>>> b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html%2c&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zdSucPmd5z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> and Matias Woloski's review at
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raojbpPQjvnjNDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> to start things off.
>>>>>>>
>>>>>>> The specification is available at:
>>>>>>>
>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftoo
>>>>>>>
>>>>>>> l
>>>>>>> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&data
>>>>>>>
>>>>>>> =
>>>>>>> 01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d
>>>>>>>
>>>>>>> 7
>>>>>>> e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B7CCBZSw%2f9mJ354xj
>>>>>>>
>>>>>>> 1
>>>>>>> Vplr0CKN3KjSDXHeFuUbWYx%2fs%3d
>>>>>>>
>>>>>>> An HTML formatted version is also available at:
>>>>>>>
>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself
>>>>>>>
>>>>>>> -
>>>>>>> issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-00.htm
>>>>>>>
>>>>>>> l
>>>>>>> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a424930
>>>>>>>
>>>>>>> 8
>>>>>>> d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H0jHGZqOrtsxM
>>>>>>>
>>>>>>> B
>>>>>>> EY3W7lFx2agz8V54RDoALY%2bxcjWV0%3d
>>>>>>>
>>>>>>>                                                                --
>>>>>>> Mike
>>>>>>>
>>>>>>> P.S.  This note is also posted at
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7cD9dg%3d
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> and as @selfissued
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=54dOa%2fD75zbVVpfbjYFAq4yL9zmJ7q9p2qIbJRY%2flIA%3d>.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> [email-masked]
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>>>>>>
>>>>>>> i
>>>>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40mi
>>>>>>>
>>>>>>> c
>>>>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2
>>>>>>>
>>>>>>> d
>>>>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5xM%
>>>>>>>
>>>>>>> 3
>>>>>>> d
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> [email-masked]
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
>>>>>>
>>>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40mic
>>>>>>
>>>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91ab2d
>>>>>>
>>>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5xM%3
>>>>>>
>>>>>> d
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Sep 2015 06:31:56 +0000

Draft -02 states that the "b64" Header Parameter value MUST be the same for all signatures/MACs.  Thanks for the useful review, Sergey!

				-- Mike

-----Original Message-----
From: Sergey Beryozkin [mailto:[email-masked]] 
Sent: Friday, August 21, 2015 9:33 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] JWS Signing Input Options initial working group draft

I guess the b64 value would simply have to be the same in all the protected headers if it is a multiple signature container...

Thanks, Sergey
On 21/08/15 16:21, Sergey Beryozkin wrote:
> As far as JWS JSON is concerned - would it be restricted to a 
> container with a single signature only (flattened or with the single 
> element signatures array) ?
>
> Thanks, Sergey
>
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftool
>> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-01%23se
>> ction-4.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c24e11589f9e3
>> 44f44be508d2aa463456%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vhW
>> RiTwt2MbSuMhjMVhcTI12MU5wNGwF9QWepV8TEho%3d
>>
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftool
>> s.ietf.org%2fhtml%2frfc7515%23section-7.2.2&data=01%7c01%7cMichael.Jo
>> nes%40microsoft.com%7c24e11589f9e344f44be508d2aa463456%7c72f988bf86f1
>> 41af91ab2d7cd011db47%7c1&sdata=hP6YA%2fCs309JrFa3NYZhs5%2bqoqZq5n2KGh
>> 9DkA4gxJk%3d
>>
>>>> Actually, the JWT restriction to only using the compact 
>>>> serialization is already in the JWT spec itself.  The last sentence 
>>>> of the first paragraph of the introduction at 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftoo
>>>> ls.ietf.org%2fhtml%2frfc7519%23section-1&data=01%7c01%7cMichael.Jon
>>>> es%40microsoft.com%7c24e11589f9e344f44be508d2aa463456%7c72f988bf86f
>>>> 141af91ab2d7cd011db47%7c1&sdata=aIQXtR12qzbEeS8iFMV0NblO7Tw%2fgH4Zw
>>>> 27vFHd%2bwzE%3d says "JWTs are always represented using the JWS 
>>>> Compact Serialization or the JWE Compact Serialization".  The new text in the JWS Unsigned Payload Option spec just adds the restriction that JWTs are to continue to use RFC7515 as written - base64url encoding the JWT claims as they always have been - for interop purposes.
>>>>
>>>> I know JWT is meant to be used primarily in OAuth2 contexts as a 
>>>> token or grant (or as one of token or grant property) 
>>>> representation and hence it is JWS Compact.
>>>>
>>>>> URL-safe, such as "{".  For that reason, the spec now makes it 
>>>>> clear that JWTs cannot use the "b64":false option.
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ft
>>>>> ools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-0
>>>>> 1%23section-5&data=01%7c01%7cMichael.Jones%40microsoft.com%7c634a8
>>>>> 171fb874a34dbe908d2a1678cfb%7c72f988bf86f141af91ab2d7cd011db47%7c1
>>>>> &sdata=FdTmmqFjXX9LBw56a1%2bk2K3dPmhp89ZqEec%2bgbAcRZA%3d
>>>>>
>>>>>
>>>>> Subject: Re: [jose] JWS Signing Input Options initial working 
>>>>> group draft
>>>>>
>>>>> Hi, can you please add an example showing a b64 header affecting 
>>>>> JWS JSON payload ? I can imagine how it will look like but it is 
>>>>> good to see an example that can be tested locally...
>>>>>
>>>>> Cheers, Sergey
>>>>>> The initial working group version of JWS Signing Input Options 
>>>>>> has been posted.  It contains no normative changes from
>>>>>> Let the working group discussions begin!  I particularly call 
>>>>>> your attention to Martin Thomson's review at 
>>>>>> 6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2mVSuUk74d8ZGB9g
>>>>>> xWRy b f%2bUz5pxOXmLiUcAqL%2bVvNk%3d Nat Sakimura's review at 
>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fw
>>>>>> ww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05189.html
>>>>>> %2c&data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442
>>>>>> a4249308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=z
>>>>>> dSucPmd5z%2b5Q5Zi%2fB61FmoUn9bhxmvatIl3R9WOdhQ%3d
>>>>>>
>>>>>>
>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fw
>>>>>> ww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html
>>>>>> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a42
>>>>>> 49308d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=raoj
>>>>>> bpPQjvnjNDynLSzSydtnVe%2fnfmWvIRTD9oXoKqA%3d
>>>>>>
>>>>>>
>>>>>> to start things off.
>>>>>>
>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs
>>>>>> elf-issued.info%2f%3fp%3d1432&data=01%7c01%7cmichael.jones%40micr
>>>>>> osoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91
>>>>>> ab2d7cd011db47%7c1&sdata=Ehd0PdoNA2rZx9b%2bTrPOgO5G2Nxkp1FutbTnL7
>>>>>> cD9dg%3d
>>>>>>
>>>>>>
>>>>>> and as @selfissued