Yaron: If a party that has access to the private key is telling the CA that the certificate ought to be revoked. I’m thinking that the CA ought to revoke it. Any party that has access to that private key can do far more malicious things.
Russ > On May 30, 2017, at 11:48 AM, Richard Barnes <[email protected]> wrote: > > > > On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <[email protected] > <mailto:[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 > <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] <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
