Re: [Acme] ACME Renewal Information (ARI) API Proposal

[Michael Richardson <[e-mail]>]

Roland Shoemaker <[e-mail]> wrote:
    > At Let's Encrypt we've been thinking about designing some kind of renewal
    > information API as an extension to ACME for a while now. Recent events
    > have

Interesting, thank you for starting this.

    > The first of these issues is how a CA should inform subscribers of a CA, or
    > third-party, initiated certificate revocation event. In most cases this

One serious thought is that this should be in-protocol either at the TLS
level or at the HTTPS level (via /.well-known).  While this will *not* work
for many uses, for those that it does work, it might be a very good way.
That is, the CA should initiate towards the server.

Failing that, the user of certificate (the ACME client) will need to poll.

    > The second issue is how ACME clients should determine when to renew a
    > regular non-revoked certificate. Most clients take one of two routes. They
    > are either manually configured to renew at a specific interval (i.e. via
    > `cron` or similar) or parse the issued certificate to determine the
    > expiration date and choose some date preceding it to attempt renewal. While
    > the latter option is better than the former, each can cause issues for both
    > the client and the issuing CA.

This is not how I see letsencrypt being configured by many.

A cron job is configured to attempt renewal once a week.
(Cron and the universe could probably benefit from a time randomization function)

This results in the latter option, of parsing the certificate and deciding if
one is close enough to expiry. I don't see why that decision couldn't be made
by the server rather than the client.
With a client-side certificate authenticated TLS connection, the server would
immediately *see* what the ACME client has.

    > The disadvantages of using OCSP mainly revolve around usage of the protocol
    > by relying parties. In order to avoid intolerance for new OCSP extensions
    > we would likely want to require clients to indicate that they want this
    > information, via either an OCSP request extension or an HTTP header, which
    > could increase caching requirements for the issuing CA and possibly require
    > changes to their existing caching infrastructure.

It's the first I hear that OCSP clients are intolerant of extensions.
If we have to fix OCSP to solve this, then that should just be done.

    > The disadvantages of using ACME mainly revolve around increased load on the
    > ACME API for the issuing CA. ACME currently has no endpoints that are
    > designed to be routinely polled, adding one could introduce a significant
    > load vector which infrastructure has not been designed for. Another
    > disadvantage is that if the API was authenticated it wouldn't be possible
    > to viably cache the renewal information at a CDN layer.

    > On balance it seems like ACME is the better choice for this API.

I agree.

    > ## Push vs. Pull

    > The CA could either push information to ACME clients, for instance via
    > webhook, or it could rely on clients polling for information.

    > The push method is challenging because many ACME clients run behind
    > firewalls or don’t have full access to provide external-facing services.
    > For instance, an ACME client might only have the ability to provision files
    > under /.well-known/acme-challenge/, or it might only have access to modify
    > DNS records.

    > The pull method, on the other hand, is straightforward. ACME clients, by
    > necessity, need to send HTTPS requests to the CA. They can use that same
    > channel to poll periodically.

I think that we probably want both.
Those who can not tolerate 3-4 day outages because they got revoked while not
paying attention, can implement the right things for push.

    > ## Cacheability

    > An important question to answer is if the results of this API need to be
    > cacheable, and if so what level of cacheable it should have. One reason for
    > designing the API around cacheability would be high request load for
    > repeated requests. Users for repeated identical requests are likely to have
    > a relatively low cardinality and these requests are not likely to be made
    > rapidly, suggesting that the API doesn't need to be highly cacheable. That
    > said given the information returned by the API isn't likely to be dynamic
    > (for instance in the lifetime of the certificate it is unlikely to change,
    > barring a revocation event) it seems likely that the issuing CA would like
    > some way to cache the results in order to reduce unnecessary resource usage..

What could be cacheable would be an information index of some kind.
Whenever the ACME server is going to do something that might affect lifetimes
of *some* certificate, the index could be incremented, which would cause
specific questions to be emitted.
This is very CRL-like, btw, and maybe could be done within the CRL infrastructure.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [