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

[Michael Richardson <[e-mail]>]

tl;dr> I haven't read the document yet, but based upon the presentation, it
       looks like it fits into the ACME charter, and we should work on it.

Amir Omidi <amir=[e-mail]> wrote:
    > CAA
    > has so far been a ACME server side value, rather than client side. If

"Well actually,"
It's not specific to ACME, but to any CA.

    > that is the case, does it make sense to extend CAA to handle client
    > side behavior as well? I want to avoid a situation where CAA is a
    > hammer and everything is a nail.

I think that this is a concern, and I hope DNSOP will weigh in here as to the
value of a new RR vs using this one.  So far, I'm not seeing nails.

    > There is also the situation to
    > consider that some providers that also take control of the DNS
    > automatically set a temporary CAA record to get the certificate they
    > need.  For example, I believe cloudflare will just override any
    > existing CAA record to get a certificate from the various providers
    > they use.

override... remove and replace, or just extend?
I know many semi-technical managers like one-stop shopping, but it scares me,
and there are many services where I remain a product rather than a customer

    > #4, the user is supposed to be notified for failures. If the public
    > provider is already implementing this notification pipeline, why
    > wouldn't they be able to implement a drop down of "Pick your own CA" in
    > the UI exposed to the user.

I think because the provider wants to be able to try the backups in an
orderly (intime) fashion.   Many small sites are basically on auto-pilot for
the durations (<30 days) involved.   While some round-the-world blogger might
be able to get emails while travelling, they might not be able to do HTTPS
safely to reach the "drop-down"

    > would have more difficulty implementing this correctly, and handling
    > all the edge cases in the client compared to exposing a "Pick your own
    > CA" in the UI. If the goal was ultimate flexibility, I think it would
    > be easier for me to implement a pick your own CA with a textbox for the
    > directory of that CA than it would be to change my client to get that
    > information through CAA.  - Exposing this information in the UI also
    > avoids the subscriber agreement issue and the rate limit issue. These
    > large providers can establish the relationships with the CAs they want
    > to use, and use them in the issuance pipeline.

All good points.
I think that there should be some more applicability scope.

I think there is a difference between hosting-providers-at-scale vs foo.com
who has 37 horizontally scaled micro-services that they have automated.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide