On Mon, Jul 6, 2015 at 11:19 AM, Phillip Hallam-Baker <[email protected]> wrote: > Not sure why you think that, can you elaborate? > > All that is being proposed here is to get rid of the base64 armor which is > unnecessary in http because it is 8-bit clean by definition.
If you look at that draft, it doesn't make JOSE simpler, it makes it wildly more complicated. It doesn't remove the base64 armor -- it adds an *option* to, which has major implications, like changing the signed value. And unfortunately, the "remove the armor because HTTP is clean" option isn't the whole story. If you did something like a Content-Signature header with a detached signature, maybe. But if the whole JWS is in the body, you have to have some framing in order to separate header / payload / signature, and if you want that to be JSON, you're going to have to Base64-encode. > The intention is that this will be part of JOSE as-is. Given that the JOSE formats are already RFCs and therefore immutable, and that there are already pretty mature JOSE libraries, it seems like that ship has sailed. --Richard > > > > > > On Mon, Jul 6, 2015 at 10:35 AM, Richard Barnes <[email protected]> wrote: >> >> Dealing with JOSE nuances is not germane to this WG. >> >> Yes, JOSE has failings -- pretty much all of which were pointed out >> during the JOSE WG process, and dismissed at the time. They are not >> so bad, however, as to render JOSE as-is unusable. Certainly the cure >> described in draft-jones-jose-jws-signing-input-options is much worse >> than the disease. Either let's scrap JOSE and re-design more cleanly, >> or let's just use it with the flaws it has. >> >> >> >> >> On Mon, Jul 6, 2015 at 10:14 AM, Phillip Hallam-Baker >> <[email protected]> wrote: >> > Another point I think should be considered on the agenda is how to use >> > JOSE >> > in the spec. >> > >> > I think it would be a very good idea to adopt the approach Mike Jones >> > and >> > myself have been suggesting of using JOSE without base64 armoring for >> > authenticating requests and responses at the Web Service level. >> > >> > http://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00 >> > >> > >> > I really hope that ACME is not going to be the last JSON based security >> > spec >> > IETF does and I would really like all the specs to end up with something >> > approaching a uniform style. >> > >> > >> > >> > On Tue, Jun 30, 2015 at 4:12 PM, Ted Hardie <[email protected]> wrote: >> >> >> >> Just to bump this up on people's lists, Rich and I will put up a >> >> preliminary agenda next Monday. If you want time for something other >> >> than >> >> draft-barnes-acme, please let us know. >> >> >> >> thanks, >> >> >> >> Ted and Rich >> >> >> >> On Fri, Jun 26, 2015 at 10:54 AM, Ted Hardie <[email protected]> >> >> wrote: >> >>> >> >>> Howdy, >> >>> >> >>> As you've seen from the IESG announcement, ACME has been approved as a >> >>> working group, so our meeting in Prague will be as a working group >> >>> rather >> >>> than a BoF. The IETF agenda is still tentative, but we're currently >> >>> scheduled for Thursday, July 23rd, 15:20-17:20, in Karlin I/II. >> >>> (There is >> >>> still a chance that will change, though, so please do not tailor >> >>> travel to >> >>> just that time frame!) >> >>> >> >>> Our charter lists draft-barnes-acme as a starting point, and Rich and >> >>> I >> >>> are asking the authors to produce an update for the meeting. We >> >>> expect some >> >>> of the working group time in Prague to be a document review/discussion >> >>> of >> >>> that draft. >> >>> >> >>> If you have other agenda items you'd like to request time for, please >> >>> send them to the list. >> >>> >> >>> thanks, >> >>> >> >>> Ted and Rich >> >> >> >> >> >> >> >> _______________________________________________ >> >> Acme mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > >> > >> > _______________________________________________ >> > Acme mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/acme >> > > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
