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

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Jun 2013 10:35:58 -0400

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 <[email-masked]> 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:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, June 12, 2013 1:57 PM
> *To:* [email-masked]; 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* <[email-masked]>
> Date: Wed, Jun 12, 2013 at 4:55 PM
> Subject: Re: [jose] #23: Make crypto independent of binary encoding
> (base64)
> To: "Matt Miller (mamille2)" <[email-masked]>
> Cc: jose issue tracker <[email-masked]>, "<
> [email-masked]>" <
> [email-masked]>, "<
> [email-masked]>" <[email-masked]>, "<
> [email-masked]>" <[email-masked]>
>
> ****
>
> 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 <[email-masked]> 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) <
> [email-masked]> 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-masked] >
> Cisco Systems, Inc.****
>
>
> On Jun 11, 2013, at 6:01 PM, jose issue tracker <
> [email-masked]> wrote:
>
> > #23: Make crypto independent of binary encoding (base64)
> >
> >
> > Comment (by [email-masked]):
> >
> > 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-masked]   |       Owner:  draft-ietf-jose-json-web-
> >     Type:  defect       |  [email-masked]
> > 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-masked]
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
>   ** **
>
> ** **
>
>
> _______________________________________________
> jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose
>
>
> --
>  <http://connect.me/gffletch>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 13 Jun 2013 10:42:24 -0400

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.
>
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     +1
>
>     Breaking deployed code as raised by Brian, Naveen and others is a
>     critical consideration.
>
>     Thanks,
>     George
>
>>     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:[email-masked]]
>>     *To:* [email-masked]
>>     <mailto:[email-masked]>; Mike Jones
>>     *Subject:* Fwd: [jose] #23: Make crypto independent of binary
>>     encoding (base64)
>>
>>     In other words: Chairs, feel free to close/wontfix :)
>>
>>     From: *Richard Barnes* <[email-masked] <mailto:[email-masked]>>
>>     Subject: Re: [jose] #23: Make crypto independent of binary
>>     encoding (base64)
>>     To: "Matt Miller (mamille2)" <[email-masked]
>>     <mailto:[email-masked]>>
>>     Cc: jose issue tracker <[email-masked]
>>     <mailto:[email-masked]>>,
>>     "<[email-masked]
>>     <mailto:[email-masked]>>"
>>     <[email-masked]
>>     <mailto:[email-masked]>>,
>>     "<[email-masked]
>>     <mailto:[email-masked]>>"
>>     <[email-masked]
>>     <mailto:[email-masked]>>, "<[email-masked]
>>     <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>>
>>
>>     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 <[email-masked]
>>     <mailto:[email-masked]>> 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)
>>         <[email-masked] <mailto:[email-masked]>> 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
>>         Matt Miller < [email-masked] <mailto:[email-masked]> >
>>         Cisco Systems, Inc.
>>
>>
>>         On Jun 11, 2013, at 6:01 PM, jose issue tracker
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>         > Comment (by [email-masked]
>>         <mailto:[email-masked]>):
>>         >
>>         > of the JWS Header and the JWS Payload to preserve them in
>>         transmission, so
>>         > been shown to work well in practice.  There's no compelling
>>         reason to make
>>         > this change.
>>         >
>>         > Schaad in the e-mail thread.  So this step isn't actually
>>         "extra" at all -
>>         > it could enable the "shifting" problem identified by Jim,
>>         it should not be
>>         > made.
>>         >
>>         > --
>>         >
>>         > Reporter: [email-masked] <mailto:[email-masked]>   |       Owner:
>>          draft-ietf-jose-json-web-
>>         <mailto:[email-masked]>
>>         > Ticket URL:
>>         <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
>>         > [email-masked] <mailto:[email-masked]>
>>         > https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/jose
>
>     -- 
>     George Fletcher <http://connect.me/gffletch>
>
>

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Jun 2013 10:55:13 -0400

+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:
> 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 
> 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
>
>> This would have been a nice discussion to have had 18 months ago, 
>> when we were getting started.
>>
>> best solution, incorporating lessons learned from earlier work 
>> without being hindered by them.
>>
>>>     this issue as "won't fix".
>>>
>>>     Thank you,
>>>
>>>     -- Mike
>>>
>>>         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."
>>>
>>>         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.
>>>
>>>         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
>>>
>>>         > been shown to work well in practice.  There's no
>>>         compelling reason to make
>>>         > this change.
>>>         >

---

From: Tim Bray <[email-masked]>
Date: Thu, 13 Jun 2013 08:00:03 -0700

I'm sympathetic to the frustration about not being allowed to do
engineering.  But this is a movie we’ve seen before; sometimes you have to
deal with the problems of success, where industry likes what you build and
just adopts it, without bothering to wait for the process to complete. In
this situation, the smartest thing to do is to declare victory, freeze the
working version, and ship the RFC.  At this point, based on the track
record, anything that’s presented as a successor to JW* v1.0 is going to
get close and respectful attention from industry.  This is a good position
to be in.

-T

On Thu, Jun 13, 2013 at 7:35 AM, Richard Barnes <[email-masked]> wrote:

> On Thu, Jun 13, 2013 at 10:24 AM, George Fletcher <[email-masked]>wrote:
>
>>  +1
>>
>>                                                             Thank you,***
>> *
>> 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.)****
>>
>> > Schaad in the e-mail thread.  So this step isn't actually "extra" at
>> all -
>> > Ticket URL: <
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Jun 2013 11:03:41 -0400

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 <[email-masked]> 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
>
>
> 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
>
> this document MUST NOT break existing code."  Otherwise, we're not doing
>> issue as “won’t fix”.
>> voice here, and I'm increasingly hearing how alone I am :)
>>
>>
>>
>> On Wed, Jun 12, 2013 at 4:23 PM, Richard Barnes <[email-masked]> wrote:
>>
>>  <impartial-analysis>
>>
>> On the one hand: Breaking every existing JWT implementation in the world
>>
>> if binary-safe encodings become available (CBOR, MsgPack, etc.)
>>
>> </impartial-analysis >
>>
>>
>>
>> <personal-opinion>
>>
>> changing out from under them in incompatible ways."
>>
>>
>>
>> [email-masked]> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jun 2013 15:05:34 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, June 13, 2013 8:04 AM
To: Justin Richer
Cc: Mike Jones; [email-masked]; <[email-masked]>; 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]]
Sent: Wednesday, June 12, 2013 1:57 PM
To: [email-masked]<mailto:[email-masked]>; Mike Jones
Subject: Fwd: [jose] #23: Make crypto independent of binary encoding (base64)

---------- Forwarded message ----------
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[email-masked]<mailto:[email-masked]>>
Cc: jose issue tracker <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> >
Cisco Systems, Inc.

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

> Comment (by [email-masked]<mailto:[email-masked]>):
>
> of the JWS Header and the JWS Payload to preserve them in transmission, so
> been shown to work well in practice.  There's no compelling reason to make
> this change.
>
> Schaad in the e-mail thread.  So this step isn't actually "extra" at all -
> it could enable the "shifting" problem identified by Jim, it should not be
> made.
>
> --
> Reporter:  [email-masked]<mailto:[email-masked]>   |       Owner:  draft-ietf-jose-json-web-
>     Type:  defect       |  [email-masked]<mailto:[email-masked]>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
> [email-masked]<mailto:[email-masked]>

jose mailing list

[email-masked]<mailto:[email-masked]>

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

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

jose mailing list

[email-masked]<mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Jun 2013 17:30:09 +0200

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

Very high level meta-comment:

We don't have any tools in the IETF to find out when these real-world phase changes occur.

The IETF standards process does not recognize them.

That tends to cause confusion because some people think protocol development is clocked by the real world and some insist that the IETF process has not yet completed, so theoretically, we are still wide open to changes.

We seem to have no idea how to handle that lack of synchronization.

Grüße, Carsten

PS.: I feel a bit guilty here, but I hope I'm not.
I have been trying to pick the brains of some people how the JOSE work might been applicable to future CoRE work without carrying the baggage of the JSON format.
In all cases, I have been very explicit that, by starting those thought processes, we should be careful about not creating delays to the current round of standardization.
But the idea is infectious enough that it escaped without the caveat attached.  Sorry about that.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Jun 2013 09:06:04 -0700

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 <[email-masked]> wrote:

>>> Jim and Karen, could you please do as Richard suggests and close this issue as “won’t fix”.
>>> 
>>>  
>>> 
>>>                                                             Thank you,
>>> 
>>>                                                             -- Mike
>>> 
>>>  
>>> 
>>> To: [email-masked]; Mike Jones
>>> From: Richard Barnes <[email-masked]>
>>> Cc: jose issue tracker <[email-masked]>, "<[email-masked]>" <[email-masked]>, "<[email-masked]>" <[email-masked]>, "<[email-masked]>" <[email-masked]>
>>> 
>>> 
>>> On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2) <[email-masked]> wrote:
>>> 
>>> On Jun 11, 2013, at 6:01 PM, jose issue tracker <[email-masked]> wrote:
>>> 
>> <XeC>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Jun 2013 17:48:56 -0400

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 <[email-masked]> wrote:

Seems like many these days are in a rush. They call for consensus before
discussing the issue.

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

--Richard

On Thu, Jun 13, 2013 at 10:24 AM, George Fletcher <[email-masked]> wrote:

> <XeC> <http://connect.me/gffletch>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Jun 2013 21:52:56 +0000

Short names were chosen because of the core compactness requirement for the Compact Serialization.  That was an engineering decision that was consciously made and for which the rationale is clear.

You can disagree with that decision but it has known clear benefits and is far from arbitrary.

                                                                -- Mike

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, June 14, 2013 2:49 PM
To: Phil Hunt
Cc: Richard Barnes; Mike Jones; [email-masked]; <[email-masked]>; George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of binary encoding (base64))

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

On Jun 13, 2013, at 12:06 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Seems like many these days are in a rush. They call for consensus before discussing the issue.

Phil

On 2013-06-13, at 7:35, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
This would have been a nice discussion to have had 18 months ago, when we were getting started.

--Richard

Thanks,
George

                                                            Thank you,
                                                            -- Mike

---------- Forwarded message ----------
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[email-masked]<mailto:[email-masked]>>
Cc: jose issue tracker <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>

<personal-opinion>

--Richard

- m&m

jose mailing list

--
<XeC><http://connect.me/gffletch>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Jun 2013 19:55:57 -0400

So is the idea that a standards organization should seek consistency

I understand the WG rationale. I reject it as a sufficient IETF rationale.
If it stands it is going to require two parallel registries for the same
algs.

I have a spec that crosses HTTP and JSON. Am I supposed to use mime
registry in one and this duplicate scheme in the other?

Blocking that type of move is what IETF last call is for. There is a
negligible benefit in the spec and a huge cost to the community.

Sent from my differenc engine

On Jun 14, 2013, at 5:53 PM, Mike Jones <[email-masked]> wrote:

  Short names were chosen because of the core compactness requirement for
the Compact Serialization.  That was an engineering decision that was
consciously made and for which the rationale is clear.

You can disagree with that decision but it has known clear benefits and is
far from arbitrary.

                                                                -- Mike

*From:* Phillip Hallam-Baker [mailto:[email-masked] <[email-masked]>]
*Sent:* Friday, June 14, 2013 2:49 PM
*To:* Phil Hunt
*Cc:* Richard Barnes; Mike Jones; [email-masked]; <[email-masked]>;
George Fletcher
*Subject:* Re: [jose] Deployed Code (was: Re: #23: Make crypto independent
of binary encoding (base64))

Phil

--Richard

+1

Thanks,
George

                                                            Thank you,

                                                            -- Mike

---------- Forwarded message ----------
From: *Richard Barnes* <[email-masked]>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[email-masked]>
Cc: jose issue tracker <[email-masked]>, "<
[email-masked]>" <
[email-masked]>, "<
[email-masked]>" <[email-masked]>, "<[email-masked]>"
<[email-masked]>

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

 <impartial-analysis>

On the other hand: Eternally binding ourselves to base64 encoding, even if
binary-safe encodings become available (CBOR, MsgPack, etc.)

</impartial-analysis >

<personal-opinion>

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-masked]>
wrote:

- m&m

jose mailing list

[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Jun 2013 23:59:01 +0000

What alternative registry of algorithm names were you thinking of?  Are you suggesting that we use the OID numbers used by CMS?

As far as I know, there is no MIME registry of cryptographic algorithm names, so I don't think there's any conflict/duplication there.

                                                                -- Mike

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, June 14, 2013 4:56 PM
To: Mike Jones
Cc: Phil Hunt; Richard Barnes; [email-masked]; <[email-masked]>; George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of binary encoding (base64))

I understand the WG rationale. I reject it as a sufficient IETF rationale. If it stands it is going to require two parallel registries for the same algs.

I have a spec that crosses HTTP and JSON. Am I supposed to use mime registry in one and this duplicate scheme in the other?

Blocking that type of move is what IETF last call is for. There is a negligible benefit in the spec and a huge cost to the community.

On Jun 14, 2013, at 5:53 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Short names were chosen because of the core compactness requirement for the Compact Serialization.  That was an engineering decision that was consciously made and for which the rationale is clear.

                                                                -- Mike

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, June 14, 2013 2:49 PM
To: Phil Hunt
Cc: Richard Barnes; Mike Jones; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>>; George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of binary encoding (base64))

Phil

--Richard

Thanks,
George

                                                            Thank you,
                                                            -- Mike

---------- Forwarded message ----------
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[email-masked]<mailto:[email-masked]>>
Cc: jose issue tracker <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>

<personal-opinion>

--Richard

- m&m

jose mailing list

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Jun 2013 16:02:12 -0400

The name fields in the following originate from PEM:
http://www.iana.org/assignments/dssc/dssc.xml

The same code points are used in HTTP Digest
http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xml

SSH uses the same code points again and defines HMAC code points:
http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xml#ssh-parameters-18

I don't think that when you are using base64 for encoding you can really
make an issue of the difference between hmac-sha2-256 and hs256 as being
serious enough to justify a whole new registry and a whole different set of
encodings.

The JWA algorithm should instead update the DSSC registry which was
originally conceived as being a single registry and point of contact for
all crypto algorithms and canonical identifiers for all protocols that do
not use protocol specific code points (like IPSEC, DNSSEC).

Setting up registries is easy. Maintaining them is not.

On Fri, Jun 14, 2013 at 7:59 PM, Mike Jones <[email-masked]>wrote:

>  What alternative registry of algorithm names were you thinking of?  Are
> you suggesting that we use the OID numbers used by CMS?****
>
> ** **
>
> As far as I know, there is no MIME registry of cryptographic algorithm
> names, so I don’t think there’s any conflict/duplication there.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Phillip Hallam-Baker [mailto:[email-masked]]
> *Sent:* Friday, June 14, 2013 4:56 PM
> *To:* Mike Jones
> *Cc:* Phil Hunt; Richard Barnes; [email-masked]; <
> [email-masked]>; George Fletcher
>
> *Subject:* Re: [jose] Deployed Code (was: Re: #23: Make crypto
> independent of binary encoding (base64))****
>
>  ** **
>
> So is the idea that a standards organization should seek consistency****
>
> ** **
>
> algs.****
> registry in one and this duplicate scheme in the other?****
>
> ** **
>
> negligible benefit in the spec and a huge cost to the community.****
>
>
>
> Sent from my differenc engine****
>
> ** **
>
>
> On Jun 14, 2013, at 5:53 PM, Mike Jones <[email-masked]>
> wrote:****
>
> consciously made and for which the rationale is clear.****
>
>  ****
>
> far from arbitrary.****
>                                                                 -- Mike***
> *Cc:* Richard Barnes; Mike Jones; [email-masked]; <
> [email-masked]>; George Fletcher
> *Subject:* Re: [jose] Deployed Code (was: Re: #23: Make crypto
> independent of binary encoding (base64))****
>
>  ****
>
> I think in this case that it is late to bring up binary encoding in Jose**
> **
>
>  ****
>
> to the current scheme.****
>
>  ****
>
> 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. ****
>
>  ****
>
> Sent from my difference engine****
>
>  ****
>
>
> On Jun 13, 2013, at 12:06 PM, Phil Hunt <[email-masked]> wrote:****
>
> discussing the issue. ****
>
>  ****
>
> Isn't it up to the chair?****
>
>  ****
>
> This isn't unique to this WG. ****
>
>  ****
>
> Phil****
> On 2013-06-13, at 7:35, Richard Barnes <[email-masked]> wrote:****
>
> we were getting started.****
>
>  ****
>
> engineering here, we're cleaning up documentation and rubber-stamping.****
>
>  ****
>
> them.****
> adapt their processing?****
>
>  ****
>
> --Richard****
>
>  ****
>
>  ****
>
>  ****
>
> On Thu, Jun 13, 2013 at 10:24 AM, George Fletcher <[email-masked]>
> wrote:****
>
> +1
>
> George****
> On 6/13/13 10:19 AM, Mike Jones wrote:****
>
> [email-masked]>" <[email-masked]>****
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> <XeC> <http://connect.me/gffletch>****
>
>  ****
>

-- 
Website: http://hallambaker.com/

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Jun 2013 23:55:13 -0400

I like the idea of being able to use standard names here.  What about doing
like we do with "cty" and "typ", i.e., defining short names that expand to
some full registry value?

On Sat, Jun 15, 2013 at 4:02 PM, Phillip Hallam-Baker <[email-masked]>wrote:

>>                                                                 -- Mike**
>> I understand the WG rationale. I reject it as a sufficient IETF
>> rationale. If it stands it is going to require two parallel registries for
>> the same algs.****
>>
>> ** **
>>
>> You can disagree with that decision but it has known clear benefits and
>> is far from arbitrary.****
>>
>>  ****
>>
>>                                                                 -- Mike**
>> **
>>
>>  ****
>>
>> I think in this case that it is late to bring up binary encoding in Jose*
>> ***
>>
>>  ****
>>
>>  Seems like many these days are in a rush. They call for consensus
>> before discussing the issue. ****
>>
>>  ****
>>