Re: [jose] #23: Make crypto independent of binary encoding (base64)
Richard Barnes <rlb@ipv.sx> Wed, 12 June 2013 20:56 UTC
Return-Path: <rlb@ipv.sx>
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 9A5CD11E810C for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 13:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.337
X-Spam-Level:
X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 25x45yRQdCs6 for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 13:56:02 -0700 (PDT)
Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1111E8108 for <jose@ietf.org>; Wed, 12 Jun 2013 13:56:00 -0700 (PDT)
Received: by mail-oa0-f52.google.com with SMTP id g12so4959768oah.39 for <jose@ietf.org>; Wed, 12 Jun 2013 13:56:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=d/IWNCGUFembJw7a+g1cN9EMdqmjRWc07J9PLt9tdXw=; b=Yl3/Ziith4qazIzSAM9pUyovdnKNLoKduTWTj9e2OItVZymSjSKOfOy2zLAB8FBHph hZaYMSQkaM2W0lySKe4ewoftkGeMG5Gpxkf0WlIBqn61J05eiQzXZq7d2ZVZY7m1Nk89 s8yiLh5fKj0xtS3zdgi4s2rZx2CYRGB/1VPmw3qkWoRK3AQcjM5RwrDn8u79AaMZpvJQ d5KkWKvfIbWz5CUz+dP8899cndEXQto/CqcR1c7Ay7o0kX12VWI78ywyTnumpBgkNlyM CoYbWz1/WLidtMml4sTJbxhpkXVQUKvkPcakTg0w7cuRszmd6bci67IM8yZQGRHv4q2T v1Kw==
MIME-Version: 1.0
X-Received: by 10.60.42.237 with SMTP id r13mr17054296oel.61.1371070559816; Wed, 12 Jun 2013 13:55:59 -0700 (PDT)
Received: by 10.60.84.8 with HTTP; Wed, 12 Jun 2013 13:55:59 -0700 (PDT)
X-Originating-IP: [192.1.51.101]
In-Reply-To: <CAL02cgSpYtAVVNe7AOiNhnBUqP-=CWaXw7NH2XwUu6eXgfZJ+w@mail.gmail.com>
References: <049.69ffc5ebf959c6eac7990651822fadf9@trac.tools.ietf.org> <064.e396e921644745f7bd339ad363a7d7f7@trac.tools.ietf.org> <BF7E36B9C495A6468E8EC573603ED94115283F43@xmb-aln-x11.cisco.com> <CAL02cgSpYtAVVNe7AOiNhnBUqP-=CWaXw7NH2XwUu6eXgfZJ+w@mail.gmail.com>
Date: Wed, 12 Jun 2013 16:55:59 -0400
Message-ID: <CAL02cgQ+K=dWnhSa7A4w85psuxOuuf9m09uyChcOZPe17BCizQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c206aaae208904defb3d9f"
X-Gm-Message-State: ALoCoQlC3qkQqfv6lcReLXxDCP/Tucpk5oq/9khZKL2VL8iaJph04/IFKthyhrDCg4SRWnJ2FjDG
Cc: "<draft-ietf-jose-json-web-encryption@tools.ietf.org>" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "<michael.jones@microsoft.com>" <michael.jones@microsoft.com>, jose issue tracker <trac+jose@trac.tools.ietf.org>, "<jose@ietf.org>" <jose@ietf.org>
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
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, 12 Jun 2013 20:56:10 -0000
To be clear, I structured my message in two parts for a reason, to separate the analysis from the opinion. I acknowledge that I am but one voice here, and I'm increasingly hearing how alone I am :) On Wed, Jun 12, 2013 at 4:23 PM, Richard Barnes <rlb@ipv.sx> wrote: > <impartial-analysis> > So just to be clear on the trade-off the WG has to make: > > On the one hand: Breaking every existing JWT implementation in the world > On the other hand: Eternally binding ourselves to base64 encoding, even if > binary-safe encodings become available (CBOR, MsgPack, etc.) > </impartial-analysis > > > <personal-opinion> > I have some sympathy with JWT implementors. It sucks to have to refactor > code. But I think we're literally talking about something like a 5-line > patch. And early JWT implementors knew or should have known (to use a DC > phrase) that they were dealing with a draft spec. As the W3C editor's > draft template says, in big bold red print, "Implementors who are not > taking part in the discussions are likely to find the specification > changing out from under them in incompatible ways." > > As PHB pointed out in the other thread, it would be nice to use JWS and > JWE in place of CMS one day, without the base64 hit. We should incur the > implementation pain now, and get the design right for the long run. Base64 > is a hack around JSON; we should build the system so that when we no longer > need that hack, it can go away. > </personal-opinion> > > --Richard > > > > > On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2) < > mamille2@cisco.com> wrote: > >> I did at first find it curious why the cryptographic operations were over >> the base64url-enccoded values, but I was also very focused on JWE, where I >> think the field separation problem is less of an issue (at least now). For >> JWS, this would certainly cause problems without some manner of unambiguous >> field parameterization. >> >> I will note that unescaped NULL is not valid in JSON, so it could be used >> as a separator between the encoded header and the payload. I do find it >> interesting if JOSE could more easily and efficiently support other >> encodings. However, I think that while this is an interesting thought >> experiment, it seems we're too far down the path to seriously consider it >> unless the current state were shown to be horribly broken. >> >> >> - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >> On Jun 11, 2013, at 6:01 PM, jose issue tracker < >> trac+jose@trac.tools.ietf.org> wrote: >> >> > #23: Make crypto independent of binary encoding (base64) >> > >> > >> > Comment (by michael.jones@microsoft.com): >> > >> > For both serializations, you already need the base64url encoded versions >> > of the JWS Header and the JWS Payload to preserve them in transmission, >> so >> > computing them isn't an extra burden. In the JWS Compact Serialization, >> > you already need the concatenation of the Encoded JWS Header, a period >> > character, and the Encoded JWS Payload, so computing that concatenation >> > isn't an extra burden. Given you already have that quantity, computing >> > the signature over it is the easiest thing for developers to do, and >> it's >> > been shown to work well in practice. There's no compelling reason to >> make >> > this change. >> > >> > Even for the JSON Serialization, the only "extra" step that's required >> to >> > compute the signature is the concatenation with the period character - >> to >> > prevent shifting of data from one field to the other, as described by >> Jim >> > Schaad in the e-mail thread. So this step isn't actually "extra" at >> all - >> > it's necessary. It's also highly advantageous to use exactly the same >> > computation for both serializations, which is currently the case. >> > >> > Since there is no compelling reason to make this change, and since >> making >> > it could enable the "shifting" problem identified by Jim, it should not >> be >> > made. >> > >> > -- >> > >> -------------------------+------------------------------------------------- >> > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- >> > Type: defect | encryption@tools.ietf.org >> > Priority: major | Status: new >> > Component: json-web- | Milestone: >> > encryption | Version: >> > Severity: - | Resolution: >> > Keywords: | >> > >> -------------------------+------------------------------------------------- >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2> >> > jose <http://tools.ietf.org/jose/> >> > >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> >> >
- [jose] #23: Make crypto independent of binary enc… jose issue tracker
- Re: [jose] #23: Make crypto independent of binary… jose issue tracker
- Re: [jose] #23: Make crypto independent of binary… jose issue tracker
- Re: [jose] #23: Make crypto independent of binary… Dick Hardt
- Re: [jose] #23: Make crypto independent of binary… Tim Bray
- Re: [jose] #23: Make crypto independent of binary… John Bradley
- Re: [jose] #23: Make crypto independent of binary… Roland Hedberg
- Re: [jose] #23: Make crypto independent of binary… Justin Richer
- Re: [jose] #23: Make crypto independent of binary… Matt Miller (mamille2)
- Re: [jose] #23: Make crypto independent of binary… Richard Barnes
- Re: [jose] #23: Make crypto independent of binary… Breno de Medeiros
- Re: [jose] #23: Make crypto independent of binary… Mike Jones
- Re: [jose] #23: Make crypto independent of binary… Tim Bray
- Re: [jose] #23: Make crypto independent of binary… Dick Hardt
- Re: [jose] #23: Make crypto independent of binary… Richard Barnes
- Re: [jose] #23: Make crypto independent of binary… Dick Hardt
- Re: [jose] #23: Make crypto independent of binary… John Bradley
- Re: [jose] #23: Make crypto independent of binary… Naveen Agarwal
- Re: [jose] #23: Make crypto independent of binary… Phillip Hallam-Baker
- Re: [jose] #23: Make crypto independent of binary… Ludwig Seitz
- Re: [jose] #23: Make crypto independent of binary… John Bradley
- Re: [jose] #23: Make crypto independent of binary… Brian Campbell
- Re: [jose] #23: Make crypto independent of binary… Mike Jones
- Re: [jose] #23: Make crypto independent of binary… George Fletcher
- Re: [jose] #23: Make crypto independent of binary… jose issue tracker