On Tue, Nov 28, 2017 at 1:19 PM, Daniel McCarney <c...@letsencrypt.org> wrote:
> I filed Issue #356 [1] to track the lost functionality here, and how we >> might want to add it back. > > > From #356: > > " In making that change, we dropped support for certain legacy back-end >> APIs that require a CSR before issuing challenges" > > > Which legacy back-end APIs are you referring to? I recall many weeks ago > you thought a specific commercial CA and a specific certificate re-seller > required CSR in new-order but both confirmed off-list they did not. > > It's frustrating to see continued resistance on the back of constraints > imposed by vague legacy systems without name. Where are the > users/maintainers of these systems to express their concerns at the > perceived "drop of support" to the working group directly? > Dude, it's just a tracking issue, assigned to the Defer milestone. It's not blocking any work here. The canonical example for me here is SSLMate [1], which takes a CSR up front, I'm told because the back-ends it uses require it. Andrew Ayer, who maintains SSLMate, is on this list, and might be able to provide further insight. But like I said, this is not blocking anything for the base spec any more. It's just a possible extension if someone shows up and asks for the feature. --Richard [1] https://sslmate.com/help/api/rest > > - Daniel / cpu > > > On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes <r...@ipv.sx> wrote: > >> I think this is fine to land now. It's not my favorite approach, but >> there's clear consensus. I filed Issue #356 [1] to track the lost >> functionality here, and how we might want to add it back. >> >> https://github.com/ietf-wg-acme/acme/issues/356 >> >> On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <j...@eff.org> >> wrote: >> >>> Hi all, >>> >>> Daniel McCarney's been working on PR#342, which changes the new-order >>> flow to take a list of identifiers instead of a CSR, and to be finalized >>> with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had >>> some back-and-forth on the list about this, versus CSR-first, versus >>> CSR-first-and-last. There was some further discussion at IETF 100 >>> (minutes: >>> https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), >>> and we hummed to accept PR 342 over the alternatives. >>> >>> If there's anyone here who couldn't make it to the meeting and would >>> like to raise strenuous objections, please speak up now, otherwise we'll >>> incorporate that change. >>> >>> Thanks, >>> Jacob >>> >>> _______________________________________________ >>> 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 >> >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
