> On Jan 22, 2018, at 7:09 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > > In a way, fetching final TXT record would be a formality: the CA could in > theory > stop once it saw the CNAME pointed at the right location, though most > likely abiding by the terms of the BRs would require following the > formal lookup steps. >
In the scheme you propose here, the optics of the situation may be a concern. The fact that the lookup is a formality because the CA directly altered the the records opens the door for objections and ballots to revise the “work around”. Why not operate the special limited DNS infrastructure in a way that even a non-CA party could theoretically own/manage that infrastructure in a manner that doesn’t require the CA itself to trust the third party? Have the target CNAME zones assigned at random and bound to an account key or similar, standardize an API for requests for new CNAME target labels to be assigned for use and for updates to be executed by the ACME client directly. In other words, don’t have the CA modify the target CNAME label’s TXT records — let the ACME client do it. Provide an API which lets any ACME client user apply for a new random target CNAME label, perhaps in an account-id hierarchy, bound to a cryptographic key for updates/adds of TXT records in that zone or on that label and then you can run it or any other party trusted by the ACME client who makes the delegation to the remote label can be chosen. The fetching by the CA validation logic in this case is no longer a formality nor is it any kind of stacked-deck farce and it is no longer strictly necessary that the dynamic limited DNS provider even be the CA. (Albeit the dynamic limited DNS provider DOES need to be a trustworthy party AND a party trusted by the subscriber.) Technologically, the merits of my proposed change are limited. In terms of the optics, this opens the door to real separation from the CA as well as has the client demonstrating something more akin to material control of the target dynamic zone, reducing arguments that the mechanism is an end-run of any kind. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
