Hi Yaron, It's a weak use case, because short-lived certificates do not solve the problem. I'm not saying CDN revocation is weak (actually - I will say that next, but I wasn't initially) - I *am* saying that trying to accomplish it with short-lived certs isn't sensible; totally the wrong tool for the job.
Not to mention - the idea of your CDN getting beached? - whoever invented that as a reason is clutching at improbable straws! If you need to stop your CDN distributing your stuff, go erase your content from them; showing "expired certificates" to customers a few days later is totally not going to cut it (nor will it stop the distribution for everyone who ignore those warning, which will be almost everyone.) Plus - the main idea of a CDN is for speed; regularly changing certs will slow everyone down too. Kind Regards, Chris Drake Friday, July 22, 2016, 10:52:06 PM, you wrote: YS> On 22/07/16 13:21, Chris Drake wrote: >> Hi Yaron, >> >> Best I can tell, everyone has jumped onto solving a cool problem, >> without there actually being any reason to solve it? >> >> I asked about the use case, and CDN authority revocation was all I got >> (imho a really *weak* reason). Maybe I got it wrong? >> >> What *exactly* is a use case for short-term certificates? What about >> HSTS/HPKP? >> Why would *any* expired short-term certificate be useful? Practically >> no ordinary user cares about bad certs - heck - iPhone users don't even >> have a way to check a cert even if they wanted to. >> >> Kind Regards, >> Chris Drake >> YS> Hi Chris, YS> Can you please explain why CDN authority revocation is a weak use case? YS> Let me share my preferred use case: I am running a large web property in YS> the cloud, where TLS connections are terminated on a cloud-based load YS> balancer (Amazon ELB, for a concrete example). I would like the cloud YS> provider to present my identity (www.example.com), but I want to revoke YS> this authority as soon as something bad happens, e.g. the cloud provider YS> is breached. YS> There may be alternative solutions, but I think short-term certs are a YS> reasonable solution here. Either the content owner gives the cloud YS> provider a new cert every X days (option 1), or the cloud provider can YS> get the short-term cert directly from the CA (option 2). YS> A solution that certainly CANNOT work is to give the cloud provider a YS> regular 1-year cert and revoke it if a breach occurs. Because we know YS> that cert revocation doesn't work. YS> Thanks, YS> Yaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
