FiloSottile
Configure validity dates with shorthands instead of start/end
@AGWA suggests at https://groups.google.com/a/chromium.org/g/ct-policy/c/936lR3MEUDU/m/fD9nWJceAgAJ
I can't help but wonder if the weird start/end dates contributed to this mistake. When I was configuring my monitor, I was so focused on the month and day that I didn't notice the incorrect year and ended up misconfiguring it as 2025. (I only became aware of the mistake this morning when I received alerts about the log containing certificates outside of the range.) If logs generally configured their shards using strings like "2025", "2025h2" or "2025q3" instead of a pair of date-times, it seems like mistakes would be less likely.
I'm unsure how to proceed with this. I like the idea of deriving the periods automatically, but the Let's Encrypt practices that @mcpherrinm shared in https://groups.google.com/a/chromium.org/g/ct-policy/c/936lR3MEUDU/m/zJemazEjAgAJ sound good and I'd like to encourage them.
One option is to support parsing a string like 2025h2 plus a backdate value in days(?).
Another option is to just test that the span is between six months and a year, and nothing else, per https://github.com/GoogleChrome/CertificateTransparency/blob/7ba65b6061317d0c122b03618d956a5dac57123f/log_policy.md#temporal-sharding. (Sunlight is a CT log, so it can and should overfit to the CT ecosystem. Should we also support non-production logs with different sharding though?)
Let's Encrypt has added validation that the spans are inside the expected range for us (more than 6 months, less than 8 months). Supporting the range from Chrome's policy seems fine to me. I'm not really worried about non-production logs, and I guess there's always the option for a flag to disable or configure the maximum length.
I'm lukewarm to having hardcoded shard periods. My preference for ecosystem health is to get shards less aligned rather than more, as we've had a couple "bumps" during transitions before, and I am not keen on making that more of a problem.
I've been thinking about launching our next log with Q4+Q1 and Q2+Q3 dates, though I don't have a good name like 2025h2. 2025q4q1 or 2025q4and2026q1 perhaps.
I'm lukewarm to having hardcoded shard periods. My preference for ecosystem health is to get shards less aligned rather than more, as we've had a couple "bumps" during transitions before, and I am not keen on making that more of a problem.
That's persuasive, yeah.
I've been thinking about launching our next log with Q4+Q1 and Q2+Q3 dates, though I don't have a good name like 2025h2. 2025q4q1 or 2025q4and2026q1 perhaps.
I was going to suggest 2025q4+2026q1 but then I remembered that wouldn't be ok in a https://c2sp.org/signed-note key name.