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 protected]]
Sent: Friday, August 21, 2015 9:33 AM
To: Mike Jones; [email protected]
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
>
> On 21/08/15 14:09, Sergey Beryozkin wrote:
>> Hi Mike
>>
>> The JWS JSON example at
>>
>> 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
>>
>>
>>
>> shows elements in the wrong order, according to
>>
>> 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
>>
>> 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
>>>> 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.
>>>>
>>>> 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 protected]]
>>>> Sent: Monday, August 10, 2015 2:39 AM
>>>> To: Mike Jones; [email protected]
>>>> 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%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
>>>>>
>>>>>
>>>>> for more on character restrictions in unencoded payloads.
>>>>>
>>>>> -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: jose [mailto:[email protected]] On Behalf Of Sergey
>>>>> Beryozkin
>>>>> Sent: Saturday, July 25, 2015 3:01 AM
>>>>> To: [email protected]
>>>>> 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%2fw
>>>>>> ww.i
>>>>>> e
>>>>>> tf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html%2c&d
>>>>>> ata=
>>>>>> 0
>>>>>> 1%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d2
>>>>>> 94d7
>>>>>> e
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> and Matias Woloski's review at
>>>>>> 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.
>>>>>>
>>>>>> The specification is available at:
>>>>>>
>>>>>> *https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
>>>>>> ftoo
>>>>>> l
>>>>>> s.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&
>>>>>> data
>>>>>> =
>>>>>> 01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a4249308d
>>>>>> 294d
>>>>>> 7
>>>>>> e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B7CCBZSw%2f9mJ3
>>>>>> 54xj
>>>>>> 1
>>>>>> Vplr0CKN3KjSDXHeFuUbWYx%2fs%3d
>>>>>>
>>>>>> An HTML formatted version is also available at:
>>>>>>
>>>>>> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f
>>>>>> self
>>>>>> -
>>>>>> issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-00
>>>>>> .htm
>>>>>> l
>>>>>> &data=01%7c01%7cmichael.jones%40microsoft.com%7cf40ec174fcc442a42
>>>>>> 4930
>>>>>> 8
>>>>>> d294d7e6e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H0jHGZqOr
>>>>>> tsxM
>>>>>> B
>>>>>> EY3W7lFx2agz8V54RDoALY%2bxcjWV0%3d
>>>>>>
>>>>>> --
>>>>>> Mike
>>>>>>
>>>>>> P.S. This note is also posted at
>>>>>> 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
>>>>>> <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 protected]
>>>>>> 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%7c72f988bf86f141af9
>>>>>> 1ab2
>>>>>> d
>>>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V
>>>>>> 5xM%
>>>>>> 3
>>>>>> d
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> [email protected]
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
>>>>> ww.i
>>>>> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%4
>>>>> 0mic
>>>>> rosoft.com%7cf40ec174fcc442a4249308d294d7e6e0%7c72f988bf86f141af91
>>>>> ab2d
>>>>> 7cd011db47%7c1&sdata=fOZrXA8pnh4Z5XsMQw5ro6Fc0%2bECj%2bKjeEziSJ5V5
>>>>> xM%3
>>>>> d
>>>>>
>>>>
>>>
>>>
>>
>>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
