Bringing a question from the bottom to top: Aaron, do you think that CAs that accept dns-persist would want to issue those certificates from a different subordinate CA? Because the trust relationship freshness is different?
Aaron Gable <[email protected]> wrote: > 2. The DNS-based (dns-01 and dns-account-01) challenges have operational > difficulties: DNS propagation can be slow, and many webmasters > (appropriately) don't want to have DNS API keys on the same host as their > ACME client (which is often on the same host as their webserver). And, operationally, with bind9, at least, it's hard to mix dynamic update zones with ones you maintain with vi. The configuration of *nsupdate* itself is tedious. (like: trailing dots matter in the key name..)... I wonder if there are clients that do better integration. Maybe there is a certbot plugin I've missed; I have a shell script. I've also written dynamic DNS update client code for dns-01 in an EST RA. The propogation issue is probably the most annoying: having your client attempt to make sure that all distribution primaries have updated is definitely a problem. So, the CNAME hack to move challenges to a (sub)zone for which it's less of a concern seems like a good BCP. > So even regardless of the approach taken here, I think this problem space > is worth tackling. I agree that we should make it easier, I'm less convinced that dns-persist is the solution. I'd be happy to adopt this document, but I might suggest we adopt a document about challenges as a requirement document. > But beyond that, I think that this *solution* space is quite interesting, > and worth discussing as a Working Group. The key insight is that, because > ACME accounts are tightly bound to keypairs, ACME account URLs can be > durable and cryptographically-bound stand-ins for random tokens. Both this > method and the existing dns-01 show the same thing: the DNS operator > approves of the operator of a specific ACME account. If I understood your description here, dns-persist is essentially using a DNS-01-like mechanism to authorize the account. I hadn't quite understood it that way. I did ask about what happens when a dns-persist zone has "member" (servers) within it that do http-01 or dns-01. > Of course, there's one hiccup: they actually only show *almost* the same > thing. The dns-01 method shows that the DNS operator approves of the > operator of a given ACME account (the one to which the random token was > sent) *right now*. The proposed dns-persist-01 only demonstrates that the > DNS operator approved of the ACME account *at some point in the past*. Agreed. I can't recall in the pre-ACME days if the proprietary random nonce in apex zone approved once, or if it persisted in my account. I think that email to [email protected] was my more common tool. Way easier than editing DNS zones. I wonder if Google's sitemaster tools (which also do nonce in zone), could consider dns-persist-01 :-) > But while I think that distinction is critical and worth discussing > extensively, I don't think it is disqualifying. In particular, I think that > the tradeoff here -- less proof-of-freshness in return for massive > operational simplification -- will result in large uptake of this > validation method and a large improvement to the security and privacy of > the web overall. The other thing is that we need more/better mechanisms to deploy non-HTTPS certificates. Particularly if having other EKUs is important, or if having web-server EKU present is a wrong. SMTP, XMPP, RADIUS, EAP-TLS come to mind. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
