> So we agree that dropping the JWS and JWE media types is a reasonable
> thing to do.
*Replacing* them with a JOSE media type 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.
The web works by labelling each data format with a media type.
I don't want to boil the ocean. I want to work with the web.
> 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.
The only reason a JOSE media type is not being used is that JWT defined its own
media type, probably because no suitable JOSE media type existed.
As an analogy, if application/json was not defined every app using JSON would
need to define an app-specific media type. In practice, application/json is
convenient in many situations.
> 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.
The "typ" fiasco showed many others also want a way to indicate the "mode" of a
JOSE message.
> 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.
As opposed to the multiple ways today - both the "alg" value and the
presence/absence of "enc".
My proposal defines 1 deterministic way (ie "mode" takes precedence):
Mode = header.get("mode)
If mode === undefined then
Alg = header.get("alg")
Mode = TABLE_OF_ALGS.get(alg).get("mode")
EndIf
Switch (mode)
Case "sig1" ...verify signature...
Case "enc1" ...decrypt...
Default ...ERROR: unsupported message...
EndSwitch
> 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?
{"mode":"sig1", "alg":"ECDH-ES"}
"mode" is "sig1" so the recipient tries to verify a signature, but fails
because the "alg" value isn't a signature algorithm. Trivial.
Not much different from a draft-11 message that has {"alg":"HS256",
"enc":"A256GCM"}.
Actually, my proposal is much better. With draft-11, half the recipients will
process this as a JWS (based on "alg"), the other half will process this as a
JWE (based on "enc") so who knows what will happen.
> That's a new error condition that rules would have
> to be specified to handle.
Draft-11 doesn't specify rules for handling {"alg":"HS256", "enc":"A256GCM"}.
It merely implies it cannot occur for legal input values -- no different than
"mode" and "alg" contradicting each other.
> It seems better to have one way of
> determining this, rather multiple ways that might conflict.
Agree. My proposal gives 1 way (that involves 2 steps to aid backward
compatibility).
> 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...
If the JOSE group decides media type parameters are too complicated I could
live with just application/jose and application/jose+json. Even that would be
much better than the current JWE/JWS/JWT media types. I think "inner" and
"mode" media type parameters add value.
--
James Manger
> -----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
