At 09:40 06/07/2017 Thursday, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >You think there should be a proprietary plug-in for any combination of >DNS-provider <-> ACME-client?
not at all (only mentioned plugin as many acme clients use separately maintained plugins for each/every challenge type (as thats how they roll) obviously monolithic ones such as the LE clients add support for whatever dns-providers they wish themselves but as with all challenge types having an optional (call user provided script X to update dns/http/etc is worthwhile so people can roll their own) >Creating DNS challenges on the fly makes things quite complicated. Another way >to circumvent the whole challenge protocol for DNS would be to let the >ACME-client create a static RSA-key-pair an publish the public key in die >ACME-TXT-record. The ACME-client connects to the CA-server via TLS with it's >private key and the CA-server just checks if the public key in the >_acme-challenge.xxx.xxx TXT-record matches the private key of the TLS >connection. I disagree its no more/less easy http challenge on-the-fly I suspect Im not the only one running my own private and acl'd off from internet, api on my dns master that receives updates, edits the zone and responds when complete (to avoid exposing a public api that may be brute forced) and I run a (3rd party) acme(letsencrypt) client that calls my client-side-script for each challenge (these talk to my private api on the master dns server) all im saying is there are 3 sides to the conversation client <1> acme-server <2> dns/http/other-auth-system <3> client I think acme should only codify the communication on the two sides that the acme-server converses on as client developers can decide to support/neglect as many (or few) auth types and http/dns/other providers as they like >Am 05.07.2017 um 03:08 schrieb Alan Doherty: >>+1 >> >>agreed the acme client design (plugins/modules/supported server architectures >>etc) should really be down to the implementors/designers >> >>as some smaller ones will only talk acme + http-01 + 1 specific server (say >>acme client built into server/device) >> >>others may offer many/all auth mechanisms and server architectures (and dns >>apis) >> >>the WG is realy concerned with the api (and CA server reactions (and >>expectation of responses) >>the myriad clients should handle the third side or the triangle >> >>client <--> acme-ca <----> client selected 3rd party >>client <-----out of scope-> client selected 3rd party >> >>(3rd party as the webserver or dns provider can be entirely separate) >> >>At 15:28 04/07/2017 Tuesday, Daniel McCarney wrote: >>>I agree with the others that have shared the opinion that this is outside of >>>the scope of ACME and this WG. >>> >>>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there >>>is already a protocol for clients to add/update/delete resource records on >>>DNS servers. Most DNS server softwares support RFC 2136 out of the box. We >>>just have to define a protocol to use (-> RFC 2136) in the ACME client. >>> >>> >>>That's exactly right. At least one ACME client (Certbot) has been working on >>>support for RFC 2136 >>>(<https://github.com/certbot/certbot/pull/4701>https://github.com/certbot/certbot/pull/4701) >>> in addition to one-off provider specific DNS APIs. >>> >>>If you need a generic way to update DNS dynamically RFC 2138 is it. If your >>>DNS provider doesn't support RFC 2136 it seems hard to imagine you could >>>convince them to adopt a newly invented ACME DNS update scheme. >>> >>>- cpu >>> >>>On Mon, Jul 3, 2017 at 12:46 PM, Rene 'Renne' Bartsch, B.Sc. Informatics >>><<mailto:[email protected]>[email protected]> wrote: >>> >>> >>>Am 03.07.2017 um 18:28 schrieb Salz, Rich: >>>For a fully automated validation process the ACME-client needs some kind of >>>protocol/interface to add/update/remove the DNS challenge records on the >>>primare DNS server. >>> >>>This is out of scope for our WG, but since we are looking at rechartering, >>>it could be brought within scope. >>> >>>But I think programmatic maintenance of DNS records should probably be done >>>within the DNS groups. >>> >>> >>>In my opinion we shouldn't reinvent the wheel. With RFC 2138 (DynDNS) there >>>is already a protocol for clients to add/update/delete resource records on >>>DNS servers. Most DNS server softwares support RFC 2136 out of the box. We >>>just have to define a protocol to use (-> RFC 2136) in the ACME client. >>> >>> >>>_______________________________________________ >>>Acme mailing list >>><mailto:[email protected]>[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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
