Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Fraser Tweedale <[e-mail]>]

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://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/

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