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

[Justin Richer <[e-mail]>]

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'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.
>
> 12 jun 2013 kl. 08:16 skrev John Bradley <[e-mail]>:
>
>> 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 <[e-mail]> 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
>>>
>>>
>>> On Tue, Jun 11, 2013 at 10:58 AM, jose issue tracker <[e-mail]> wrote:
>>> #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:  [e-mail]               |      Owner:  draft-barnes-jose-use-
>>>       Type:  defect                   |  [e-mail]
>>>   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/>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose