Subject: [jose] Selective header protection

From: Richard Barnes <[email-masked]>
Date: Tue, 7 May 2013 10:08:15 +0100

Dear JOSE WG,

[This will be better covered by the chair's minutes from the interim, but I
wanted to go ahead and post a summary so that related key wrapping
discussion can happen.]

One of the topics discussed at the JOSE interim was how to deal with header
integrity for multiple recipients.  There was agreement in the room to
proceed with a strategy of removing some header parameters from integrity
protection -- especially per-recipient parameters.

At a high-level, the change to the syntax is as follows:
-- For JWE, header parameters may be included at the top level of a JWE-JS
or within the "recipients" objects
-- Unprotected parameters are expressed as a JSON dictionary under the
"header" parameter
-- Protected parameters are base64-encoded and included under the
"protected" parameter

Thus, for example, a JWE might have the following form:
{
    "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": { "alg": "A128KW", "kid": "42" },
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

A complete set of examples is included below.  Comments welcome!

One area where comments would be especially helpful is the compact
serialization.  In the examples below, there are two proposed compact
serializations based on the new format.  Variant 1 maps "global" parameters
and "recipient" parameters to separate base64url-encoded parts.  Variant 2
combines them into a single dictionary.  On the one hand, Variant 1 maps
more simply to the JSON format; on the other hand, Variant 2 keeps the same
number of components as the current compact serialization.

Thanks,
--Richard

// Examples:
// 1. Current JWE-JS format
// 2. Proposed JWE-JS format
// 3. Simple example of proposed JWE-JS format
// 4. Current JWS-JS format
// 5. Proposed JWS-JS format
// 6. Proposed JWE-compact format (variant 1)
// 7. Proposed JWE-compact format (variant 2)

// JWE-CURRENT
// header = base64({"alg":"A128KW","enc":"A128GCM","kid":"42"})
{
    "recipients": [{
        "header":
"eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiNDIifQo",
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

// JWE-PROPOSED
// protected = base64({"enc":"A128GCM"})
{
    "header": { "typ": "JWE" },
    "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": { "alg": "A128KW", "kid": "42" },
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

// JWE-PROPOSED-SUPER-SIMPLE
// Single recipient, no protected parameters
{
    "header": {
        "typ": "JWE",
        "alg": "A128KW",
        "enc": "A128GCM",
        "kid": "42"
    },
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}

// JWS-CURRENT
// header = base64({"alg":"RS256","kid": "42"})
{
    "payload": "4_0ZISMX1I8xmdPTeBi6eg",
    "signatures": [{
        "header": "eyJhbGciOiJSUzI1NiIsImtpZCI6ICI0MiJ9Cg",
        "signature": "3Hu6Av79mEzu6...NcF16ls8gJDe2OmSY"
    }]
}

// JWS-PROPOSED
// protected = base64({"alg":"RS256"})
{
    "payload": "4_0ZISMX1I8xmdPTeBi6eg",
    "signatures": [{
        "header": { "kid": "42" },
        "protected": "eyJhbGciOiJSUzI1NiJ9Cg",
        "signature": "3Hu6Av79mEzu6...NcF16ls8gJDe2OmSY"
    }]
}

// JWE-PROPOSED-COMPACT-1
// protected = base64({"typ":"JWE","enc":"A128GCM"})
{
    "protected": "eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIn0K",
    "recipients": [{
        "header": {"alg":"A128KW","kid":"42"},
        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    }],
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}
=====COMPACT====
 eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIn0K
.eyJhbGciOiJBMTI4S1ciLCJraWQiOiI0MiJ9Cg
.w_6lbR8WRO0-pxm3MyEXmg
.vKjNIAhMfYW3zq-TikHfXQ
.PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03
.Zurj775FrQgnI-EPZmbUCg

// JWE-PROPOSED-COMPACT-2
// Header parameters from single recipient header folded into base header
// protected =
base64({"typ":"JWE","enc":"A128GCM","alg":"A128KW","kid":"42"})
{
    "protected":
"eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiQTEyOEtXIiwia2lkIjoiNDIifQo",
    "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
    "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",
    "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",
    "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"
}
=====COMPACT====
 eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiQTEyOEtXIiwia2lkIjoiNDIifQo
.w_6lbR8WRO0-pxm3MyEXmg
.vKjNIAhMfYW3zq-TikHfXQ
.PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03
.Zurj775FrQgnI-EPZmbUCg

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 May 2013 22:00:19 +0000

For context, I believe that the participants in the interim meeting had agreed that for the compact serializations (which only support a single recipient or signature), for simplicity reasons, we will continue to require that all header fields be integrity protected.  This means that the dot-separated fields for JWS and JWE remain as they are.  Yes, we'd discussed possibly adding more dot-separated fields as a hypothetical exercise, but decided not to do so for the single-recipient compact serialization case.

Other than recording the hypothetical discussion about possible adding more fields to the compact serializations, and the "JWE-PROPOSED-SUPER-SIMPLE" example, which was not discussed at the interim meeting, "I believe that Richard's note below accurately reflects the discussions on this topic during the interim working group meeting.

FYI, I'll also forward a note I wrote that independently recorded these decisions, which had previously been sent to the interim meeting participants.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, May 07, 2013 2:08 AM
To: [email-masked]
Subject: [jose] Selective header protection

Dear JOSE WG,

[This will be better covered by the chair's minutes from the interim, but I wanted to go ahead and post a summary so that related key wrapping discussion can happen.]

One of the topics discussed at the JOSE interim was how to deal with header integrity for multiple recipients.  There was agreement in the room to proceed with a strategy of removing some header parameters from integrity protection -- especially per-recipient parameters.

At a high-level, the change to the syntax is as follows:
-- For JWE, header parameters may be included at the top level of a JWE-JS or within the "recipients" objects
-- Unprotected parameters are expressed as a JSON dictionary under the "header" parameter
-- Protected parameters are base64-encoded and included under the "protected" parameter

One area where comments would be especially helpful is the compact serialization.  In the examples below, there are two proposed compact serializations based on the new format.  Variant 1 maps "global" parameters and "recipient" parameters to separate base64url-encoded parts.  Variant 2 combines them into a single dictionary.  On the one hand, Variant 1 maps more simply to the JSON format; on the other hand, Variant 2 keeps the same number of components as the current compact serialization.

Thanks,
--Richard

// Examples:

// JWE-CURRENT
        "header": "eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiNDIifQo",

// JWE-PROPOSED

// JWS-CURRENT

// JWS-PROPOSED

// protected = base64({"typ":"JWE","enc":"A128GCM","alg":"A128KW","kid":"42"})
    "protected": "eyJ0eXAiOiJKV0UiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiQTEyOEtXIiwia2lkIjoiNDIifQo",

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 May 2013 03:18:21 +0100

As I recall, there was no discussion of compact formats at the interim, so
both alternatives are available for comment. In both cases, all top-level
header fields are integrity-protected.

On Tuesday, May 7, 2013, Mike Jones wrote:

>  For context, I believe that the participants in the interim meeting had
> agreed that for the compact serializations (which only support a single
> recipient or signature), for simplicity reasons, we will continue to
> require that all header fields be integrity protected.  This means that the
> dot-separated fields for JWS and JWE remain as they are.  Yes, we’d
> discussed possibly adding more dot-separated fields as a hypothetical
> exercise, but decided not to do so for the single-recipient compact
> serialization case.****
>
> ** **
>
> Other than recording the hypothetical discussion about possible adding
> more fields to the compact serializations, and the
> “JWE-PROPOSED-SUPER-SIMPLE” example, which was not discussed at the interim
> meeting, “I believe that Richard’s note below accurately reflects the
> discussions on this topic during the interim working group meeting.****
>
> ** **
>
> FYI, I’ll also forward a note I wrote that independently recorded these
> decisions, which had previously been sent to the interim meeting
> participants.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *On Behalf Of *Richard Barnes
> *Sent:* Tuesday, May 07, 2013 2:08 AM
> *To:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> *Subject:* [jose] Selective header protection****
>
> ** **
>
> Dear JOSE WG,****
>
> ** **
>
> [This will be better covered by the chair's minutes from the interim, but
> I wanted to go ahead and post a summary so that related key wrapping
> discussion can happen.]****
>
> ** **
>
> One of the topics discussed at the JOSE interim was how to deal with
> header integrity for multiple recipients.  There was agreement in the room
> to proceed with a strategy of removing some header parameters from
> integrity protection -- especially per-recipient parameters.****
>
> ** **
>
> At a high-level, the change to the syntax is as follows:****
>
> or within the "recipients" objects****
>
> "header" parameter****
> "protected" parameter****
>
> ** **
>
> Thus, for example, a JWE might have the following form:****
>
> {****
>
>     "protected": "eyJlbmMiOiJBMTI4R0NNIn0K",****
>
>     "recipients": [{****
>
>         "header": { "alg": "A128KW", "kid": "42" },****
>
>         "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"****
>
>     }],****
>
>     "initialization_vector": "vKjNIAhMfYW3zq-TikHfXQ",****
>
>     "ciphertext": "PTRhlo61rZ9bcVFLGK6sIi21r9-Zez03",****
>
>     "authentication_tag": "Zurj775FrQgnI-EPZmbUCg"****
>
> }****
>
> ** **
>
> A complete set of examples is included below.  Comments welcome!****
>
> ** **
>
> number of components as the current compact serialization.****
>
> ** **
>
> Thanks,****
>
> --Richard****
>
> ** **
>
> ** **
>
> // Examples:****
>
> // 1. Current JWE-JS format****
>
> // 2. Proposed JWE-JS format****
>
> // 3. Simple example of proposed JWE-JS format****
>
> // 4. Current JWS-JS format****
>
> // 5. Proposed JWS-JS format****
>
> // 6. Proposed JWE-compact format (variant 1)****
>
> // 7. Proposed JWE-compact format (variant 2)****
>
> ** **
>
> ** **
>
> // JWE-CURRENT****
>
> // header = base64({"alg":"A128KW","enc":"A128GCM","kid":"42"})****
>
> {****
>
>     "recipients": [{****
>
>         "header":
> "eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiNDIifQo",****
>
>         "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"****
>

---

From: John Bradley <[email-masked]>
Date: Tue, 7 May 2013 20:22:16 -0700

I remember standing at the white board and discussing it.  People agreed that we would put all the headers in a single protected JAON object.  You commented that that would work and be comparable with the existing compact format, but we could add another dot separated segment if we wanted to have unprotected headers. 

It was discussed.  You disagreed and prefers the additional segment. 

John B. 

Sent from my iPhone

On 2013-05-07, at 7:18 PM, Richard Barnes <[email-masked]> wrote:

> As I recall, there was no discussion of compact formats at the interim, so both alternatives are available for comment. In both cases, all top-level header fields are integrity-protected. 
> 
> 
>> For context, I believe that the participants in the interim meeting had agreed that for the compact serializations (which only support a single recipient or signature), for simplicity reasons, we will continue to require that all header fields be integrity protected.  This means that the dot-separated fields for JWS and JWE remain as they are.  Yes, we’d discussed possibly adding more dot-separated fields as a hypothetical exercise, but decided not to do so for the single-recipient compact serialization case.
>> 
>>  
>> 
>> Other than recording the hypothetical discussion about possible adding more fields to the compact serializations, and the “JWE-PROPOSED-SUPER-SIMPLE” example, which was not discussed at the interim meeting, “I believe that Richard’s note below accurately reflects the discussions on this topic during the interim working group meeting.
>> 
>>  
>> 
>> FYI, I’ll also forward a note I wrote that independently recorded these decisions, which had previously been sent to the interim meeting participants.
>> 
>>  
>> 
>>                                                             -- Mike
>> 
>>  
>> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Wed, 8 May 2013 07:15:38 +0000

John’s recollection matches mine.  The discussion was very short because no one went to bat for changing the Compact Serializations.  (If anyone had, I’m certain that it would have been a longer, much more memorable discussion.)

Keeping the Compact Serializations intact was a core element of the compromise agreed to wherein we also allowed the possibility of non-integrity-protected header values in the JSON Serializations.

I believe that we’re in a good place now as a result, where full generality is possible in the JSON Serializations with multiple recipients/signatures and where the Compact Serializations remains simple – with optimizations intentionally employed that are enabled by capitalizing on the by-design constraint that that the Compact Serializations are restricted to a single recipient/signature.

                                                            -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Tuesday, May 07, 2013 8:22 PM
To: Richard Barnes
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Selective header protection

John B.

Sent from my iPhone

On 2013-05-07, at 7:18 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
As I recall, there was no discussion of compact formats at the interim, so both alternatives are available for comment. In both cases, all top-level header fields are integrity-protected.

                                                            -- Mike

From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf Of Richard Barnes
Sent: Tuesday, May 07, 2013 2:08 AM
To: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
Subject: [jose] Selective header protection

Dear JOSE WG,

{

    "recipients": [{

    }],

}

Thanks,

--Richard

// Examples:

// JWE-CURRENT

{

    "recipients": [{

        "encrypted_key": "w_6lbR8WRO0-pxm3MyEXmg"
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 May 2013 16:46:41 +0100

Ok, in any case, I don't think there was any agreement/consensus at the
f2f, mainly just "you could do X" or "Y".  So I think that comments from
the WG on their feelings about the two possibilities are still helpful.

FWIW, I prefer the "extra dot" version because it's a much cleaner map to
JSON.

--Richard

On Wed, May 8, 2013 at 8:15 AM, Mike Jones <[email-masked]>wrote:

>  John’s recollection matches mine.  The discussion was very short because
> no one went to bat for changing the Compact Serializations.  (If anyone
> had, I’m certain that it would have been a longer, much more memorable
> discussion.)****
>
> ** **
>
> Keeping the Compact Serializations intact was a core element of the
> compromise agreed to wherein we also allowed the possibility of
> non-integrity-protected header values in the JSON Serializations.****
>
> ** **
>
> I believe that we’re in a good place now as a result, where full
> generality is possible in the JSON Serializations with multiple
> recipients/signatures and where the Compact Serializations remains simple –
> with optimizations intentionally employed that are enabled by capitalizing
> on the by-design constraint that that the Compact Serializations are
> restricted to a single recipient/signature.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* John Bradley [mailto:[email-masked]]
> *Sent:* Tuesday, May 07, 2013 8:22 PM
> *To:* Richard Barnes
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [jose] Selective header protection****
>
> ** **
>
> I remember standing at the white board and discussing it.  People agreed
> that we would put all the headers in a single protected JAON object.  You
> commented that that would work and be comparable with the existing compact
> format, but we could add another dot separated segment if we wanted to have
> unprotected headers. ****
>
> ** **
>
> It was discussed.  You disagreed and prefers the additional segment. ****
>
> ** **
>
> John B.
>
> Sent from my iPhone****
>
>
> On 2013-05-07, at 7:18 PM, Richard Barnes <[email-masked]> wrote:****
>
>  As I recall, there was no discussion of compact formats at the interim,
> so both alternatives are available for comment. In both cases, all
> top-level header fields are integrity-protected. ****
>
>
>
> On Tuesday, May 7, 2013, Mike Jones wrote:****
>
>  ****
>  ****
>  ****
>  ****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *To:* [email-masked]
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/jose****
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 8 May 2013 08:51:46 -0700

Fair enough you did express your preference for the extra dot format at the time as being closer to the JSON format.

Others preferred not adding an extra segment and keeping the existing compact format.

John B.

On 2013-05-08, at 8:46 AM, Richard Barnes <[email-masked]> wrote:

> Ok, in any case, I don't think there was any agreement/consensus at the f2f, mainly just "you could do X" or "Y".  So I think that comments from the WG on their feelings about the two possibilities are still helpful.
> 
> FWIW, I prefer the "extra dot" version because it's a much cleaner map to JSON.
> 
> --Richard
> 
> 
> On Wed, May 8, 2013 at 8:15 AM, Mike Jones <[email-masked]> wrote:

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 May 2013 16:54:51 +0100

What's the cost of an extra segment?  Your'e already doing jwe.split('.').
 So you just need to shift your indices by one in the next line.

On the other hand, coalescing the headers into a single value requires
special-casing the single recipient case.

On Wed, May 8, 2013 at 4:51 PM, John Bradley <[email-masked]> wrote:

> Fair enough you did express your preference for the extra dot format at
> the time as being closer to the JSON format.
>
>>  John’s recollection matches mine.  The discussion was very short
>> because no one went to bat for changing the Compact Serializations.  (If
>> anyone had, I’m certain that it would have been a longer, much more
>> memorable discussion.)****
>>
>> ** **
>>
>> -- For JWE, header parameters may be included at the top level of a
>> JWE-JS or within the "recipients" objects****
>>