Re: [Acme] Short term certificates - two options

[Yaron Sheffer <[e-mail]>]

Hi Chris,

The LURK CDN use case is described here: 
https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3

Personally I care more about the case of the TLS server being part of 
the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box), 
and talking to enterprise-based servers that hold the long-term credentials.

Thanks,
	Yaron

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
>
>
>
>