On 30/05/17 18:48, Richard Barnes 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
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
I certainly don't like the latest change :-)
I understand the use case of "finding a key lying around" (although I've
never personally found a key lying around), but if you think of an
enterprise with a small group of people managing security but a much
larger group of people with access to server certs, this provides any
server admin with a trivial way to DoS the organization by revoking
www.bigcorp.com, so trivial that people can do it by mistake.
Thanks,
Yaron
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
