What if lifetime not a multiple of batch_duration

[bwesterb]

I think we're not quite correct dealing with lifetimes that are not a multiple of batch_duration. Perhaps better to demand lifetimes to always be a multiple of batch_duration.

[davidben]

Requiring it SGTM, but out of curiousity, which part isn't quite correct?

[bwesterb]

Requiring it SGTM, but out of curiousity, which part isn't quite correct?

1. floor(lifetime / batch_duration) + 1 is off by one if lifetime is a multiple of batch_duration
2. We accept certificates outside of their lifetime (as we accept whole batches at once).

[davidben]

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. 😄)

[bwesterb]

Ah, you're right. Anyway, with lifetime a multiple of batch_duration, we don't have to ponder these issues anymore :).