Re: [jose] FW: Should we delete the "typ" header field

[Richard Barnes <[e-mail]>]

I think James's point is that there's no point to using "typ": "JOSE".  If
you've already parsed the object far enough to read that field, you know
it's a JOSE object.  So we should just remove that value.

--Richard


On Sun, Jul 14, 2013 at 4:09 PM, Mike Jones <[e-mail]>wrote:

>  It can be application-specific if the application chooses to use that
> value.  I will plan change the sentence in question by adding the words “by
> applications” as below to eliminate the potential ambiguity that you
> identified:****
>
>    The type value *"JOSE" MAY be* used by applications****
>
>    to indicate that this object is a *JWS or* JWE using the *JWS Compact*
>
> *   Serialization or the* JWE Compact Serialization.****
>
> ** **
>
> As for the choice of the names “JOSE” and “JOSE+JSON”, those reflect the
> decision on the last call to change from the type-specific MIME types
> application/jws, application/jwe, application/jws+json, and
> application/jwe+json to the more inclusive names application/jose and
> application/jose+json.  Both the MIME types exist because the
> serializations use different representations, and so their content types
> need to be different.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Manger, James H [mailto:[e-mail]]
> *Sent:* Saturday, July 13, 2013 6:41 AM
> *To:* Mike Jones; [e-mail]
>
> *Subject:* RE: [jose] FW: Should we delete the "typ" header field****
>
>  ** **
>
> Mike,****
>
> ** **
>
> The “typ” changes (below) make no sense.****
>
> The first sentence is marginally clearer that “typ” is some sort of label
> for a higher-layer (above JOSE processing), eg values are
> application-specific. But the very next sentence suggests “JOSE” as a
> value! Argh!! How can that be “application-specific”? It is the definition
> of not application-specific. Defining “JOSE+JSON” in the next sentence is
> even worse. That makes It seem that “typ” is indicating the serialization,
> which everyone (including yourself) have agreed is wrong.****
>
> ** **
>
> ** **
>
> -- from
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-jose-json-web-encryption-12.txt
> ****
>
> ** **
>
> *4.1.10.*  "typ" (Type) Header Parameter****
>
> ** **
>
>    The "typ" (type) header parameter is *MAY be* used to declare the type
> of****
>
>    this****
>
>    object. *complete JWE object in an application-specific manner in*
>
> *   contexts where this is useful to the application.  This parameter has*
>
> *   no effect upon the JWE processing.*  The type value "JWE" is *"JOSE"
> MAY be* used****
>
>    to indicate that this object is a *JWS or* JWE using the *JWS Compact*
>
> *   Serialization or the* JWE Compact Serialization.  The type value
> "JWE+JSON"****
>
>    is****
>
>    *"JOSE+JSON" MAY be* used to indicate that this object is a *JWS or*JWE
> ****
>
>    using the *JWS JSON Serialization or the* JWE JSON Serialization.****
>
>    Other type values MAY be used, and if not understood, SHOULD be****
>
>    ignored.  The "typ" value is a case sensitive string.  Use of this****
>
>    header parameter is OPTIONAL.****
>
> ** **
>
>    MIME Media Type [RFC2046] values MAY be used as "typ" values.****
>
> ** **
>
>    "typ" values SHOULD either be registered in the IANA JSON Web****
>
>    Signature and Encryption Type Values registry [JWS] or be a value****
>
>    that contains a Collision Resistant Namespace.****
>
> ** **
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* Mike Jones [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Saturday, 13 July 2013 1:32 AM
> *To:* Manger, James H; [e-mail]
> *Subject:* RE: [jose] FW: Should we delete the "typ" header field****
>
> ** **
>
> I’ve applied the proposed changes in the -12 drafts.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Mike Jones
> *Sent:* Thursday, May 30, 2013 12:22 AM
> *To:* 'Manger, James H'; [e-mail]
> *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:* [e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *Manger, James H
> *Sent:* Thursday, May 30, 2013 12:17 AM
> *To:* [e-mail]
> *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:[e-mail]<[e-mail]>]
>
> *Sent:* Thursday, 30 May 2013 4:45 PM
> *To:* Manger, James H; [e-mail]
> *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:* [e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *Manger, James H
> *Sent:* Wednesday, May 29, 2013 11:08 PM
> *To:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>