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

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

> 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.)
>

JWT stands for JSON Web Token. JSON is JSON, not some binary encoding, and
base64 makes it Web-safe at acceptable cost. It meets the stated needs, is
widely implemented, and works.  If at some future time there’s an
interesting binary packaging format X, invent XWT which does a good job for
X.  This is a fishing expedition.

Speaking on behalf of the many who are already using JWT with excellent
results, could the WG please ship this highly successful product?

 -T

>
> <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
>
>