We shouldn't be basing decisions now on speculative binary encoding that may or
may not ever come into existence or gain any traction. We're explicitly
building solutions that are intended to be easily usable with JSON as it exists
today, for deployment today and into the future.
As Justin pointed out, there's an existence proof that JWS is simple enough
that developers get it right. That's actually very important, and not
something that we should dismiss lightly.
If later a binary encoding has come into existence and gained traction, we
could decide to recharter and do more work, if necessary. But I'm not holding
my breath on the precondition to that "if". Besides, if people are fine with
binary encodings, we already have CMS.
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Wednesday, June 12, 2013 1:24 PM
To: Matt Miller (mamille2)
Cc: jose issue tracker; <[email protected]>;
Mike Jones; <[email protected]>
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
<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)
<[email protected]<mailto:[email protected]>> 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 < [email protected]<mailto:[email protected]> >
Cisco Systems, Inc.
On Jun 11, 2013, at 6:01 PM, jose issue tracker
<[email protected]<mailto:trac%[email protected]>> wrote:
> #23: Make crypto independent of binary encoding (base64)
>
>
> Comment (by [email protected]<mailto:[email protected]>):
>
> 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: [email protected]<mailto:[email protected]> | Owner:
> draft-ietf-jose-json-web-
> Type: defect |
> [email protected]<mailto:[email protected]>
> 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
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
