> 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
