On Wed, Nov 11, 2015 at 11:11:19AM +0000, Eran Messeri wrote:
> On Wed, Nov 11, 2015 at 5:21 AM, David Mandelberg <[email protected]>
> wrote:
> > If a log ceases operation (and sets a Final STH) due to a planned
> > algorithm rollover, for how long are the log's existing SCTs and inclusion
> > proofs valid?
>
> I expect in this case the log would be completely removed from the list of
> logs recognized by the client when all of the certificates it has logged
> are either expired or are logged in other logs.
"logged in other logs" may not be a sufficient condition to allow a log to
be removed; otherwise-valid SCTs from the terminating log may be presented
for some time.
I know SCT redundancy in certificates is supposed to guard against a log
going away, but I presume a lot more logs will stop due to planned
termination than malfeasance, and that volume of terminations might be a
problem, even with the numbers of SCTs mandated for inclusion in
certificates.
The problem may also be present for SCT presentation in the TLS
handshake or OCSP response. What are the expected mechanisms for a server
operator to select a log (or logs) to retrieve an SCT? How will server
operators know to switch logs when the one they logged to "goes away"? I'm
thinking this is analogous to the "fire and forget" problem of things like
bogon lists[1], and it would be nice not to create the same problem again.
- Matt
[1] lists of "invalid" IP networks, which many network operators added as
"drop all traffic from these prefixes" in their routers. When the list
of "invalid" networks changed, because addresses in those ranges started
to be allocated, chunks of the Internet were unreachable because network
operators weren't keeping their bogon lists up-to-date.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
