*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 protected]> 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 :) > > > On Wed, Jun 12, 2013 at 4:23 PM, Richard Barnes <[email protected]> wrote: > >> <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 protected]> 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 protected] > >>> Cisco Systems, Inc. >>> >>> On Jun 11, 2013, at 6:01 PM, jose issue tracker < >>> [email protected]> wrote: >>> >>> > #23: Make crypto independent of binary encoding (base64) >>> > >>> > >>> > Comment (by [email protected]): >>> > >>> > 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. >>> > >>> > -- >>> > >>> -------------------------+------------------------------------------------- >>> > Reporter: [email protected] | Owner: draft-ietf-jose-json-web- >>> > Type: defect | [email protected] >>> > 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:2> >>> > 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
