Hi Yaron, The premise seems wrong: > These certificates allow the domain owner to terminate the TLS server's > authorization when necessary,
What that is technically true, it does not facilitate the *purpose* of the termination (which would be to prevent continued CDN content distribution) - clients can simply ignore the "expired certificate" problem and still get the content. Trying to build a kludge to use certificates where session keys should be used instead seems a bad-idea(tm) to me. Kind Regards, Chris Drake Thursday, July 21, 2016, 5:53:37 PM, you wrote: YS> Hi Chris, YS> The LURK CDN use case is described here: YS> https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3 YS> Personally I care more about the case of the TLS server being part of YS> the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box), YS> and talking to enterprise-based servers that hold the long-term credentials. YS> Thanks, YS> Yaron YS> On 20/07/16 23:32, Chris Drake wrote: >> Hi Yaron, >> >> What is the use case for these? >> >> Kind Regards, >> Chris Drake >> >> >> Wednesday, July 20, 2016, 7:51:57 PM, you wrote: >> >> YS> Hi, >> >> YS> At the LURK BoF this week there was some interest in having a solution >> YS> where a domain owner can delegate to some other entity (which we will >> YS> call "the TLS server") the authority to terminate TLS connections on its >> YS> behalf, using short-term certificates. These certificates allow the >> YS> domain owner to terminate the TLS server's authorization when necessary, >> YS> without requiring certificate revocation - which we know doesn't work >> YS> reliably. The certificates' validity is measured in days, e.g. 3 days. >> >> YS> First, I would like to request the working group to adopt short-term >> YS> certificates as a charter item. >> >> YS> Second, I would like the group's advice in choosing between two very >> YS> different approaches to this problem. >> >> >> YS> Option 1: Certificate Pull >> >> YS> This option is documented in the LURK draft [1], which will be modified >> YS> to include feedback received this week, specifically to use more >> YS> traditional certification request (CSR) flows. But the basic idea is >> YS> very simple: >> >> YS> 1. TLS server generates a CSR once every 3 days for www.example.com, >> YS> sends it to the domain owner using an authenticated REST API. >> >> YS> 2. Domain owner validates the CSR, forwards it to ACME server, gets back >> YS> a short-term cert. >> >> YS> 3. Domain owner returns the cert to the TLS server. >> >> YS> If something bad happens, the domain owner simply stops forwarding >> YS> requests from this particular TLS server. >> >> >> YS> Option 2: Certificate Delegation >> >> YS> This option moves more of the responsibility to the ACME server. >> >> YS> 1. Domain owner contacts the ACME server and obtains a "delegation >> YS> ticket" which is specific to the TLS server. The ticket is good for a >> YS> long period, e.g. 1 year. >> >> YS> 2. TLS server regularly contacts the ACME server, proves ownership of >> YS> the delegation ticket, and receives a short-term certificate. >> >> YS> If something bad happens, the domain owner contacts the ACME server and >> YS> revokes the delegation ticket. >> >> >> YS> Comparison: >> >> YS> 1. Option 2 is clearly more complicated to specify and to implement. >> >> YS> 2. Option 2 extends the ACME protocol. Many clients can ignore it, but >> YS> servers will need to implement it. >> >> YS> 3. Option 1 requires the domain owner to have a server available >> YS> regularly, even if it is only a short REST interaction once every few >> YS> days. Option 2 doesn't require any such server. >> >> YS> 4. Option 1 looks to the ACME server as a normal cert request, and >> YS> therefore will swamp the CT logs with lots of short-term certs. With >> YS> Option 2, we can log to CT the issuance of the delegation ticket instead >> YS> of the actual certificates. >> >> >> YS> I would appreciate your input! >> >> YS> Thanks, >> >> YS> Yaron >> >> >> YS> [1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00 >> >> >> >>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
