On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <[email protected]> wrote:
> When we allow the issued certificate to revoke itself, this has major > implications, in particular for delegated certificates. But even for > regular certs, it is the account's private key that's more secure (it is > managed by the security personnel where such exist, it is not deployed on > multiple servers) and that is the certificate that should be preferred for > revocation. So I suggest to use MAY for revocation by the issued > certificate's private key, instead of SHOULD. > You MAY not like the latest change we made, which upgraded this requirement to MUST :) https://github.com/ietf-wg-acme/acme/pull/300 > Also, including the actual certificate in the request means that the CA > needs to perform multiple preliminary checks that would not be required if > the client sent the certificate URL (or its serial number). The CA MUST > parse the certificate, MUST validate it, MUST ensure that it was issued by > the current CA, and then MUST identify it in its database of issued certs. > More complexity, more opportunities for security holes. > The idea of including the certificate (as well as allowing a certificate to revoke itself) was to support the case where an admin just finds a certificate + private key lying around, and wants to kill it. In that case, you have neither the Certificate URI nor the account private key. I would note that we have shifted from referencing keys by value to by reference in request JWS objects, requiring clients to track their account URIs. We made that change in the interest of forcing the server to look up a public key for the account, reducing the likelihood of the server accepting a signature by an unknown key. We might get some similar benefits here, but maybe not -- after all, if the certificate doesn't correspond to a URI, then it's probably not from this CA, in which case it the CA can't revoke it anyway. --Richard > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
