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