I know I'm in the rough here, but IMHO for many enterprises, when they
compare between a certain downtime and a not so certain MITM threat,
they would decide differently. But I'm not going to argue this point any
further.
Thanks,
Yaron
On 30/05/17 20:10, Russ Housley wrote:
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]
<mailto:[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
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
