On Mon, Jun 10, 2024 at 11:06 AM Tyrel <[email protected]> wrote:
> Since it has come up in multiple delayed revocation events across multiple > CAs, I want to push back on the idea that regulators are a valid reason for > revocation delays in most cases. What do you mean by valid? - seen as an acceptable reason by regulators? - seen as an acceptable reason by subscribers? - seen as an acceptable reason by CAs? - seen as an acceptable reason by relying parties? - compatible with the rules laid out in the BRs? - seen as an acceptable reason by root programs? the first 3 seem to often be the case, from the evidence available to me I’m guessing but I don’t think the vast majority of relying parties care, but would probably accede to “the government said we can’t do this thing (and we won’t bring up any of the things we could have done to avoid this situation)” the BRs don’t admit to any option for delaying revocation beyond 120hr but they also don’t indicate what an appropriate response should be, and it is clear that “distrust” is not viewed as a proportionate response even to a large number of delayed revocation incidents (in the absence of other problems) and it’s sort of hard to see how often it’s bought up in delrev incidents without specific opposition by root program representatives, let alone subsequent consequences, and *not* feel that the root programs actually feel that it’s a valid reason I think that the practice of delaying revocation due to (entirely predictable, and plausible to mitigate, if also generally undetailed) regulatory contexts is harmful for the web PKI, but as long as the CAs are able to push the risk onto the web PKI rather than turning away a customer that is inappropriate for the web PKI, or telling them to get a backup certificate pre-approved from a different CA, or whatever…why would CAs *not* let Subscribers use that as an excuse? Mike -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsH7KwoJ2PXGJXkw5S18dQDH4NXSNCivjzoMFyvZRxWpw%40mail.gmail.com.
