+1 to everything James says here. "cty" == Content-Type. It's just a MIME type for the encapsulated content.
The "application/" hack is clever. I would like some apps people to review, but it seems workable to me at first blush. On Thu, May 30, 2013 at 4:09 AM, Manger, James H < [email protected]> wrote: > > The purpose of the “JWS” and “JWE” types is to provide standard > identifiers for applications that may want to use them, either in the “typ” > field**** > > ** ** > > Don’t do that. We already know it’s a JOSE message. We already know it’s a > JWE or JWS by alg or enc (or [2]). So typ:JWE or typ:JWS can add nothing > but confusion. If an app has no extra semantics above it being a JOSE > message, then they should omit “typ”.**** > > ** ** > > > or the “cty” field (the values of which are in the same namespace). *** > * > > ** ** > > > I’ll plan to similarly clarify that the semantics of “cty” are > application-specific and the contents of “cty” do not affect the JOSE > processing.**** > > ** ** > > Don’t do that. “cty” is the media type of the content. It is clear that > this is metadata about the content and doesn’t affect JOSE processing (of > this message). Media types are well defined so there is no need to call > them application-specific.**** > > ** ** > > Suggested simplification: Define “cty” as holding the media type of the > content. State that an “application/” prefix may be omitted to save a few > bytes for this common case. To reconstruct the full media type, add a > “application/” prefix if and only if there is no “/” before the first “;” > in the value.**** > > No registry needed.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Mike Jones [mailto:[email protected]] > *Sent:* Thursday, 30 May 2013 5:22 PM > > *To:* Manger, James H; [email protected] > *Subject:* RE: [jose] FW: Should we delete the "typ" header field**** > > ** ** > > I agree, given this thread, that clarified wording is in order along the > lines of that which you suggest. Thanks for writing it. I’ll put doing so > on my to-do list.**** > > ** ** > > The purpose of the “JWS” and “JWE” types is to provide standard > identifiers for applications that may want to use them, either in the “typ” > field or the “cty” field (the values of which are in the same namespace). > I’ll plan to similarly clarify that the semantics of “cty” are > application-specific and the contents of “cty” do not affect the JOSE > processing.**** > > ** ** > > Best wishes,** > ** > > -- Mike**** > > ** ** > > *From:* [email protected] > [mailto:[email protected]<[email protected]>] > *On Behalf Of *Manger, James H > *Sent:* Thursday, May 30, 2013 12:17 AM > *To:* [email protected] > *Subject:* [jose] FW: Should we delete the "typ" header field**** > > ** ** > > > The purpose of “typ” is your 3.**** > > ** ** > > Then why define "typ":"JWS", "typ":"JWS+JSON", "typ":"JWE", and > "typ":"JWE+JSON"?**** > > These values cause confusion as they only make sense for purposes [1] and > [2].**** > > ** ** > > The text describing "typ" says it declares the “type of this object”.**** > > This clearly also causes massive confusion. The object is obviously a JOSE > message; it is also obviously a JWS or JWE; it might also be a JWT, or a > missile launch instruction, or a meeting invitation, or anything. “type” > and “object” are too generic for readers to get the same understanding.*** > * > > ** ** > > At a minimum it should be radically rephrased. Perhaps:**** > > “The "xxx" header parameter can be used to hold an application-specific > string identifying the meaning of a JOSE message to an application. This > parameter has no affect on JOSE processing.”**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Mike Jones > [mailto:[email protected]<[email protected]>] > > *Sent:* Thursday, 30 May 2013 4:45 PM > *To:* Manger, James H; [email protected] > *Subject:* RE: [jose] Should we delete the "typ" header field**** > > ** ** > > The purpose of “typ” is your 3.**** > > ** ** > > There can already be no confusion about 1 because they’re syntactically > completely different. 2 is unnecessary because the “alg” value (or the > existence of “enc”) already distinguishes between JWS and JWE semantics.** > ** > > ** ** > > -- Mike**** > > ** ** > > *From:* [email protected] > [mailto:[email protected]<[email protected]>] > *On Behalf Of *Manger, James H > *Sent:* Wednesday, May 29, 2013 11:08 PM > *To:* [email protected] > *Subject:* Re: [jose] Should we delete the "typ" header field**** > > ** ** > > > Can anybody justify why this field should be present in the document – > or should it just disappear?**** > > ** ** > > It seems there are at least 3 different meanings given to "typ" in the > header of a JOSE message:**** > > ** ** > > [1] The "typ" value indicates the serialization of the JOSE message. For > example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact > (dot-separated-b64-blobs) and JSON serializations.**** > > ** ** > > [2] The "typ" value indicates the high-level semantics of the JOSE > structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the > semantics defined in the separate JWE and JWS specifications.**** > > ** ** > > [3] The "typ" value indicates the application-layer semantics of the > message. For example, "typ":"JWT" value indicates that the message conveys > a set of claims (as a JSON object) wrapped as a JOSE message (either > unprotected, signed, MACed, encrypted, or signed then encrypted) that use > the compact serialization.**** > > ** ** > > Indicating the serialization [1] does not seem helpful as the recipient > needs to know the serialization before they can extract the header to see > the "typ" value. Indicating the serialization is actually harmful as it > tightly couples a message to one serialization, whereas serialization is > generally thought of as a transport-layer choice that is independent of the > message security or semantics.**** > > ** ** > > Indicating the high-level semantics of the JOSE structure [2] is slightly > useful so a message can be switched to different code according to its > structure. It is not that useful, however, as further switching is required > to distinguish different modes (eg unprotected vs asymmetric signature vs > MAC). This meaning only helps if the field is made mandatory, and the > presence/absence of the "enc" field or looking up the class of the "alg" > value are not specified as alternatives.**** > > ** ** > > Being able to indicate application-layer semantics [3] could theoretically > be useful. Perhaps the "profile" attribute or "rel=’profile’" link relation > in HTML5 is analogous. In this case JOSE should not define values for the > field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as > application-layer semantics — and certainly not inside the JOSE message.** > ** > > ** ** > > Most (all?) of the many specs mentioning the "typ" field make it optional, > and if they suggest particular "typ" values those are only “MAY”s or > “SHOULD”s — not “MUST”s. Consequently, apps cannot rely on "typ" regardless > of its meaning.**** > > ** ** > > ** ** > > My suggestions:**** > > ** ** > > * For [1], define two media types to distinguish the two serializations, > not a header field.**** > > ** ** > > * 1st preference for [3], drop it from JOSE specs; let an application > using JOSE (eg JWT) define a field (and value) for this. If the application > defines the field in a generic fashion for reuse by other applications that > is a nice bonus.**** > > ** ** > > * 2nd preference for [3], define a field (but no values) that can hold an > application-layer semantics identifier – but only put this definition in a > spec that defines JOSE messages as a whole (not specs specific to JWE or > JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.* > *** > > ** ** > > * For [2], define a mandatory field that indicates the semantics of the > JOSE structure at a low enough level that a JOSE implementation built on > top of a crypto library could (almost) work without needing to recognize > the "alg" value. "typ" would have been a reasonable name for this field but > is now too polluted with confusion. How about "t"?**** > > Consider for instance a JOSE implementation that only supports > "alg":"HS256". To add support for "alg":"HS3" (HMAC with SHA-3) minimal (if > any) new code is needed in a JOSE layer: perhaps an extra table entry > mapping the JOSE label "HS3" to a crypto library label (eg "HmacSHA3"). > "t":"mac" can accompany both these algs. To support "alg":"RS512", in > contrast, requires calls to different crypto library functions (knowing the > difference between public & private keys for instance). This deserves a > separate value, say, "t":"sig".**** > > ** ** > > --**** > > James Manger**** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
