You think there should be a proprietary plug-in for any combination of DNS-provider <-> ACME-client?

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.



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

Reply via email to