The other endpoints' sections in the document are written using language assuming that that endpoint is implemented, so it makes sense to do the same thing here.
So given that there's a revocation endpoint, you're saying that all of the revocation authorization methods mentioned must be considered valid? That seems like overkill. On 03/28/2017 03:05 PM, Richard Barnes wrote: > 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] > <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
