Maybe a better way to ask my question is - Is there any situation other than an action taken expressly by the account where an ACME account with LE can become deactivated or revoked?
I'm pretty sure I know the answer to this question ("No.") but wish to double check as I'm not new to LE but I am new to trying to automate everything.
According to the ACME RFC account objects don't have a concept of expiry.
If I create some scripts to automate cert renewal, do I have to realistically worry about handling any kind of ACME account expiry or do they just not expire? Obviously authorizations expire regularly and that is easily handled but I'm mostly questioning the ACME accounts themselves.
It's possible for them to be deactivated without the account holder directly taking action, such as if the account key was reported as being compromised. Or possibly in a last-ditch effort to mitigate problems being caused by a poorly-behaving client or something like that.
I know somewhere I saw someone recommending that clients should plan on automatically creating a new account if the account that they were configured with had been deactivated, but I don't think it's in the "official" Integration Guide or RFCs. (And I don't think certbot does, for whatever that's worth.)
There's also this thread from earlier in the year, with some questions similar to yours:
I suppose that [at some point] the account encryption will be deemed insecure OR something else related to the level of privacy/usefulness will need to be elevated - nothing lasts forever!
And that may require generating a newer account.
[but that is just speculation on my part]
Well, if there were, say, a break in 2048-bit RSA, I could see needing clients to migrate their account keys to ECDSA (or a longer RSA key). But that shouldn't need making a new account, just changing the account key.
But yes, as the Integration Guide says, client authors definitely need to Plan For Change.
At some point we may choose to expire some accounts. That’s not likely to happen too soon.
A criteria will be something like accounts more than 5 years old and never successfully issued any certificates, or no certs issued in the last 5 years, or something along those lines that we predict will be non-disruptive.
Certainly any account that is routinely issuing (within the last two years, at a minimum) will not be deleted.
Note that staging is different, and we occasionally clear out staging.
I just wanted to add the following personal thoughts...
An ACME Account's identifier and API credential is the randomly generated Account Key.
The biggest component of "account" data on the ACME server is the Account Key itself. The fixed core account data (email address, tos, etc) are a fraction of that size. The scalable account data (identifiers linked to certs and activity) are relatively small and ephemeral in nature.
The ACME RFC requires "deactivated" accounts to have their keys placed on a blocklist to prevent other accounts from using it – either because the key was compromised, or somehow a second entity generated the same key for a brand new account or key rollover. (I am not sure if the CA/B Baseline rules require this or not.)
When you combine these two details together, I think it becomes increasingly unlikely without an RFC update to see an ACME Server expire or deactivate accounts as the current RFC essentially requires a server to maintain all active or previously-used Account Keys as either an Active Account or Blocklist. Unless they decide to block previously encountered keys on a digest/thumbprint value instead of the full key – my understanding of the RFC is that ISRG would simply be moving an Account Key from Active to Expired storage lookups, which should not result in any savings to database size.
That's only database size, performance is another issue -- so while I think it's very likely to see old account data culled, I doubt there will be a push by ISRG/LE to expire old accounts unless they hit a performance bottleneck on searches against active accounts (which I think is unlikely, because there are numerous ways to optimize that - many of which are inherent to various infrastructure changes they've previously announced as planned).
TLDR; I don't think LE/ISRG are likely to expire accounts because due to the RFC there will not be a sizable gain to performance or data storage and they have many more important things to do with limited resources.
This is my personal opinion, based in part on informed understanding but also pure conjecture.
While the key is the biggest thing, the email address and other associated PII is more interesting for deletion, as it avoids us holding PII unnecessarily which is something we don’t want to do.
So I do think there’s a chance at some point (not likely too soon) that we really do clear out old accounts, even if it does mean keeping more blocked keys.
Also, elliptical curve keys are a lot smaller than RSA, and newer accounts should be using those.
It's also probably the only reason accounts are saved, no?
I mean, cached authorisations can be associated with their public key, and deleted when they expire. I don't imagine boulder needs to know about every acme account ever, it just needs to tell them apart. (And blocklist them when deactivated)
I meant you can save all the (auth, accountpubkey) pairs without necessarily saving the entire accountpubkey space. You only need the subscriber to prove they control the private key, no proof of existing registration is needed (eab be damned).
My interpretation of the RFC is the ACME server probably only needs to retain the AccountKey and associated data for Certificate Revocation on compromised keys - which would be 90 days (Cached Authorizations are a LetsEncrypt implementation detail, last 30 days, and are expected to last shorter in the near future). Certificates can be revoked by other means, but via the issuing account key is incredibly useful.
Considering the CA/B Forum Baseline Requirements and browser behaviors with OCSP and caching can result in revoked certs being valid for 10 days, I think the theoretical minimum may be 100 days (e.g. to revoke an expired certificate within that 10 day window when weird things can happen). This is all theoretical though, in practice they're talking about 5 years. I don't think there are any other actions or RFC elements that require data retention beyond this point, however I have not read the totality of the BRs or the auditing requirements that ISRG must adhere to.
We're talking academics and theory here, but I think ISRG could conceivably do the following with old accounts:
1- Keep the AccountKey active, but destroy all associated data except for the email address and TOS version.
2- Keep the AccountKey active, but destroy all data – including the email and TOS version. Affected accounts would hit an error, and need to resubmit email and TOS if they authorize again.
I think #2 is not a viable option, because it's more likely to have clients re-register with a new key, than re-register with the account key - which undermines the savings.
Anyways, my point on chiming on here and de-railing this completed question, is that a server still needs to track "expired" account keys – so I think the logistics of trying to clear out old data may ultimately end up as just losing the associated data and not the account itself. It still seems to me that the work-effort to "archive" old accounts and PII would be considerably smaller than the effort to delete them that ISRG is considering, while the operational benefits for both would be about equal.
Unfortunately I believe we need to keep account keys forever, once they're registered. This is to prevent two actors from ever having access to the same account.
Imagine that Alice registers an account, then Bob compromises her account key. Alice realizes this and deactivates the account, causing Bob's malicious requests to be rejected. Years pass. Let's Encrypt deletes the account, because it has been deactivated for so long, forgetting about the key entirely. Bob's attack automation has been running the whole time, and suddenly starts "working" as it registers a new account using the same old key. Alice realizes what has happened, and can now use that original key to control Bob's account!
Obviously this is very contrived. But I think that if/when Let's Encrypt does actually delete old accounts, we'll likely move all of those old accounts keys into our list of blocked keys, to prevent them from ever being used again. Having many entries in that table (which is only checked at account creation time) is much more efficient and contains much less PII than having them (and their email addresses) in the accounts table.
Yeah, we've come to similar conclusions, except that I think the effort of moving the old keys to the blocked keys table, and not just leaving them as accounts stripped of PII, would be only marginally more effort and totally worth it for the database efficiency gains.
I think it's easier to switch this story/analogy around.
Irene generates keys endlessly and registers 2^x of accounts with the ACME server but otherwise does nothing with them. The ACME server eventually deletes the knowledge of these keys and accounts because they're inactive. Alice registers an account with a key that collides with one that Irene created in the past. Irene can now authenticate as Alice.
Sorry for being unclear, as I knew all that. I intended my post to be about migrating the "active" Account Keys to the expired datastore. i.e. I don't think an Account Key may have any utility (aside from creating new orders*) after 100 days from last issuance - and ISRG is considering 1760+ days of inactivity.
*(Based on the ACME spec alone, and not including any requirements by the CA/B forum or auditing/compliance programs ISRG belongs to).
