So we agree that dropping the JWS and JWE media types is a reasonable thing to
do.
As far as adding a complicated new media type without a clear use case to do
so, we don't agree. We're not trying to boil the ocean here. This thread was
intended to be about simplifying things by removing things that aren't actually
being used - not adding new complicated things that also aren't being used.
For context on your proposal below, you've proposed several times in several
ways to completely restructure the processing rules for JWS and JWE. None of
those have gained traction with the working group to date. Your proposal below
seems to be more of the same - at least to me.
One of the problems this would create would be having multiple ways of
indicating whether the object is a JWS or JWE - both the "alg" value and the
additional values you propose. A problem with such duplication is that it
creates new error conditions to handle. For instance, what if your new
parameters said that the content was a JWS but the content was actually a JWE?
That's a new error condition that rules would have to be specified to handle.
It seems better to have one way of determining this, rather multiple ways that
might conflict.
Without a clear use case for adding the complicated media type you describe
below which seems far from minimal, including saying why its goals can't be
accomplished with what already exists, I don't think it makes sense. My view,
anyway...
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Manger,
James H
Sent: Tuesday, June 18, 2013 8:52 PM
To: Mike Jones; [email protected]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?
Good questions, Mike. My (backward compatible) suggestions below.
> The JWS and JWE documents currently define these MIME types for the
> convenience of applications that may want to use them:
> application/jws
> application/jws+json
> application/jwe
> application/jwe+json
Drop these.
Define application/jose and application/jose+json.
Allow two optional parameters on these media types:
inner -- indicates the media type of the content of the JOSE message, after
removing 1 or more layers of JOSE protection. For instance, if a JPEG image is
signed with an RSA key, then encrypted with AES-GCM, inner would be image/jpeg.
mode -- indicates the sort of protection applied (eg signed, encrypted,
unprotected...). If multiple modes of protection are applied in turn (eg signed
then encrypted) they can all be listed: from the outer-most mode to the
inner-most; separated by a plus (eg mode="enc+sig").
A "mode" media type parameter would be easy to specify if JOSE messages had a
corresponding header field, instead of inferring the sort of processing from
the "alg" value. :-(
Suggestion:
1. Define a header parameter that indicates the sort of processing. Its name
could be "T", or "mode" (just not "typ" as that is too confused).
[I like "T" (short; stands out as THE primary field in a JOSE message), but I
use "mode" below to be a little less controversial.]
2. Create a registry for "mode" values.
3. Define some initial "mode" values, alongside the spec for that processing:
"sig1" for digitally signing B64(header).B64(content);
"mac1" for MAC over B64(header).B64(content);
"enc1" for AEAD, where AAD is B64(header)
"none" for unprocessed content
"cmp" for compressed (but not protected) content
"enc2" for AEAD applied differently (as per the JSON representation)
...
4. Allow the "mode" parameter to be absent if an "alg" value is present and has
a default "mode". This maintains compatibility with JOSE messages based on
previous drafts.
5. Define the default "mode" for existing "alg" values. For instance, for
"alg":"HS256" the default is "mode":"mac1". The registry of alg values would
have a column for the default mode (though new algs can leave that column
blank).
6. Drop the "crit" field. If you are creating a JOSE message with new semantics
that MUST be understood, just define a new "mode" value. For example, to avoid
some base64 overhead you could define "mode":"sig2" to mean digitally sign
header||content||len(header).
7. Allow a list of "mode" values to be specified as a parameter on a JOSE media
type.
[probably]
8. A plus sign "+" can be appended to any "mode" value to indicate that the
content of this JOSE layer is another JOSE layer. That is, process this message
as per the "mode" without the "+", then process the content as another JOSE
message.
[Appending "+" is simpler than "cty":"jws" or "more":true, but assumes the
inner JOSE message uses the same serialization as the outer one.]
End result: simpler, more easily understood by people; one field that is
suitable for an implementation to use to switch to the appropriate processing
code; backward compatible with earlier drafts; clear mechanism for making
changes that MUST-be-understood (that we can be confident code will notice).
> That being said, I’m not aware of any uses of these by applications at
> present.
Apps such as OpenID Connect could use:
application/jose;inner=application/jwt+json
Apps can still define their own media types for JOSE messages (eg
application/jwt) though that should not be necessary.
> Thus, I think that makes it fair game to ask whether we want to keep
>them or remove them – in which case, if applications ever needed them,
>they could define them later.
>
> Another dimension of this question for JWS and JWE is that it’s not
> clear that the four types application/jws, application/jws+json,
> application/jwe, and application/jwe+json are even the right ones. It
> might be more useful to have generic application/jose and
> application/jose+json types, which could hold either JWS or JWE
> objects respectively using the compact or JSON serializations
> (although I’m not advocating adding them at this time).
>
> Having different JWS versus JWE MIME types apparently did contribute
> to at least Dick’s confusion about the purpose of the “typ” field, so
> deleting them could help eliminate this possibility of confusion in
> the future. Thus, I’m increasingly convinced we should get rid of the
> JWS and JWE types and leave it up to applications to define the types
> they need, when they need them.
>
> Do people have use cases for these four MIME types now or should we
> leave them to future specs to define, if needed?
We are defining a format for use on the web. The web identifies formats via
media types. So JOSE needs to define media types.
--
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
