Hi Matt, On 19.06.20 01:21, Matt Palmer wrote: > > Another use case I can think of is analogous to the PGP concept of a > "revocation certificate". Consider the case where, for whatever reason, an > ordinary user of an ACME CA loses access to the private key used in a > certificate or ACME account, and wishes to notify the CA that the key should > no longer be trusted. While it is possible to deactivate an account if you > have the private key, you cannot do so if the keys have been abstracted and > then destroyed -- say, in a randomware+blackmail attack, which are, sadly, > all too common. It is not strictly necessary to hold either the account key which was used to issue the certificate or the private key belonging to the certificate.
According to section 7.6: > Before revoking a certificate, the server MUST verify that the key > used to sign the request is authorized to revoke the certificate. > The server MUST consider at least the following accounts authorized > for a given certificate: > > o the account that issued the certificate. > > o an account that holds authorizations for all of the identifiers in > the certificate. That means, you can create a new ACME account and get all the authorizations verified for all the identifiers present in the certificate, which then allows you to revoke every certificate with these identifiers. So the use case where all the private keys are lost forever is already taken care of by the protocol. Regards, Jannis _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
