Hi Fraser, I did not see your earlier proposal and thanks for providing this history. Can CAA be used? Yes, but the number of CAA records to manage grows with the number of domains for which certs must be issued. This could be a headache for some orgs. I agree that it depends on the number of domain names and that this could cause some challenges if you manage thousands of domain names, on the other hand, this could be templated (depending on the DNS provider), and if you have thousands of domain names you might also have thousands of ACME capable servers. In case all thousand domain names use the same CNAME, CAA specifies that the record could be at the target domain name.
Each domain must indeed have at least one CAA record, but there is no need to change these records unless you want to change the CAs for this domain. This draft could make such a change easier, as instead of changing the ACME server configuration (which is not always possible in a shared environment) at each provider and/or at all your own servers, and potentially in CAA, you could now simply change this domain by domain. CAA records should ideally be configured on all domains by organizations relying on certificates anyway, it restricts who can issue certificates for your domain name and significantly reduces the attack surface. All CAs are required to check CAA records according to the CA/Browser forum Baseline Requirements before issuing a certificate. That said, adoption of CAA is not at the level where we would like to see it. This draft might create an additional incentive to configure CAA records. Per published RFCs only the "dns" identifier type could be use with the CAA approach. "ip" identifiers are important for many orgs, particuarly those managing their own cloud infrastructure. Correct, this is not something we really considered, as when you manage your own infrastructure you can also manage your ACME configuration more easily. But like you stated, usage of CAA in the .arpa domain could be dealt with in a separate document. Paul ________________________________ From: Fraser Tweedale <fr...@frase.id.au> Sent: Friday, July 7, 2023 05:23 To: Mike Ounsworth <mike.ounswo...@entrust.com> Cc: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com>; Richard Barnes <r...@ipv.sx>; acme@ietf.org <acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt On Fri, Jul 07, 2023 at 01:55:52AM +0000, Mike Ounsworth wrote: > Thanks for the comments Fraser. > > Guilty as charged -- we were not thinking about private enterprise > environments when we wrote it; we were thinking about > publicly-reachable servers on public clouds getting certs from > public CAs. In that context, the quote from the abstract "at the > mercy of their hosting provider as to which Certification > Authorities (CAs) can be used" is less about the ACME server being > reachable in a network sense, and more about public hosting > providers -- quite reasonably -- not wanting to maintain a > dropdown menu of every ACME server on the internet. Typically if > you want to use a CA other than the single one that your hosting > provider knows how to ACME to, then your only option is to > manually upload a PEM file. Yuck. The other assumption here is > that this draft is really for domain owners who care enough about > where their certs come from to have a "favourite CA" because > people who don't care will be happy to use whatever default ACME > server. > > That said, it's interesting to think about how this could apply to > your enterprise problem of "find me /some/ ACME server that I can > reach/use in this network zone". Assuming a private network with > multiple DNS zones, you could configure your private DNS to slap > on a constant CAA record across a DNS zone, and that gives you > your "give me an ACME server, any one will do", right? > > Out of curiosity, what happened to draft-tweedale-acme-discovery? > Did it just not have enough momentum to proceed? Searching on the > ACME list archive did not turn up very much discussion. I presented it at IETF 109. There was broard agreement that it was a problem that should be solved, but no appetite for the WG to adopt it at that time. I'm happy with the content of the proposal and even implemented a working POC in certbot. For context, I work at Red Hat and helped develop the ACME server support in Red Hat Certificate System (upstream: Dogtag Certificate System) and Identity Management in RHEL (upstream: FreeIPA). So I was thinking about how to further enable customers to use cert automation within their environments. We haven't implemented the proposed DNS-SD records yet, because there is no client support (due to lack of a standard to follow - a "chicken/egg" situation). Can CAA be used? Yes, but the number of CAA records to manage grows with the number of domains for which certs must be issued. This could be a headache for some orgs. Per published RFCs only the "dns" identifier type could be use with the CAA approach. "ip" identifiers are important for many orgs, particuarly those managing their own cloud infrastructure. But how to use CAA for ipAddress SAN is not defined. (Perhaps use the existing CAA attributes in _.in-addr.arpa and _.ip6.arpa zones). There is a draft that defines how it would work for the "email" identifier type[1]. [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/__;!!FJ-Y8qCqXTj2!ezGmXjnzfTuIX7JryAxwWBM4Y0J3L361SpCv7HT0y-OrUWiCDLwPd9OLbGk2iZD2fa3rfV8mXrxRH3QGmNSGIBlmBj8$ However, I think that the CAA approach is likely to get more traction. It uses DNS RR types that PKI people are already familiar with. It *can* be used in enterprise environments, albeit with more administrative burden in scenarios that involve a lot of domain names. The gap of how CAA can be applied to ipAddress SAN names should be dealt with in a separate document. Such work will no doubt attract interest from other groups (CAB Forum in particular). The approaches are not mutually exclusive but I really can't imagine clients would want to implement support for more than one mechanism. Let's see where this new proposal leads! Cheers, Fraser Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
