> > 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.
SSLMate/Andrew are the reseller I recall confirming could accommodate #342 without needing a CSR in new-order. I hope Andrew can clarify if I'm remembering incorrectly. On Tue, Nov 28, 2017 at 1:23 PM, Richard Barnes <r...@ipv.sx> wrote: > > > 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
