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 >
smime.p7s
Description: smime.p7s
> _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose -- Roland "Education is the path from cocky ignorance to miserable uncertainty. - Mark Twain
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
