maybe one could make it so an email specific to the domain that is verified could be used instead to just screw the entire DNS thing? I mean CAs have used e-Mail based issuance over the address in the whois (no longer practical due to increase of whois privacy by default) or the standardized hostmaster etc addresses. that way any given acme client would only need access to the inbox of that specific mail which probably is a whole lot easier than DNS stuff.
Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser <cont...@emersion.fr>: > > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi <ryan-i...@sleevi.com> > wrote: > > > > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß < > teamhydro55...@gmail.com> wrote: > > > > > > > problem is obviously also the CA/Browser Forum has certain > requirements, > > > > and I guess having access to some kind of direct verification at the > time > > > > of issue might be probably one of these. > > > > > > This is the correct answer. > > > > > > While the IETF can certainly explore developing voluntary standards for > > > other methods, the ability for CAs to adopt these methods is limited > by CAs > > > customers: the browsers and operating systems that include and use CAs > to > > > validate domain names on their behalf. > > > > > > The explicit goal by several browser/OS vendors is to obtain a fresh > proof > > > of control over a domain, and reduce/eliminate any caching or reuse. > > > Delegation (by keys or persistent records) is definitely an area of > > > expressed concern. > > My take is that in theory it's an understandable goal, but that in > practice, > this detoriorates security. > > In practice, ACME clients: > > 1. Have a static, long-term token stored in their configuration file > 2. The token is powerful and can update any DNS record in the zone > > How come browser/OS vendors are fine with this, but not with a different > approach involving an ACME-specific key? > > Sure, since this happens behind the ACME/DNS protocols and is an > implementation > detail, this isn't ACME's responsibility anymore. However, because > browsers/OS > vendors have this requirement of not allowing delegated proofs, we end up > with > a worse situation than necessary. > > Ultimately, ACME clients need a way to update DNS records to solve the > dns-01 > challenge. Ignoring and pushing the problem down to the DNS operators does > not > fix the root cause. > > If an ACME client needs to prove that they have authority over a DNS zone, > they > will need some kind of authorization/key/token or similar, be it > vendor-specific or not. Why not acknowlege this fact and come up with a > reasonable standard? > > > > I think the suggest of more uniform APIs for managing DNS is very much > in > > > line with those goals, and would help far more than ACME. > > Yes, no matter what ACME requires, a standardized API to update DNS records > would be nice. Michael Richardson suggested that such an API (or a subset > of) > already exists (via secure DDNS), but isn't supported by most DNS operators > (even if supported by some DNS daemons). > > Establishing a new standard involves talking to existing DNS operators, > and ask > them to implement the new standard. For them, the new standard wouldn't > have a > high enough return on investment: ACME clients already volunteer to > implement > each and every proprietary API. Even if a good standard ticking the > checkboxes > of RFC 5218 existed, I don't think it would be successful (no "Positive Net > Value" for DNS operators). > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
