On Tue, Apr 26, 2016 at 10:03:13AM +0900, Randy Bush wrote: > >> That would just leave us wanting a way to also revoke certs that might > >> have been issued to an illegitimate key. But given the lag that OCSP > >> has, it might be reasonable to just auto-kill those too, since with > >> reasonable automation even a 'normal' key roll-over can probably get > >> new certs deployed before OCSP starts flagging old ones as revoked. > > > > I don't think authorizing under a new account key should revoke old > > certs. I think in general we want revocation to be an intentional > > action, or we risk people accidentally taking their own site down. > > this is an old problem. from loss of private keys (yes, one is inclined > to mis-cite darwin) to people creating bogus pgp credentials with my > email address. > > i am not aware of a simple reliable in-band solution. the examples i > know rely on out of band proof of identity. oob revocation > authentication usually has scaling issues.
I think the problem in ACME's scope is much smaller. How you get back control of 'lost' authority for completing a challenge (ie. exclusive control over your server/DNS etc.) is separate to ACME. We just need a way to inform the ACME CA once you do that you are now the authorised authority, and give you the ability to revoke anything that was granted or issued under any other prior authority. Automatically cancelling all other authz seems simple enough. I don't mind having to manually revoke certs in that case, but I floated doing that automatically as well because the manual option means adding things that we don't have yet too. In theory the reg object returns "authorizations" and "certificates" (boulder doesn't implement that yet), but -02 says that's only for "certificates issued for this account" ... where what we'd need in this case is certs issued for names under any account (and the ability for a different account key to revoke them, since you won't have either the original account key or the original cert key). I guess the other trick with auto-killing authz, is that the imposter might have authorised names which are ostensibly under my control, but which I don't normally have registered with the ACME CA. i.e., I have my.org and foo.my.org authorised. After a break-in, someone gets authz for my.org, foo.my.org, bar.my.org. If I recover with my original configuration, bar.my.org wouldn't get auto-killed since I won't (know to) challenge for it ... In some ways, that's probably not a lot different from them registering things I don't know about with a different CA that I don't know about, but if I have CAA in use, it would be nice to be able to query for all extant authz for *.my.org with that CA to be sure I can do what is needed to reclaim them all again. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
