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 protected]]
Sent: Tuesday, May 07, 2013 8:22 PM
To: Richard Barnes
Cc: Mike Jones; [email protected]
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 protected]<mailto:[email protected]>>
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:
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 protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>
[mailto:[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>]
On Behalf Of Richard Barnes
Sent: Tuesday, May 07, 2013 2:08 AM
To: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>
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
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"
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
