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] [mailto:[email protected]] On Behalf Of Richard
Barnes
Sent: Tuesday, May 07, 2013 2:08 AM
To: [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"
}],
"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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
