by mirages on 1/10/25, 2:54 PM with 34 comments
by ForHackernews on 1/10/25, 4:49 PM
If this is permitted, then I see no problem with this plan. It will force people to do what they already should be doing: have a plan in place to rotate certificates in case of revocation.
> The point is that right now revocation is so painful that it’s causing CAs to side with subscriber convenience over the integrity of the web PKI. Sampled, controlled revocations let us identify points of pain before they have security implications, and motivate Subscribers to prepare their systems—whether through automation or not, up to them, I’m not their dad—to tolerate on-time revocation. We care about the likely outcomes of automation, such as tolerance of short revocation or expiry timelines, really, but if BigSlowCo wants to staff a 24-hour cert maintenance squad such that they don’t (successfully) pressure their CA into blowing revocation deadlines, that’s their opex choice. Directly evaluating ecosystem capability around prompt revocation is the only way I can think of to identify areas of danger or weakness before they become issues for the web.
This is like testing the fire extinguishers.
by alyandon on 1/10/25, 4:29 PM
by nimish on 1/10/25, 5:19 PM
by Habgdnv on 1/10/25, 6:23 PM
by Spivak on 1/10/25, 4:41 PM
But on the flip side those 30 unlucky souls are gonna be pissed. There's so many other less disruptive ways you could do this.
by tiffanyh on 1/10/25, 5:12 PM
As opposed to 30-random entities.
by DuckConference on 1/10/25, 5:10 PM
by workfromspace on 1/11/25, 11:09 AM
by seventytwo on 1/10/25, 5:34 PM
by 1317 on 1/10/25, 4:24 PM
by otabdeveloper4 on 1/10/25, 5:38 PM