Re: [jose] Should we delete the "typ" header field
"Jim Schaad" <ietf@augustcellars.com> Thu, 30 May 2013 14:51 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 4700621F8765 for <jose@ietfa.amsl.com>; Thu, 30 May 2013 07:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X+bTv6ChLATz for <jose@ietfa.amsl.com>; Thu, 30 May 2013 07:51:40 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 65C2921F859A for <jose@ietf.org>; Thu, 30 May 2013 07:51:40 -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 smtp3.pacifier.net (Postfix) with ESMTPSA id C8E8938F2C; Thu, 30 May 2013 07:51:39 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Richard Barnes' <rlb@ipv.sx>, 'Mike Jones' <Michael.Jones@microsoft.com>
References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E1151AD1B9CF@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943677C7C91@TK5EX14MBXC285.redmond.corp.microsoft.com> <CAL02cgSk-SPWz+aKL9TjJK7Vj0hZ0xYiVtYwXOomV7Fyg1V8nw@mail.gmail.com>
In-Reply-To: <CAL02cgSk-SPWz+aKL9TjJK7Vj0hZ0xYiVtYwXOomV7Fyg1V8nw@mail.gmail.com>
Date: Thu, 30 May 2013 07:50:50 -0700
Message-ID: <043e01ce5d45$14383e80$3ca8bb80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_043F_01CE5D0A.67DB3B40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL+gOaQctokYsIF5NqCLBrsp9OxugFUhxlHAZ0OZScCEhVBnZaVasvw
Content-Language: en-us
Cc: "'Manger, James H'" <James.H.Manger@team.telstra.com>, jose@ietf.org
Subject: Re: [jose] Should we delete the "typ" header field
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: Thu, 30 May 2013 14:51:45 -0000
I agree that [1] is incorrect. Given that you could encode the same JSON object either as a JSON object or as a compact serialization (if formed correctly) signing the serialization into the type structure seems very awkward. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, May 30, 2013 7:39 AM To: Mike Jones Cc: Manger, James H; jose@ietf.org Subject: Re: [jose] Should we delete the "typ" header field That is completely backwards. [3] is satisfied by "cty". JWT should be setting "typ"=JWE/JWS, "cty"=JWT-claims. If it's doing otherwise, it's semantically confused and wrong. On James's points: (1) I think we all agree that (1) is not a useful application of "typ". The current docs are wrong to include the "+JSON" forms. (2) My preference would be to keep an explicit indicator. Relying on structure / algorithm IDs is brittle. (3) This is "cty", not a use case for "typ" --Richard On Thu, May 30, 2013 at 2:45 AM, Mike Jones <Michael.Jones@microsoft.com> wrote: 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H Sent: Wednesday, May 29, 2013 11:08 PM To: jose@ietf.org 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 jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
- [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] FW: Should we delete the "typ" header … Richard Barnes
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Manger, James H
- Re: [jose] Should we delete the "typ" header field Mike Jones
- [jose] FW: Should we delete the "typ" header field Manger, James H
- Re: [jose] FW: Should we delete the "typ" header … Mike Jones
- Re: [jose] FW: Should we delete the "typ" header … Manger, James H
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Richer, Justin P.
- Re: [jose] Should we delete the "typ" header field Nat Sakimura
- Re: [jose] Should we delete the "typ" header field John Bradley
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Anthony Nadalin
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Nat Sakimura
- Re: [jose] Should we delete the "typ" header field Brian Campbell
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Nat Sakimura
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] Should we delete the "typ" header field Nat Sakimura
- Re: [jose] Should we delete the "typ" header field Dick Hardt
- Re: [jose] Should we delete the "typ" header field Nat Sakimura
- Re: [jose] Should we delete the "typ" header field Manger, James H
- Re: [jose] Should we delete the "typ" header field Axel.Nennker
- Re: [jose] Should we delete the "typ" header field Jim Schaad
- Re: [jose] Should we delete the "typ" header field Mike Jones
- Re: [jose] Should we delete the "typ" header field Richard Barnes
- Re: [jose] FW: Should we delete the "typ" header … Mike Jones
- Re: [jose] FW: Should we delete the "typ" header … Manger, James H
- Re: [jose] FW: Should we delete the "typ" header … Mike Jones
- Re: [jose] FW: Should we delete the "typ" header … Richard Barnes
- Re: [jose] FW: Should we delete the "typ" header … Mike Jones
- Re: [jose] FW: Should we delete the "typ" header … Jim Schaad
- Re: [jose] FW: Should we delete the "typ" header … Mike Jones
- Re: [jose] FW: Should we delete the "typ" header … Manger, James H