i think its because acme is designed to be interactive/interrogative proof of control
as opposed to proof the acme client had control at some point in the past (but no guarantee its still the case) At 09:55 12/09/2018 Wednesday, Tobias Erichsen wrote: >Content-Language: de-DE >Content-Type: multipart/alternative; > boundary="_000_21603AF28BEB014F89BED60814E8E14E3F1CE82Aexchange2010wob_" > >Hello everyone, > >there have been various feature proposals on the Lets Encrypt community forum >and also at least one here on this mailing-list >(<https://www.ietf.org/mail-archive/web/acme/current/msg00641.html>https://www.ietf.org/mail-archive/web/acme/current/msg00641.html) > to implement a version of the dns challenge that is >less complex than the current solution where a generic client needs to >implement a large amount of different APIs to cover >all the DNS-providers in the wild, some of which dont even provide >automatable APIs > >Im really curious to learn about the reasons why those proposals have been >ignored. Perhaps I overlocked some explanation, >but I did not discover any yet > >One defined TXT-Record for each ACME-provider like Lets encrypt for example >which contain the SHA-512 hash of the publid key, >or the hash of the account-name should really suffice to prove the >domain-control when trying to renew certificates During >the ACME renewal, a cryptographic exchange of a token should prove the control >over ACME public/private. > >Is there anything I have overlooked which would be a reason to block the >introduction of such dns-02 challenge? > >Best regards, >Tobias > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
