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

"Jim Schaad" <ietf@augustcellars.com> Wed, 19 June 2013 04:48 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679221F9BA6 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2013 21:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 031HGXTFi6s9 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2013 21:48:44 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 224B421F9BA3 for <jose@ietf.org>; Tue, 18 Jun 2013 21:48:44 -0700 (PDT)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9291D38F1B; Tue, 18 Jun 2013 21:48:43 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Manger, James H'" <James.H.Manger@team.telstra.com>, "'Mike Jones'" <Michael.Jones@microsoft.com>, <jose@ietf.org>
References: <4E1F6AAD24975D4BA5B1680429673943678735D4@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1151BA6A75E@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151BA6A75E@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 18 Jun 2013 21:47:48 -0700
Message-ID: <03a201ce6ca8$267c50f0$7374f2d0$@augustcellars.com>
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-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=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  http://www.ietf.org/internet-drafts/draft-turner-application-cms-media-type-04.txt that is doing much the same thing for CMS.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Tuesday, June 18, 2013 8:52 PM
> To: Mike Jones; jose@ietf.org
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose