Closed bwesterb closed 12 months ago
Requiring it SGTM, but out of curiousity, which part isn't quite correct?
Requiring it SGTM, but out of curiousity, which part isn't quite correct?
floor(lifetime / batch_duration) + 1
is off by one if lifetime
is a multiple of batch_duration
floor(lifetime / batch_duration) + 1 is off by one if lifetime is a multiple of batch_duration
Ah yeah, you're right. I think I was thinking that, suppose batch_duration = 1 and lifetime = 2, at time 2.5, we actually overlap with three batch intervals, not 2. But where I got that wrong was that we only care about overlapping with the batch endpoints, not the intervals.
I think the correct formulation was ceil(lifetime / batch_duration).
FWIW, while I think it's reasonable to express things in terms of integers where we can, it should be a low priority consideration. We should expect implementors to know how translate an expression with ceil/floor into integer math and need not sacrifice other considerations for it. In particular...
We accept certificates outside of their lifetime (as we accept whole batches at once).
I don't think that's true. We accept whole batches at once (which is fine; they have the same lifetime), but not whole windows. See step 4 here: https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html#name-certificate-verification
This was intentional. Just because a batch number is within your window does not mean it is valid. This is important whether or not the lifetimes are multiples of the batch duration. A relying party may be arbitrarily behind. By wall clock, maybe we are now at batch 100, but I last talked to the TS at batch 80. The far end of my window will contain only expired things, but I cannot start advertising 100 because I don't know what 100 is.
This is also why the certificate selection algorithm considers expiry, because the RP may say batch numbers that are expired. The certificate negotiation problem becomes a lot harder when RP-advertised windows aren't fixed-width.
(To that end, it's also okay if we overcount our window size. It's just wasteful. 😄)
Ah, you're right. Anyway, with lifetime a multiple of batch_duration, we don't have to ponder these issues anymore :).
I think we're not quite correct dealing with
lifetime
s that are not a multiple ofbatch_duration
. Perhaps better to demandlifetime
s to always be a multiple ofbatch_duration
.