If you want to make the case that we need to specify that specific values need
to be integrity protected in the JSON Serializations, providing justification
for why they must be integrity protected, that would be a very useful
contribution. We could add those requirements to a future version of the JSON
Serialization sections. For the Compact Serialization, none of that reasoning
is necessary or pertinent, since we decided to continue taking the conservative
route of integrity protecting everything.
The "yuck" cases you cite only arise because the working group decided at the
interim meeting to allow some unprotected headers for the JSON Serializations.
I agree that if we can clearly specify that some fields must be integrity
protected, it will have the positive effect of reducing the set of unnecessary
choices that would otherwise be available to implementers.
Do you have some idea of which header parameters must be integrity protected?
It sounds below like you do...
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Manger,
James H
Sent: Tuesday, May 07, 2013 7:08 PM
To: [email protected]
Subject: Re: [jose] FW: Draft write-up of discussion on JSON Serialization with
some non-protected fields
> A transformation from JWS and JWE objects using the compact serializations to
> ones using the JSON Serialization is always possible as simple syntactic
> transformation.
Great.
A "simple syntactic transformation" can’t work if "typ" has different values
for the 2 serializations so "typ":"JWE-JS" should be dropped.
> {"protected":"base64url(“{"enc":"A128GCM"}”)",
> "header":{"kid":"3"},
> "recipients":[
> {"header":{"alg":"A128KW"},
> "encrypted_key":"ekey"}],
> "initialization_vector":"iv",
> "ciphertext":"ct",
> "authentication_tag":"tag"
> }
From these examples it appears that the originator can arbitrarily decide which
header fields are protected and which are not. For instance, the 3 header
fields above ("enc":"A128GCM", "kid":"3", "alg":"A128KW") could be arranged in
8 different protected/unprotected combinations to create a valid JWE.
Yuck. This feels complex and dangerous. The 8 different combinations all have
slightly different security properties. How are recipients supposed to choose
which are safe to accept? If recipients only accept a subset we have major
interoperability problems. If recipients MUST accept all combinations then I
suspect we only get the security of the weakest combination (so there is very
little value in allowing the others).
It would be much better to decide: AEAD details are protected; key exchange
details are not protected (by the AEAD operation).
> By design, a transformation from a multi-recipient JWE or multi-signature JWS
> to the compact serializations is not possible.
A serialization that only supports the single-recipient (or single-signer) case
might be acceptable (though not ideal) if it really simplifies this common
case. However if JOSE defines a range of ways to create single-recipient
messages (eg with all-protected, all-unprotected, or mixed-protection for
header fields), then it is not acceptable for a JOSE serialization to only
support 1 of these.
Either the messages JOSE defines are "safe" (fit-for-purpose) so serializations
should support them, or such messages shouldn’t be defined at all.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
