On Thu, Dec 19, 2024 at 10:43 AM Roman Fischer <[email protected]> wrote:
> Dear everybody, > > > > >Point 3 is unusual as revocation for compliance reasons is explicitly > outlined, and that's all that this is? There isn't any new changes to the > legal language required that I can see. > > > > I checked with our legal department and they clearly stated that we will > have to amend the contracts if we want to be sure that we can't be sued for > damages inflicted by random revocation. Current language (at least in our > contracts) allows us to revoke in case of security incidents, > non-compliance and some other cases. But a preventative revocation would > currently not be covered. > A surprisingly direct statement from inside counsel, given that the detailed language of the policy component hasn’t been determined! But of course as we know you can get sued for anything, and the question is whether you eventually prevail in court. We saw with the unfortunate DigiCert situation earlier this year that even clear contract language around revocation promptness can’t protect against misleading filings or overly-sympathetic judges, at least in terms of initial injunctions and bringing a case that’s not trivially dismissed. If a CPS update is not sufficient—which would confuse me, but that’s not impossible!—your legal department would have ~18 months to roll out some (likely trivial) new language and get it adopted during renewals or through other means. I have confidence in them! An alternative, of course, is that Mozilla or whoever just adds N sampled certs to OneCRL with 5 days notice to the CA. Given that, there’s nothing that a CA needs to do other than inform the subscriber and reissue when asked, but that only really tests Subscriber capability and not CA commitment to compliance. I think we have seen an unfortunate abundance of evidence that both are areas of concern around prompt revocation, not that they necessarily need to be addressed by the same mechanism. > Also, I'm not convinced that it will motivate many customers towards > automation. Most will probably just gamble and bet on not being in the > unlucky 30, especially if they get their certs from a large CA... > Yes, this is a clear weakness of the fixed-30 element of the proposal, but that’s an argument for proportionate sampling, not for avoiding the practice entirely. I have a hard time reconciling “most will probably ignore this context” with “it would be too disruptive for subscribers”, I admit. > Regarding a comment made in another mail, I think it's fair to say that > most public trust CAs -need- to conform to all major root store policies to > be of any value for their customers. The more fragmented these root store > policies are, the more complex (and error prone!) complying to them > becomes. For this reason, we would really encourage the root store > operators to converge on requirements set forward. > > A requirement is no harder to meet because it’s from one root store than if it applies to multiple, surely. What is the source of additional error risk that goes away when something is more widely adopted by root programs? Does it become easier to participate in CT if that requirement from Chrome’s program is adopted by others? Are you saying that it’s too hard for a CA to analyze a handful of different root store policies and determine what the requirements *are*? Within the limits of reasonableness, that’s a job for the quality of language in the program descriptions; this is an area where there could be some improvements, which is part of why Ben is driving this refresh of the MSRP I think. Independent of that, I think it would be great for more root stores to join in this new practice, and I would like advocate to them for exactly that. That’s a separate question from whether it needs to be in the BRs via the CABF. I think it can be effective without inclusion in the BRs, just like Chrome’s policy on CT has been effective in driving adoption. 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqsvrxrNzOUKTUTyu1Yha2QtPWLZVr8pDyio1bso48nf-Q%40mail.gmail.com.
