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

[Mike Jones <[e-mail]>]

To be clear, I don't think anyone brought the JOSE specs to the IETF expecting no changes or engineering to occur.  And in fact, there have been thousands of improvements made since individual submission drafts - and in the case of JWE, some of these were breaking changes.  No one was or is trying to circumvent the IETF process.

But what I hear people saying now is that the specs are at a sufficient level of maturity that we should no longer be making breaking changes without a compelling reason to do so and that the industry would be well served by completing the RFCs in a timely fashion.  I agree with that position.

                                                            -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Thursday, June 13, 2013 8:04 AM
To: Justin Richer
Cc: Mike Jones; [e-mail]; <[e-mail]>; George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of binary encoding (base64))

I have no problem with the authors developing the -00 versions of JW* as Informational.  But then the Standards Track documents that this group is developing would be free to break with legacy (cleanly).

This group should have done what OAuth did.  Publish "v1.1" as an Informational, AD-sponsored draft, then work on a Standards Track "v2".  Instead, it seems that some of us have been under the impression we were working on "v2" while others thought "v1.1".  Which, in retrospect, seems to have been the origin of a lot of the angst here.

If we go back and publish a cleaned up version of -00 as "v1.1", would anyone here stick around to work on "v2.0"?  I would.


On Thu, Jun 13, 2013 at 10:55 AM, Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
+1 to George's suggestion. We know that what we have today will function, and if this WG doesn't finish its job then the reality is that everyone doing "legacy" JWS isn't much going to care what the JOSE WG says anymore. In other words, there's enough momentum behind the current state of JOSE that it would cause a serious fork if we were to change things now.

So let's be smart about the fork. Let's push what we have as "JOSE", then "JOSE2" can turn it into the multi-encoded-binary-framework that fits other use cases. And it'll be JOSE2's job to come up with reasonable backwards compatibility or incompatibility rules and functions. If we do this, which is what George is saying, then we can actually have some control over both compliance to the "current" specs and compliance to the "new" as-of-yet-undefined specs, and we stand a chance of people outside of this working group actually paying attention to what the working group is saying, both with the current and with the new.

And finally, as the proverb says, "don't let the perfect stand in the way of the good."

 -- Justin

On 06/13/2013 10:42 AM, George Fletcher wrote:
I think that in the current situation the issue isn't just breaking deployed code but also the timeliness of completing the spec. If the desire is to change the processing at some point in the future, why not complete this set of specs and then look to add the backward compatibility/migration strategy to an updated/future version of the specification? That's effectively what this would be anyway, and allowing other specifications and working code to be compliant with the current specification is very valuable and doesn't preclude revising the mechanism in the future.

Thanks,
George
On 6/13/13 10:35 AM, Richard Barnes 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: Wednesday, June 12, 2013 1:57 PM
To: [e-mail]<mailto:[e-mail]>; 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 <[e-mail]<mailto:[e-mail]>>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[e-mail]<mailto:[e-mail]>>
Cc: jose issue tracker <[e-mail]<mailto:[e-mail]>>, "<[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>>, "<[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>>, "<[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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 < [e-mail]<mailto:[e-mail]> >
Cisco Systems, Inc.

On Jun 11, 2013, at 6:01 PM, jose issue tracker <[e-mail]<mailto:[e-mail]>> wrote:

> #23: Make crypto independent of binary encoding (base64)
>
>
> Comment (by [e-mail]<mailto:[e-mail]>):
>
> 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:  [e-mail]<mailto:[e-mail]>   |       Owner:  draft-ietf-jose-json-web-
>     Type:  defect       |  [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jose





_______________________________________________

jose mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/jose

--
[George Fletcher]<http://connect.me/gffletch>


--
[George              Fletcher]<http://connect.me/gffletch>


_______________________________________________

jose mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/jose