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
