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

"Jim Schaad" <> Wed, 19 June 2013 04:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D679221F9BA6 for <>; Tue, 18 Jun 2013 21:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 031HGXTFi6s9 for <>; Tue, 18 Jun 2013 21:48:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 224B421F9BA3 for <>; Tue, 18 Jun 2013 21:48:44 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9291D38F1B; Tue, 18 Jun 2013 21:48:43 -0700 (PDT)
From: "Jim Schaad" <>
To: "'Manger, James H'" <>, "'Mike Jones'" <>, <>
References: <> <>
In-Reply-To: <>
Date: Tue, 18 Jun 2013 21:47:48 -0700
Message-ID: <03a201ce6ca8$267c50f0$7374f2d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQJdUfWtdvWfIayb6axdJ1IllIJd1wIYXLYBmA3pO1A=
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2013 04:48:49 -0000

One possible way to do this can be seen in this document that is doing much the same thing for CMS.


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