Hello everyone, please find my responses to all of you so far inline below:
> On 8 Sep 2022, at 19:46, Peter Thomassen <[email protected]> wrote: > > For the sake of arriving at the best solution, I believe it would be best to > consider all potential solutions we can think of and reject all but the one > that seems best. We agree, we have identified this problem some time ago, and we have designed this particular solution, after careful consideration of various parameters. It does not mean it's the only one or the best one, but it's something we believe addresses all requirements and requires the minimum number of changes. We have also implemented this and we've been testing this for the past 2 years. Although ACME is a protocol that can be used by any CA, and is not necessarily tied to WebPKI, our proposal tried to be compatible with the existing Baseline Requirements for Certificate Issuance by the CA / Browser Forum. The method that we are using is 3.2.2.4.7 which requires the presence of a TXT record under a direct subdomain that starts with a "_". If we don't follow these requirements, although DNS-ACCOUNT-01 will be a valid ACME challenge, its adoption by Publicly Trusted CAs will not be possible until a new method is added to the BRs. Moreover, a consideration in designing this challenge was to introduce minimal changes to the existing and well known / understood behavior of the DNS-01 challenge. Considering ACME is a security sensitive protocol, not fundamentally changing the scope of the DNS-01 seemed desirable. > On 8 Sep 2022, at 20:06, Mike Ounsworth <[email protected]> wrote: > > Should that be mentioned in the Security Considerations section? I'm thinking > that you could add to the end of your existing S.C. something like > "Certification Authorities (CAs) MAY, during ACME account creation, check > that the DNS-ACCOUNT-01 prefix is unique in their database …" As this per-account part of the label is not CA-specific, and it is global, a single ACME server cannot keep track of all the possible accounts (including from other servers), but nor does it have to. The probability of a collision is 1 over 2^80, and even in the case where there is one, it only becomes equivalent to DNS-01. The ACME server does not have to take any action, nor does this impact security. Is there some particular concern that you have regarding the security of the challenge if two ACME accounts share the same hash? We believe that it is equivalent to DNS-01 where by definition all accounts share the same label. > On 8 Sep 2022, at 20:06, Mike Ounsworth <[email protected]> wrote: > > Why is this method more amenable to wildcards than existing ones? What are > the policy implications of this, ex. at the CA/B F level? From the existing methods that are available in RFC8555, only DNS-01 can be used for wildcard certificates in WebPKI. The HTTP-01 and TLS-ALPN-01 challenges are not sufficient for that according to the CA/B Forum Baseline Requirements. Therefore, if these certificates are required, the domain controller is now currently forced to use DNS-01 (with the shortcomings mentioned in the original post), or avoid using ACME and fall back to another method such as e-mail or phone verification. > On 9 Sep 2022, at 09:22, Michael Richardson <[email protected]> wrote: > > I'm concerned that it is less easily predicted by the operator, which affects > the ability to easily install the desired CNAME, which seems to be a primary > consideration. Assuming you mean the user of the ACME client when you say "operator". The current proposal bases this off a long-term static value, which is the ACME Account URL. This URL is required by ACME clients already, so we believed that it is something they already have access to. It is assigned by the ACME server and it has control over it already, to enable issuance of certificates. It is true that now the subdomain is different for every ACME account, and you have to calculate it, e.g. if you want to debug something, but we believe that the calculation is trivial and will not cause problems. Perhaps we could even make available an online utility that given an ACME Account URL would produce the correct label. Here's a command that will produce this from shell: printf "https://example.com/acme/acct/ExampleAccount"; | shasum -a 256 | xxd -r -p | head -c 10 | base32 We envision the following way to use DNS-ACCOUNT-01: Assuming you use an authoritative server that is not easy to automate, such as one that serves a zone file from the disk, you generate one or more ACME accounts with your ACME servers (e.g. one per region), and then calculate the subdomains that correspond to these accounts. In this file you add the required CNAME records that point to a DNS server that's easy to automate (e.g. one with an API or a database backend). From now on, every time you have to issue a certificate, you only need to modify the automatable zone, and the non-automatable one remains the same. Therefore we expect this calculation for the subdomain to be done infrequently and remain the same for extended periods of time. Antonis _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
