I was able upgrade the lego client in a pretty short patch (5 files changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates with Daniel's branch of pebble.
--Richard [1] https://github.com/bifurcation/lego/pull/1 On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney <c...@letsencrypt.org> wrote: > I think its an anti-pattern to standardize protocol features that haven't > been implemented by anyone so here's a PR[0] for the Pebble ACME server > that implements Richard's proposal[1] to establish viability. The proposal > seems > OK to me given the trade-offs/alternatives on the table. > > I would encourage other ACME client/server developers to try their hand at > implementing the changes from [1] as well. I've tested my PR with > hand-rolled requests but not as part of an automated issuance process with > a "real" ACME client. Speak now or forever hold your bugs. > > [0] - https://github.com/letsencrypt/pebble/pull/162 > [1] - https://github.com/ietf-wg-acme/acme/pull/445/files > > On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes <r...@ipv.sx> wrote: > >> No, if a server receives a GET request for a resource other than those >> specified, then it MUST return 405. But please check out the PR and see if >> it's clear there. >> >> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich <rs...@akamai.com> wrote: >> >>> >>> - * Servers MUST return a 405 if they get a GET for a resource other >>> than directory/newNonce/certificate. >>> >>> >>> >>> They means client? Or there’s a word missing, and “they get a” is “they >>> do not support” >>> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
