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 <[email protected]>:
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 protected]> 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
<[email protected]> 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: [email protected] | Owner: draft-barnes-jose-use-
Type: defect | [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
