Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

["Manger, James H" <[e-mail]>]

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Manger, James H
> Sent: Tuesday, June 18, 2013 8:52 PM
> To: Mike Jones; [e-mail]
> 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