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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
