On Thu, May 12, 2016 at 09:19:50AM -0700, Jacob Hoffman-Andrews wrote: > Proposed change: instead of deletion of accounts and authorizations, > specify deactivation. This simplifies both the spec and the > implementation, and leaves data retention choices up to CA policy. > > https://github.com/ietf-wg-acme/acme/pull/125
RE: "It is up to server policy how long to retain data related to that account, whether to revoke certificates issued by that account, and whether to send email to that account's contacts." Should that still say something about the server revoking authz? Since there is no way to revoke that once the account key is revoked (unless we do the auto-revoke thing when authz is obtained for another account key). If we're going to say "the result of this depends on server policy" we do need a way for clients to query the resulting state in an automated way and resynchronise their state with the server again. Users shouldn't have to hand-hack local config and state based on an out of band declaration of server policy. Instead of leaving it up to the server to decide whether to revoke certs, what if we make that an option of the client request? i.e., something like: - status "deactivated", disables the account but does not revoke currently issued certs. - status "revoked", disables the account *and* revokes certs (and probably everything else associated with the account too). We already determined there wasn't a good One Size Fits All answer to whether to revoke certs by default in that case or not, but the user is the one who will be unhappy if we pick the wrong one for them, and saying "the CA will decide that for you" doesn't solve that like letting them tell it exactly what they need would. In the example given of "Clients may wish to do this when the account key is compromised.", they may have no other way to get the certs revoked, since they may not possess the certificate key for everything issued after the account key was compromised. But this way we'd also have the softer "deactivated" option to disable an existing key after a planned roll-over event, without immediately revoking the current certs. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
