Subject: [jose] Common elements (was: Re: Should we keep or remove the JOSE JWS and JWE MIME types?)

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 14:41:14 -0400

While we're at it, you could move over the header parameters that are
shared between the two.  Namely all but "enc" and "zip".  ("epk", and "apu"
should move to JWA.)

And once you do that, it seems more and more like JWE is becoming the
little brother to JWS, in which case we might as well combine them.

On Thu, Jun 20, 2013 at 1:47 PM, Mike Jones <[email-masked]>wrote:

>  Editorially, if we do decide to add application/jose and
> application/jose+json MIME types, I would register them in
> draft-ietf-jose-json-web-signature, just like other registry content shared
> between JWS and JWE, such as the JSON Web Signature and Encryption Header
> Parameters Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18>
> .****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> -----Original Message-----
> From: Matt Miller (mamille2) [mailto:[email-masked]]
> Sent: Thursday, June 20, 2013 10:33 AM
> To: Richard Barnes
> Cc: Mike Jones; [email-masked]
> Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?
>
> ** **
>
> I just want to say that I think having a media type is important and
> useful.  It might not be important and useful for JWT or OAuth or
> OpenID-Connect, but I can think of many applications that would make use of
> them if at all possible.****
>
> ** **
>
> I personally don't care if it's a generic media type or individual
> application/jwe and application/jws.  However, I think a generic media type
> would require a separate document; trying to fit this into the one shared
> document (JWA) seems wrong.****
>
> ** **
>
> ** **
>
> - m&m****
>
> ** **
>
> Matt Miller < [email-masked] >****
>
> Cisco Systems, Inc.****
>
> ** **
>
> PS: I've found +json useful for other things, because I do have
> applications that present in different formats (right now that's usually
> +xml).  While there's not a simple corollary with XML-based concepts, I
> think there will be corollaries in the future (e.g., CBOR).  Having them
> now means we're not painted into a corner if (when) we look at JOSE2 and
> support for binary representations.****
>
> ** **
>
> On Jun 20, 2013, at 10:49 AM, Richard Barnes <[email-masked]>****
>
> wrote:****
>
> ** **
>
> > That algorithm is part of the story, but it's incomplete.  What we need
> is****
>
> > an algorithm that starts with an arbitrary octet string and sorts by****
>
> > JWS/JWE and serialization.  An outline of the flow chart:****
>
> > ****
>
> > 1. If content parses as valid JSON****
>
> > 1.*. Parse JSON****
>
> > 1.1. Iontains a "ciphertext" field -> JWE + JSON****
>
> > 1.2. Contains a "payload" field -> JWS + JSON****
>
> > 1.3. Else fail****
>
> > 2. Else if content matches the regex "^[a-zA-Z0-9_.-]*$"****
>
> > 2.*. Split on "."****
>
> > 2.1. If 5 components -> JWE + compact****
>
> > 2.2. If 3 components -> JWS + compact****
>
> > 2.3. Else fail****
>
> > 3. Else fail****
>
> > ****
>
> > There's also the question of which document this goes in.  It would be a
> ****
>
> > natural thing for a combined JWS+JWE document, but we don't have one of*
> ***
>
> > those :(****
>
> > ****
>
> > ****
>
> > ****
>
> > ****
>
> > On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <
> [email-masked]>wrote:****
>
> > ****
>
> >> There is a defined algorithm to distinguish between the JWS and JWE****
>
> >> objects in the third paragraph of****
>
> >>
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4
> ****
>
> >> .********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >>                                                            -- Mike*****
> ***
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]****
>
> >> *Sent:* Thursday, June 20, 2013 8:15 AM****
>
> >> *To:* Mike Jones****
>
> >> *Cc:* [email-masked]****
>
> >> ****
>
> >> *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> ****
>
> >> types?********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >> Multiplexing JWE and JWS under a single JOSE media type only makes sense
> ****
>
> >> if there's a defined algorithm to demux them.  So if you want to do
> this,****
>
> >> you would need to write down the algorithm.********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >> Personally, it seems simpler and clearer to me to just have the four***
> *
>
> >> current types, so that you know which type of object you're dealing
> with,****
>
> >> and in what serialization, without having to do content sniffing.******
> **
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <
> [email-masked]>****
>
> >> wrote:********
>
> >> ****
>
> >> 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********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> That being said, I’m not aware of any uses of these by applications at*
> ***
>
> >> present.  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?********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >>                                                                --
> Mike*******
>
> >> *****
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> P.S.  For completeness, I’ll add that the JWK document also defines
> these****
>
> >> MIME types:********
>
> >> ****
>
> >>                application/jwk+json********
>
> >> ****
>
> >>                application/jwk-set+json********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> There are already clear use cases for these types, so I’m not advocating
> ****
>
> >> deleting them, but wanted to call that out explicitly.  For instance,
> when****
>
> >> retrieving a JWK Set document referenced by a “jku” header parameter, I
> ****
>
> >> believe that the result should use the application/jwk-set+json type.
> (In****
>
> >> fact, I’ll add this to the specs, unless there are any objections.)****
>
> >> Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses****
>
> >> application/jwk+json.  Both could also be as “cty” values when
> encrypting****
>
> >> JWKs and JWK Sets, in contexts where that that would be useful.********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> ****
>
> >> _______________________________________________****
>
> >> jose mailing list****
>
> >> [email-masked]****
>
> >> https://www.ietf.org/mailman/listinfo/jose********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> > _______________________________________________****
>
> > jose mailing list****
>
> > [email-masked]****
>
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 19:04:06 +0000

As you know from our private conversation about your review comments, while closely related, the key selection header parameter definitions are, by design, not identical between the JWS and JWE spec.  In JWS they refer to the key that is used to check the signature/MAC.  In JWE they refer to the key to which the JWE was encrypted.  Trying to coalesce them would only make the text unnecessarily muddier in both cases.

                                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 11:41 AM
To: Mike Jones
Cc: Matt Miller (mamille2); [email-masked]
Subject: Common elements (was: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?)

While we're at it, you could move over the header parameters that are shared between the two.  Namely all but "enc" and "zip".  ("epk", and "apu" should move to JWA.)

And once you do that, it seems more and more like JWE is becoming the little brother to JWS, in which case we might as well combine them.

On Thu, Jun 20, 2013 at 1:47 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Editorially, if we do decide to add application/jose and application/jose+json MIME types, I would register them in draft-ietf-jose-json-web-signature, just like other registry content shared between JWS and JWE, such as the JSON Web Signature and Encryption Header Parameters Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18>.

                                                            -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

I just want to say that I think having a media type is important and useful.  It might not be important and useful for JWT or OAuth or OpenID-Connect, but I can think of many applications that would make use of them if at all possible.

I personally don't care if it's a generic media type or individual application/jwe and application/jws.  However, I think a generic media type would require a separate document; trying to fit this into the one shared document (JWA) seems wrong.

- m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >

Cisco Systems, Inc.

PS: I've found +json useful for other things, because I do have applications that present in different formats (right now that's usually +xml).  While there's not a simple corollary with XML-based concepts, I think there will be corollaries in the future (e.g., CBOR).  Having them now means we're not painted into a corner if (when) we look at JOSE2 and support for binary representations.

On Jun 20, 2013, at 10:49 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>>

wrote:

> That algorithm is part of the story, but it's incomplete.  What we need is

> an algorithm that starts with an arbitrary octet string and sorts by

> JWS/JWE and serialization.  An outline of the flow chart:

> 1. If content parses as valid JSON

> 1.*. Parse JSON

> 1.1. Iontains a "ciphertext" field -> JWE + JSON

> 1.2. Contains a "payload" field -> JWS + JSON

> 1.3. Else fail

> 2. Else if content matches the regex "^[a-zA-Z0-9_.-]*$"

> 2.*. Split on "."

> 2.1. If 5 components -> JWE + compact

> 2.2. If 3 components -> JWS + compact

> 2.3. Else fail

> 3. Else fail

> natural thing for a combined JWS+JWE document, but we don't have one of

> those :(

> On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <[email-masked]<mailto:[email-masked]>>wrote:

>> There is a defined algorithm to distinguish between the JWS and JWE

>> objects in the third paragraph of

>> *From:* Richard Barnes [mailto:[email-masked]]

>> *Sent:* Thursday, June 20, 2013 8:15 AM

>> *To:* Mike Jones

>> *Cc:* [email-masked]<mailto:[email-masked]>

>> types?****

>> if there's a defined algorithm to demux them.  So if you want to do this,

>> you would need to write down the algorithm.****

>> Personally, it seems simpler and clearer to me to just have the four

>> current types, so that you know which type of object you're dealing with,

>> and in what serialization, without having to do content sniffing.****

>> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>>

>> 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****

>> That being said, I'm not aware of any uses of these by applications at

>> present.  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

>> 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

>> 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?****

>>                                                                -- Mike***

>> P.S.  For completeness, I'll add that the JWK document also defines these

>> MIME types:****

>>                application/jwk+json****

>>                application/jwk-set+json****

>> There are already clear use cases for these types, so I'm not advocating

>> deleting them, but wanted to call that out explicitly.  For instance, when

>> retrieving a JWK Set document referenced by a "jku" header parameter, I

>> believe that the result should use the application/jwk-set+json type.  (In

>> fact, I'll add this to the specs, unless there are any objections.)

>> Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses

>> application/jwk+json.  Both could also be as "cty" values when encrypting

>> JWKs and JWK Sets, in contexts where that that would be useful.****

>> _______________________________________________

>> jose mailing list

>> [email-masked]<mailto:[email-masked]>

> _______________________________________________

> jose mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 16:36:07 -0400

And as I said in that conversation, it seems like you could have those two
sentences instead of 12 sections of duplicative text.

On Thu, Jun 20, 2013 at 3:04 PM, Mike Jones <[email-masked]>wrote:

>  As you know from our private conversation about your review comments,
> while closely related, the key selection header parameter definitions are,
> by design, not identical between the JWS and JWE spec.  In JWS they refer
> to the key that is used to check the signature/MAC.  In JWE they refer to
> the key to which the JWE was encrypted.  Trying to coalesce them would only
> make the text unnecessarily muddier in both cases.****
>
> ** **
>
>
> -- Mike****
>
> ** **
>
> *Sent:* Thursday, June 20, 2013 11:41 AM
> *To:* Mike Jones
> *Cc:* Matt Miller (mamille2); [email-masked]
> *Subject:* Common elements (was: Re: [jose] Should we keep or remove the
> JOSE JWS and JWE MIME types?)****
>
> ** **
>
> should move to JWA.)****
> little brother to JWS, in which case we might as well combine them.****
>
> ** **
>
> On Thu, Jun 20, 2013 at 1:47 PM, Mike Jones <[email-masked]>
> wrote:****
>
> [email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 21 Jun 2013 09:57:32 +1000

> Editorially, if we do decide to add application/jose and application/jose+json MIME types, I would register them in draft-ietf-jose-json-web-signature, just like other registry content shared between JWS and JWE, such as the JSON Web Signature and Encryption Header Parameters Registry.

>> While we're at it, you could move over the header parameters that are shared between the two.  Namely all but "enc" and "zip".  ("epk", and "apu" should move to JWA.)

+1

>> And once you do that, it seems more and more like JWE is becoming the little brother to JWS, in which case we might as well combine them.

+0.5
We do need a *single* description of the basic structure of any JOSE object. Calling such a spec "JWS" is not ideal. With a sensible separation of the spec into sections on the basic structure, a section of signing, a section on MACing, a section on authenticated encryption, sections on key exchange... -- it wouldn't matter quite so much if, say, the encryption section was in a separate document as long as it didn't have to duplicate so much text the way JWE does.

> As you know from our private conversation about your review comments, while closely related, the key selection header parameter definitions are, by design, not identical between the JWS and JWE spe…

Coalescing the text would highlight the design flaw that the same field (eg "kid") in the same place (JOSE header) has different meanings (eg identifying a recipient key or identifying an originator key). It might help us fix that design flaw.

--
James Manger