Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of binary encoding (base64))
Phillip Hallam-Baker <hallam@gmail.com> Fri, 14 June 2013 21:49 UTC
Return-Path: <hallam@gmail.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 6AA4121F99ED for <jose@ietfa.amsl.com>; Fri, 14 Jun 2013 14:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 qOOTS0lcP6w0 for <jose@ietfa.amsl.com>; Fri, 14 Jun 2013 14:49:08 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 688CF21F99FA for <jose@ietf.org>; Fri, 14 Jun 2013 14:49:04 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id e11so929842wgh.30 for <jose@ietf.org>; Fri, 14 Jun 2013 14:48:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=8jPHzF6PrsFIyYTIMM0ECuAw6YQvDvCv20XMaQkka0g=; b=NGqOonEl04C95hDJ+PYwb7VbZiBnr2wmdOJy4q/LR3HE/ybb4/i1z0dHsMTv45TNEV 6qdYrDt59YbBYknN/IA2/iGszK1pVURq4VICELlukl9k5GLrWfEk/M80+T4q9VEg2DHH spNk92NQuxTu2xVXuH+21563ukpabeM6+MhUCSXFGyoB/vDATPuywchiYCR4ZaOZZl1J DahgQlkupj3qQCUewkJH82klMm568lUiUEexAMNgaUO6g7RryoRTs8GM0F4e/Qbj35Eq Iwbmoz/rDL2tU0QtEYw0qLPjzNelquV7F1vhXt65WC2yKUCfDTs27JZdjb2PbAJqZhTB 7WBQ==
X-Received: by 10.194.104.74 with SMTP id gc10mr2553493wjb.48.1371246538793; Fri, 14 Jun 2013 14:48:58 -0700 (PDT)
References: <CAL02cgRLGaSGFqg6PUoz1KX+7jEjU7rwt-t7B=U0FvEqYZrU-w@mail.gmail.com> <C2C21851-DB8D-4B0A-B134-7C0686192270@oracle.com>
In-Reply-To: <C2C21851-DB8D-4B0A-B134-7C0686192270@oracle.com>
Mime-Version: 1.0 (1.0)
From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Fri, 14 Jun 2013 17:48:56 -0400
Message-ID: <7188842785648960750@unknownmsgid>
To: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="047d7bf10b46d82ab304df243683"
Cc: Richard Barnes <rlb@ipv.sx>, Mike Jones <Michael.Jones@microsoft.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, George Fletcher <gffletch@aol.com>, "<jose@ietf.org>" <jose@ietf.org>
Subject: Re: [jose] Deployed Code (was: Re: #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: Fri, 14 Jun 2013 21:49:10 -0000
I think in this case that it is late to bring up binary encoding in Jose But that does not mean we can't add it later. Specs have revisions. All that is needed to support binary is a flag to say what was signed. Defaults to the current scheme. Now if it was a case where binary had been raised at the start of the process and the person got told to shut up because of 'focus' well that would be different. When people pull that trick I have no qualms about repeating my concerns in IETF last call. I think that all too often there is too much haste when starting a WG and people get railroaded into a broken scheme some faction likes. But that did not happen here so I think it is going to be for the binary camp to work out the solution. My bigger Jose concern is the bizarre decision to rename all the crypto alg names. I have a spec that uses mime and JSON. If I take Jose seriously I need a second crypto alg registry. That is junk, that is something that was raised at the start of the process. So yes, I will make it an issue in IETF last call Sent from my difference engine On Jun 13, 2013, at 12:06 PM, Phil Hunt <phil.hunt@oracle.com> wrote: Seems like many these days are in a rush. They call for consensus before discussing the issue. Isn't it up to the chair? This isn't unique to this WG. Too many times the explanation for keeping an apparent 'feature/flaw' is 'because we don't want change'. Yet often the group can't explain it. Or worse, the group just says "we know the emperor has no clothes, we just don't feel the need to comment." This is where alarm bells go off for me. Phil On 2013-06-13, at 7:35, Richard Barnes <rlb@ipv.sx> wrote: This would have been a nice discussion to have had 18 months ago, when we were getting started. I don't think it's compatible with the IETF ethos to say "Changes to this document MUST NOT break existing code." Otherwise, we're not doing engineering here, we're cleaning up documentation and rubber-stamping. What would be acceptable is to say "Changes must break cleanly with existing code". That is, it should be possible for a JWT implementation to, say, process both "legacy" JWS syntax and whatever comes out of this group. That way, we could come to consensus on the best solution, incorporating lessons learned from earlier work without being hindered by them. Would participants here consider it a acceptable for the output of this working group to be incompatible with existing JWT implementations, as long as it had the property that JW* objects in the new format could be clearly distinguished from "legacy" JW* objects, so that implementations could adapt their processing? --Richard On Thu, Jun 13, 2013 at 10:24 AM, George Fletcher <gffletch@aol.com> wrote: > +1 > > Breaking deployed code as raised by Brian, Naveen and others is a critical > consideration. > > Thanks, > George > > On 6/13/13 10:19 AM, Mike Jones wrote: > > Jim and Karen, could you please do as Richard suggests and close this > issue as “won’t fix”.**** > > ** ** > > Thank you,**** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx <rlb@ipv.sx>] > *Sent:* Wednesday, June 12, 2013 1:57 PM > *To:* jose-chairs@tools.ietf.org; Mike Jones > *Subject:* Fwd: [jose] #23: Make crypto independent of binary encoding > (base64)**** > > ** ** > > In other words: Chairs, feel free to close/wontfix :)**** > > ** ** > > ---------- Forwarded message ---------- > From: *Richard Barnes* <rlb@ipv.sx> > Date: Wed, Jun 12, 2013 at 4:55 PM > Subject: Re: [jose] #23: Make crypto independent of binary encoding > (base64) > To: "Matt Miller (mamille2)" <mamille2@cisco.com> > Cc: jose issue tracker <trac+jose@trac.tools.ietf.org>, "< > 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@ietf.org>" <jose@ietf.org> > > **** > > 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 mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose > > > -- > <XeC> <http://connect.me/gffletch> > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Richard Barnes
- [jose] Deployed Code (was: Re: #23: Make crypto i… Richard Barnes
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… George Fletcher
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Justin Richer
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Tim Bray
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Mike Jones
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Carsten Bormann
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Phil Hunt
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Phillip Hallam-Baker
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Mike Jones
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Phillip Hallam-Baker
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Mike Jones
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Phillip Hallam-Baker
- Re: [jose] Deployed Code (was: Re: #23: Make cryp… Richard Barnes