*Hello Everyone,* Over the past few months, I’ve become increasingly interested in the ACME ecosystem.
One technology I find particularly fascinating is ACME CAA records, which I believe are significantly underutilized. Specifically, the account binding feature has great potential to enhance security. However, one of the main challenges is that setting up these records can be complex and often requires manual effort. To address this issue, I propose a delegation mechanism that could simplify the process. In the current state, it’s already possible to automate the setup of CAA records. For example, the process could work as follows: 1. A reverse proxy requesting certificates from a provider like Let's Encrypt first creates an account using the ACME API. 2. It then adds the corresponding ACME CAA record with the newly created account included in the account binding tag. 3. After verifying DNS propagation, the reverse proxy proceeds with certificate issuance as usual. However, there is a challenge with this approach: the reverse proxy or ACME client requires direct access to modify the DNS records of the domain. This situation is similar to the one encountered when using DNS-01 validation for certificates. In that case, the ACME client only needs access to the _acme_challenge subdomain, allowing for improved security through tools like acme-dns or by using more restrictive DNS API permissions. Applying a similar delegation mechanism for CAA records could strike a balance between security and usability. By limiting the required DNS access and incorporating such tools, the process would become both safer and more practical. While sharing this idea on the Let's Encrypt forums, I learned that the CA Baseline Requirements mandate CAA validation according to RFC 8659. This adds significant complexity to implementing such a concept for the issue and issuewild functionalities. Despite the challenges, I still believe this approach could be highly beneficial for account binding and validation methods. For example, an implementation might look like this: example.com. IN CAA 0 issue "letsencrypt.org; \ delegation=caa.example.com"caa.example.com. IN CAA 0 issue "letsencrypt.org; \ accounturi=https://example.net/account/1234"; Although this example would raise some more questions like: 1. Should the delegated entries also follow the CAA format? 2. Do the issue or issuewild tags need to match at all levels? I would love to hear some opinions on this matter. Cheers
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
