There's no requirement for the server to have a revocation endpoint at all!
""" The server MUST provide “directory” and “new-nonce” resources. """ ... not "revoke-cert". It's up to the CA which parts of ACME they use. The only way this would make sense is if it were framed as "for the revocation mechanism defined in this document, you must..." And in that case, I would be inclined to just upgrade all those SHOULDs to MUSTs. On Tue, Mar 28, 2017 at 5:26 PM, Erica Portnoy <[email protected]> wrote: > Section 7.6 reads: > > Revocation requests are different from other ACME requests in that they > can be signed either with an account key pair or the key pair in the > certificate. Before revoking a certificate, the server MUST verify that > the key used to sign the request is authorized to revoke the > certificate. The server SHOULD consider at least the following accounts > authorized for a given certificate: > - the account that issued the certificate. > - an account that holds authorizations for all of the identifiers in the > certificate. > The server SHOULD also consider a revocation request valid if it is > signed with the private key corresponding to the public key in the > certificate. > > With this wording, the server is not required to accept any form of > automated revocation request. It should be able to accept at least one > form of revocation, even if only the account that issued the > certification, or any of the described methods but at least one. Either > of these would leave policy choices sufficiently flexible without > removing important functionality. > > Best, > Erica Portnoy > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
