Another option that has been proposed a number of times over the years has been to also support _caa underscore-prefixed attribute leaf labels (rfc8552) as well as updating the CAA search logic. This way a single delegation could just be a CNAME (although would then just allow for one). This could also be an opportunity to fix up some of the search logic in CAA in-collaboration with the IETF DNSOP WG as there are a number of issues with how CAA is currently specified that came up after it was specified.
For example: _caa.example.com. IN CNAME 600 caa1.example.net.caa1.example.net. IN CAA 10 issue "letsencrypt.org; accounturi=https://example.net/account/1234"; I'm not sure if this would fully cover your use-case (eg, you could have exactly one CNAME here unlike the more complex inclusions that something like SPF supports) but it would make it easier to delegate CAA record management details within an organization and could also be a path to fix some other issues with how CAA works in DNS. This would also allow CAA to be specific for records that are CNAME'd but keeping the CAA rules local. For example: abc.example.com. IN CNAME 600 abc-example.cdn.example. _caa.abc.example.com. IN CAA 10 issue "letsencrypt.org" Erik On Sat, Jan 25, 2025 at 9:07 AM Ramon Wehrli <ramonwehrli= 40googlemail....@dmarc.ietf.org> wrote: > *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 >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
