Subject: [Acme] Discussion on draft-aaron-acme-ari-01

From: Aaron Gable <[email-masked]>
Date: Thu, 11 Nov 2021 13:28:28 -0800

Hi acme@,

As mentioned in today's meeting, there are a few aspects of the current
ACME Renewal Info draft that I'd like feedback on.
The current draft is at
https://www.ietf.org/archive/id/draft-aaron-acme-ari-01.html, and the
source is at https://github.com/aarongable/draft-acme-ari.
Of course all notes and feedback outside these specific Open Questions is
also greatly appreciated.

1) Getting client to recheck ARI quickly and regularly

This is tracked as https://github.com/aarongable/draft-acme-ari/issues/13

The -01 ARI draft specifies that ARI responses must come with a
`Retry-After` header, and that clients should check ARI again after the
Retry-After period has passed. This matches the semantics of the
Retry-After header as specified in RFC7231.

However, this does nothing to suggest that the client should check in again
as soon as possible after the retry-after period has passed. For example, a
cron-based ACME client that wakes up once every 24 hours would be fully
compliant with an ACME server whose Retry-After header specifies 6 hours.

We would like to have the document specify that clients should check in on
a regular, server-controlled basis. The ideas we've had so far are:
a) Include a "next check-in window" in the renewalInfo response, alongside
the existing suggestedWindow
b) Include a "polling period" in the server's directory (either by making
the new `renewalInfo` key map to an object with both the base url and the
polling period; or by including it as a new key in the directory's meta
object)
c) Another header? Is there another HTTP header that provides the semantics
we want?
d) Leave it as-in, and just specify that the client should check in within
a certain amount of time after the Retry-After header.

I'm currently leaning towards (b), including the polling period in the ACME
directory meta section, but am open to other ideas and discussion.

2) Considering inclusion of a "this has been renewed" callback endpoint

This is tracked as https://github.com/aarongable/draft-acme-ari/issues/15

One of the motivating use-cases for this protocol extension is the
"business continuity in spite of revocation" case: a CA that is about to
revoke a certificate could, the next time that cert's subscriber's client
polls the ARI endpoint, inform the client that it should renew right away.
Then the client could replace the cert as normal, and the original could be
revoked without any disruption to the subscriber.

However, if a cert contains multiple identifiers as SANs, identifying when
a cert has been renewed becomes difficult. What if the client decides to
request two new certs, each with half of the identifiers? What if the
client no longer cares about one of the identifiers, and requests one cert
with N-1 names? It is easy to imagine even messier cases.

Therefore it would be useful for the client to be able to inform the server
"Thanks for telling me I should renew this cert; I have no completed that
task to my own satisfaction", so that the server can then go ahead and
revoke the cert, knowing it will not cause any disruption by doing so.

One idea to implement this would be for the client to POST to the same
resource url as it polls for renewalInfo, with the body being a signed JWT
containing a single "renewalComplete=true" as the body. The server would
only accept this if the POST were signed by the same account key as
originally ordered the cert.

3) Whether or not using SHA1 in constructing the URL is a good idea

This is tracked as https://github.com/aarongable/draft-acme-ari/issues/16
and https://github.com/aarongable/draft-acme-ari/issues/17

During the meeting there were some comments regarding the suitability of
SHA1 for hashing the Issuer Name and Issuer Key when constructing the
renewalInfo URL.

Points in favor of SHA1 include:
- No need for a cryptographic hash in this case
- Widely and readily available in all ACME client environments
- Matches the RFC5019 "Lightweight OCSP Profile" spec

Points against SHA1 include:
- Slower than some other non-cryptographic hashes
- Prevents libraries from dropping SHA1 support entirely
- Using something else likely also pushes us towards allowing algorithm
flexibility (as OCSP does), which introduces additional complexity

I currently believe that sticking with SHA1 is the best path forward, but
am very interested in further comments and discussion.

Thanks again for all of the discussion so far,
Aaron

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Nov 2021 13:37:57 -0500

> Retry-After header as specified in RFC7231.

Agreed.

    > a regular, server-controlled basis. The ideas we've had so far are:

I'm not quite clear how this can affect the once-every-24-hours crontab problem.
Is it your contention that this behaviour would change?
Would the client wake up once-every-24hours, and then wait?  or that the
crontab situation would change/go-away?

    > the existing suggestedWindow

How big would these windows be?

    > polling period; or by including it as a new key in the directory's meta

I'm not sure I understand this option.

    > c) Another header? Is there another HTTP header that provides the semantics

I don't think so.

    > directory meta section, but am open to other ideas and discussion.

That seems reasonable.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Nov 2021 13:43:50 -0500

{Splitting up replies to make threads easier to deal}

    > revoked without any disruption to the subscriber.

I manage LE's certificates for a few dozen machines.  Not so many that it's
worth the overhead of more formal monitoring, but not so few that it's easy.
They machines are very different in OSes and versions and whether they do
dns-01 or http-01 challenges, and so suffer from various different failures.

In about 2 out of 5 cases,  a few weeks after the last renewal, I've changed
something (added a new virtual host, for instance), which results in me
renewing early.  Alas, LE sends me a notice of expiry based upon the original
certificate expiry, and I make a note to check that it's really renewed, not
remembering which is which.

Long story: this confirmation stuff would be helpful for many situations.

    > originally ordered the cert.

This seems good.
When a certificate is re-issues with an expanded (or diminished) set of SANs,
then I hope that we can use this to mark the old certificate as satisfied.
Should the CA revoke?  I'm not sure if it's worth the CRL space, if CRLs are
being used.