2016-07-20 14:52 GMT+02:00 Sean Leonard <[email protected]>:

> On 7/20/2016 2:51 AM, Yaron Sheffer wrote:
>
>> Option 1: Certificate Pull
>> [...]
>> 1. TLS server generates a CSR once every 3 days for www.example.com,
>> sends it to the domain owner using an authenticated REST API.
>> [...]
>> Comparison:
>> 3. Option 1 requires the domain owner to have a server available
>> regularly, even if it is only a short REST interaction once every few
>> days.
>>
>
> Actually a new certificate needs to be requested at least once per day.
> The 1 day before and 1 day after is for clock skew time. That increases all
> communications by 3x. Possibly much more, if you want your skew time to be
> greater than 24 hours.
>

I guess most ACME issued certificates are currently installed immediately.
The 1 hour backdate of Let's Encrypt seems to be enough to cover most clock
skews. I didn't see any complaints about that specific issue yet, at least.


> If the TLS server:
> a) reuses the same private key for the equivalent long-term period (1
> year) and the short-term certificates have a common continuity data item
> (either a certificate extension, or a custom RDN component, containing a
> common identifier such as a UUID), or
> b) if each short-term certificate identifies the prior short-term
> certificate (by identifying the prior short-term certificate's serial
> number, or, by reserving the last 9 bits of the serial number to a sequence
> from 0 - 511, to be issued serially to the same TLS server)
>
> ...would CT be able to correlate them so as not to overwhelm the logs?
>

But yes, even if not every day, but every 3 days, I would be a lot of
certificates.


> The advantage of the latter-most suggestion(s) is that CT logs could be
> engineered to record a "rolling certificate pack": the certificate stored
> is a single certificate (the base certificate), and the certificate is
> interpolated on a daily basis where the serial number bits change as the
> notBefore and notAfter times advance by a predetermined amount of time
> (e.g., 24 hours). Of course, the signature block would change;
> interpolating those bits would not be sufficient to regenerate the rolling
> certificates unless the signature blocks are recorded.
>
> Sean
>
>
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to