An older but still sufficiently-recent version of a different shard would contain serials which also appear on the current version of that same different shard. These duplicate serials would immediately indicate that a substitution has occurred.
On Thu, Oct 6, 2022 at 12:15 PM Andrew Ayer <a...@andrewayer.name> wrote: > On Thu, 6 Oct 2022 11:32:50 -0700 > "'Aaron Gable' via dev-security-policy@mozilla.org" > <dev-security-policy@mozilla.org> wrote: > > > A client downloading the full collection of CRL shards can check the > > thisUpdate timestamps to ensure it is not receiving old data, and can > > check for duplicate shards to ensure it doesn't receive the same > > shard twice. As long as they download the correct expected number of > > sufficiently-recent shards, there are no duplicates, and all > > signatures validate, they can be confident that none of the shards > > have been replaced. > > Could you elaborate on your proposed logic, in particular how a client > would determine whether a shard is "sufficiently-recent"? Let's say a > client considers anything less than 24 hours old to be > "sufficiently-recent" but a CA reissues CRLs every 12 hours. Then an > attacker would always be able to replace the shard they want to hide > with an older but still sufficiently-recent version of a different > shard. > > Regards, > Andrew > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErf%3Dksqbjsvd4w6saYz_%3DD7qdWxcj__69cMyArQdwFjyvQ%40mail.gmail.com.
