Discuss clock skews

[davidben]

Probably under deployment considerations. The shortlived certificate aspect assumes your clock is right. Although we also get to play on easy: we're only considering up-to-date RPs and those RPs (presumably) got a clock update in the most recent update.

The clock could have gone wrong since though, so deployments would need to ponder this.

[bwesterb]

Perhaps too radical of a proposal, but what is the argument against the following: an RP will accept a certificate in the latest window it has regardless of the clock.

This will make negotiation also easier. Because what if the RP has its clock skewed to the future and thinks it has a very outdated window: say only two batches of that window are valid. If it sends that it has this window to a subscriber, and the subscriber has a certificate in one of the earlier batches, it will send that one without considering the clock skew of the RP.

[davidben]

The RP may not necessarily be able to contact the update server all the time. The latest window being far in the past could be clock skew, or it could just be stale. I don't think the RP should accept the batch in that case, otherwise expiry on these certificates don't work. And if expiry doesn't work, everything that follows from expiry (scope of revocation, monitoring, etc) breaks down.

[bwesterb]

Then shouldn't the RP negotiate by saying "I'll accept these CAs with batches between n and m", where m-n < validity_window_size? Then the only thing clock skew can do, is making n too large.

[davidben]

Oh yeah, that'd be a nice way to resolve that. The current negotiation scheme can't express that, but I think the current scheme needs work anyway.

(Though if the fast-issuance flow gets to comparable certificate lifetimes, we'll need an answer for clock skew anyway... which may be simply "RPs should deal with this".)