Independent of the current implementations. I prefer the current base64url encoding of the segments, it is harder for people to get wrong.
I have sympathy for the constrained environment people who want BSON (binary JSON). Having a compact binary representation probably makes sense for those environments where you can safely transmit binary objects. I however think that alternate binary encodings are future work and what we have meets the goal of driving adoption. If size is the issue then you can always compress a jws on the wire and expand it at the other end before validating the signature. I think changing at this point would be a mistake. John B. On 2013-06-12, at 10: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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
