Re: [jose] #23: Make crypto independent of binary encoding (base64)

Dick Hardt <dick.hardt@gmail.com> Wed, 12 June 2013 21:04 UTC

Return-Path: <dick.hardt@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 9340321F8895 for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 14:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.590, 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 PXsb5Ii26Ty0 for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 14:04:12 -0700 (PDT)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A7FE621E8097 for <jose@ietf.org>; Wed, 12 Jun 2013 14:04:09 -0700 (PDT)
Received: by mail-bk0-f48.google.com with SMTP id jf17so4862501bkc.35 for <jose@ietf.org>; Wed, 12 Jun 2013 14:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=isW+PDwYyaeIoKh2KhSzKFqzOa2r3pvjOUIbeP7zRW8=; b=r3IXrZyL5NCBqUFcHunn+ituKuPpVpNS3y2RaZB4GJRgv19S0VL7NzFvFYOe1N0heQ EwB7DeORJJwtBZJgMr7A8HsVZsDqlKwdhIl74PdQsqUNTUACJGn0qkzCvHwS5QMEXtWt emD6PBtadVrZKbk2KEJ2HCGYoIXpQ5i09+IAhrgg1NmfRXaox5E25TYk5oqdx+Cot6lx eoLXmAOGLV0foFdFA+aja2oxg6sfSj/xSxWdHQEcm84Onc7oi/83N+A/t0hsxBn7IJN4 ppxQTZGnpepXspOn4kuNCFTVUmtEHIUw60Y70Qoaojou49bFruCyw/uaD7APaceRQLFY 76tA==
X-Received: by 10.204.70.203 with SMTP id e11mr3507096bkj.16.1371071048654; Wed, 12 Jun 2013 14:04:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.168.12 with HTTP; Wed, 12 Jun 2013 14:03:48 -0700 (PDT)
In-Reply-To: <CAL02cgQ+K=dWnhSa7A4w85psuxOuuf9m09uyChcOZPe17BCizQ@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> <CAL02cgQ+K=dWnhSa7A4w85psuxOuuf9m09uyChcOZPe17BCizQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 12 Jun 2013 14:03:48 -0700
Message-ID: <CAD9ie-shVqHGqTt3g0Z7dZVrunQsOF=CJZ+w_etVV_BA9Em2Xg@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="047d7b87450ed152c804defb5aa4"
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>, "Matt Miller (mamille2)" <mamille2@cisco.com>
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 21:04:14 -0000

*if* a binary safe representation of JSON becomes popular, then a related
signing specification can be created that deals with the use cases where
this is important

IMHO: The current spec deals with all the real world problems implementors
are wanting to solve or thinking of solving.


On Wed, Jun 12, 2013 at 1:55 PM, Richard Barnes <rlb@ipv.sx> wrote:

> 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 list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>