On Wed 2015-05-13 19:36:51 -0400, Ted Hardie wrote: > So, the point I'm getting at is that the system ought to provide > an automated way to request revocation if the requester can meet > the same bar as it would take to request or renew a certificate. If 42 > is one of the ways to meet that bar, well and good. If 42 is not one > of the ways to meet the original bar, then putting effort to automating > revocation on that basis seems off to me.
There is at least one scenario where automated revocation seems
legitimate but automated issuance does not: posession of the
end-entity's secret key.
That is: If i have the secret key, i *also* need to prove something else
(control of the domain) to get a certificate issued. But if i have the
secret key to an already-issued certificate, i should not need to prove
control of the domain to get the certificate revoked.
If I compromise your secret key, the nicest possible thing i can do with
it is get it revoked. There is no reason to prevent this action from
anyone who has access to the secret key.
I think i like Russ's first suggestion best:
>> ACME certificate management must, in an automated manner, allow an
>> authorized party to request revocation of a certificate.
because it lets the WG (and implementers/deployers) decide to include
types of authorization that might be relevant for revocation but not for
issuance, while still covering the general case.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
