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

From: "jose issue tracker" <[email-masked]>
Date: Tue, 11 Jun 2013 17:58:20 -0000

#23: Make crypto independent of binary encoding (base64)

 The cryptographic operations that JOSE performs should not depend on the
 transfer encoding used for binary components.  The operations should work
 directly on the encoded byte strings, not on the encoded form.

 This is already true for content, IV, ciphertext, encrypted key, and
 authentication tag.  The only thing that needs fixing is the protected
 header value.  That's a little tricky, since the protected header value is
 JSON, which doesn't have a standard encoding.  But it's not that onerous
 just to convert it to UTF-8 -- in fact, senders are already required to
 convert the protected header to UTF-8.

 So the only change is to require recipients to convert the protected
 header to UTF-8 before using it.   This can be accomplished with two minor
 changes:

 <http://tools.ietf.org/html/draft-ietf-jose-json-web-
 signature-11#section-5.2>
 OLD: "The resulting JWS Protected Header MUST be a completely valid JSON
 object conforming to RFC 4627 [RFC4627]."
 NEW: "The resulting JWS Protected Header MUST be a completely valid JSON
 object conforming to RFC 4627 [RFC4627].  If the JWE Protected Header is
 valid, convert it to the UTF-8 encoding.  Otherwise, reject the JWE."

 <http://tools.ietf.org/html/draft-ietf-jose-json-web-
 encryption-11#section-5.2>
 OLD: "The resulting JWE Protected Header MUST be a completely valid JSON
 object conforming to RFC 4627 [RFC4627]."
 NEW: "The resulting JWE Protected Header MUST be a completely valid JSON
 object conforming to RFC 4627 [RFC4627].  If the JWE Protected Header is
 valid, convert it to the UTF-8 encoding.  Otherwise, reject the JWE."

-- 
-------------------------------------+-------------------------------------
 Reporter:  [email-masked]               |      Owner:  draft-barnes-jose-use-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |     Status:  new
Component:  draft-barnes-jose-use-   |  Milestone:
  cases                              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Tue, 11 Jun 2013 19:50:20 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => draft-ietf-jose-
     [email-masked]
 * component:  draft-barnes-jose-use-cases => json-web-encryption

Comment:

 Update: I missed the fact that (1) JWS signs over the encoded octets, and
 (2) JWS adds an unnecessary "." character to the signed value.  So
 consider this proposal extended to include the following change:

 <http://tools.ietf.org/html/draft-ietf-jose-json-web-
 signature-11#section-5.1>
 OLD: JWS Signing Input  The concatenation of the Encoded JWS Header, a
 period ('.') character, and the Encoded JWS Payload.
 NEW: JWS Signing Input  The concatenation of the JWS Header and the JWS
 Payload.

 This is the same as what CMS does, except in the reverse order.  (In CMS,
 you sign over payload || signedAttrs.)

-- 
-------------------------+-------------------------------------------------
 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:1>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 12 Jun 2013 00:01:41 -0000

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.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
jose <http://tools.ietf.org/jose/>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Jun 2013 20:24:03 -0700

I don't understand what is being suggested. What is the conversion to UTF-8
for?

On Tue, Jun 11, 2013 at 10:58 AM, jose issue tracker <
[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Jun 2013 21:20:46 -0700

I haven’t been following this closely, but someone who uses JWTs (there are
a lot of them out there) asked me “Wouldn’t this break all the existing JWT
libraries and software deployed in production?”  I’m not 100% sure, but it
looks to me like the answer is yes.  Since i observe empirically that JWTs
work very well in production for federated login and many other
applications, and offer a level of security that is acceptable to some of
the most paranoid security organizations in the world, I think this
proposal is not remotely close to being cost-effective.

Forgive me if I’m wrong and this wouldn’t actually break JWTs.  -T

---

From: John Bradley <[email-masked]>
Date: Wed, 12 Jun 2013 08:16:46 +0200

Changing what the integrity is calculated over is about a big breaking change.

I have personally considered alternate encodings for constrained environments (internet of things) however the format we have now has the advantage that it is hard for developers to get wrong, unlike xmldsig.

Jim made a good point that you have to encode the length of the parts or have a separator that cannot appear in the parts. 

I expect that escaping every "." in the JSON is not going to work very well. 

We know what we have works.  It is possible to have long debates over things that won't work.

The integrity has always been calculated this way,  It is not new.

John B.

On 2013-06-12, at 6:20 AM, Tim Bray <[email-masked]> wrote:

> I haven’t been following this closely, but someone who uses JWTs (there are a lot of them out there) asked me “Wouldn’t this break all the existing JWT libraries and software deployed in production?”  I’m not 100% sure, but it looks to me like the answer is yes.  Since i observe empirically that JWTs work very well in production for federated login and many other applications, and offer a level of security that is acceptable to some of the most paranoid security organizations in the world, I think this proposal is not remotely close to being cost-effective.
> 
> On Tue, Jun 11, 2013 at 10:58 AM, jose issue tracker <[email-masked]> wrote:

---

From: Roland Hedberg <[email-masked]>
Date: Wed, 12 Jun 2013 08:41:18 +0200

I'm completely behind John on this.
Also, being one that has a JWT library implementation I can support Tim in that this is a breaking change.
A change that I'm definitely against.

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Jun 2013 09:45:50 -0400

I agree as well -- one of the best things about how the JWS/JWE systems 
work is that they're very simple and deterministic. With *zero* 
normalization (not even space folding), and all operations on a 
well-known encoding that doesn't get parsed and transformed in transit, 
you've got something that's not only easy to develop, it's easy to get 
*right*, and to get right every time.

Adding "a couple dozen lines of code" and breaking every single deployed 
instance isn't going to make things more secure or scalable -- it's 
going to make JOSE be ignored by the developers of the world. We have 
empirical proof that things work well the way that they're currently 
specified, I say cut it, ship it, call it a day.

  -- Justin

On 06/12/2013 02:41 AM, Roland Hedberg wrote:
>>> I haven't been following this closely, but someone who uses JWTs (there are a lot of them out there) asked me "Wouldn't this break all the existing JWT libraries and software deployed in production?"  I'm not 100% sure, but it looks to me like the answer is yes.  Since i observe empirically that JWTs work very well in production for federated login and many other applications, and offer a level of security that is acceptable to some of the most paranoid security organizations in the world, I think this proposal is not remotely close to being cost-effective.
>>>
>>> Forgive me if I'm wrong and this wouldn't actually break JWTs.  -T
>>>
>>>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 12 Jun 2013 14:27:37 +0000

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.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Jun 2013 16:23:37 -0400

<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
>
> > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2
> >

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 12 Jun 2013 13:30:36 -0700

The alternative is not only binding to base64 encoding forever. It is
to introduce canonicalization as well -- signature verification will
fail if JSON deserialization modifies blank spacing data, and you can
be a compliant JSON parser and not be faithful with representation of
line-breaks, for instance. As I understand the proposal, it does not
indicate that the encoding is specifiable, it indicates that signature
computation and verification should be applied to the decoded format.

On Wed, Jun 12, 2013 at 1:23 PM, Richard Barnes <[email-masked]> wrote:
> 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."
>
> On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2)
> <[email-masked]> wrote:
>>
>> > Ticket URL:
>> > <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Jun 2013 20:32:57 +0000

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-masked]]
Sent: Wednesday, June 12, 2013 1:24 PM
To: Matt Miller (mamille2)
Cc: jose issue tracker; <[email-masked]>; Mike Jones; <[email-masked]>
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)

<impartial-analysis>

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.

- 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]>):
>
> Reporter:  [email-masked]<mailto:[email-masked]>   |       Owner:  draft-ietf-jose-json-web-
>     Type:  defect       |  [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Wed, 12 Jun 2013 13:44:29 -0700

> 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

> 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
> On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2) <
> [email-masked]> wrote:
>
>> > Ticket URL: <
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 12 Jun 2013 13:54:24 -0700

+1

On Wed, Jun 12, 2013 at 1:44 PM, Tim Bray <[email-masked]> wrote:

>> On the other hand: Eternally binding ourselves to base64 encoding, even
>> if binary-safe encodings become available (CBOR, MsgPack, etc.)
>>
>
>>> 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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Jun 2013 16:55:59 -0400

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

---

From: Dick Hardt <[email-masked]>
Date: Wed, 12 Jun 2013 14:03:48 -0700

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

---

From: John Bradley <[email-masked]>
Date: Wed, 12 Jun 2013 23:40:39 +0200

Independent of the current implementations.   I prefer the current base64url encoding of the segments, it is harder for people to get wrong.

I have sympathy for the constrained environment people who want BSON (binary JSON).   Having a compact binary representation probably makes sense for those environments where you can safely transmit binary objects.   

I however think that alternate binary encodings are future work and what we have meets the goal of driving adoption.

If size is the issue then you can always compress a jws on the wire and expand it at the other end before validating the signature.

I think changing at this point would be a mistake.

John B.

On 2013-06-12, at 10:23 PM, Richard Barnes <[email-masked]> wrote:

> On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2) <[email-masked]> wrote:

---

From: Naveen Agarwal <[email-masked]>
Date: Wed, 12 Jun 2013 17:53:05 -0700

But I think we're literally talking about something like a 5-line patch.

Unfortunately there are lot of clients apps that are using jwt and
modifying those apps is not going to be easy.
Whether it is a one line or two line change, it doesn't matter. Breaking
change for something that is working well is bad idea (unless it is for
security reason).

Naveen

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jun 2013 23:51:23 -0400

I also prefer to process bit as they appear on the wire.

A binary encoding is going to need different code for the parser/encoder. I
don't see a problem tweaking aspects of JOSE that were bound to the
particular JSON encoding.

While it would be nice in theory to be able to transform between encodings
and have signatures still work, I don't think that is possible except in
the very specific case where all that is being done is base64 encoding
binary blobs.

I don't believe that any canonicalization scheme has proved to be reliable
enough in practice to actually provide the alleged value. There seem to be
more corner cases than anyone imagines possible.

I certainly would not want to break JWT for the sake of an encoding that
JWT is not using.

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 13 Jun 2013 09:37:57 +0200

On Wed, 2013-06-12 at 23:40 +0200, John Bradley wrote:
> Independent of the current implementations.   I prefer the current
> base64url encoding of the segments, it is harder for people to get
> wrong.
> 
> 
> I have sympathy for the constrained environment people who want BSON
> (binary JSON).   Having a compact binary representation probably makes
> sense for those environments where you can safely transmit binary
> objects.   
> 
> 
> I however think that alternate binary encodings are future work and
> what we have meets the goal of driving adoption.
> 
> 
> If size is the issue then you can always compress a jws on the wire
> and expand it at the other end before validating the signature.

If size is an issue on the wire, then chances are that it is also an
issue on the device, so just compressing and expanding may not be a good
solution. Note that in a constrained environment even some of the
processing devices have limited RAM memory and space for (decompression)
libraries and such.

I very much subscribe to your previous statement though: It's future
work (but we shouldn't forget it).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2 
Scheelevägen 17 
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Jun 2013 10:49:53 +0200

Agreed compressing and expanding on constrained devices is not ideal. 

Though I understand people are doing that in some cases to fit in a single packet.  Doing a good job for those environments is however future work and probably requires BSON or some other extension. 

John B. 
Sent from my iPhone

---

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Jun 2013 08:00:58 -0600

Big +1 to Naveen's comment here. It's not about the size of the code change
at all. It's about the impact to widely deployed production code that
cannot be simultaneously updated.

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Jun 2013 14:19:50 +0000

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]; 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]<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:

<personal-opinion>

--Richard

- m&m

---

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

+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]; Mike Jones
> *Subject:* Fwd: [jose] #23: Make crypto independent of binary encoding 
> (base64)
>
> From: *Richard Barnes* <[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]>>
>
> 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 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
>     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
>
>     <[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:
>
>     > Reporter: [email-masked] <mailto:[email-masked]>   |       Owner:
>      draft-ietf-jose-json-web-
>     <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

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

---

From: "jose issue tracker" <[email-masked]>
Date: Mon, 17 Jun 2013 03:09:19 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |       Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |      Status:  closed
Component:  json-web-    |   Milestone:
  encryption             |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:3>
jose <http://tools.ietf.org/jose/>