On Sun, Feb 06, 2022 at 04:34:00PM +0200, Dimitris Zacharopoulos wrote: > On 4/2/2022 2:20 π.μ., Matt Palmer wrote: > > On Wed, Feb 02, 2022 at 06:23:59AM +0000, Dimitris Zacharopoulos wrote: > > > I believe the phrase "previously demonstrated" may be misinterpreted to > > > mean the initial CSR submission, as Wilson and Ryan described. > > > > > > There needs to be some sort of "fresh" or new demonstration of controlling > > > the compromised key so that other Subscribers can be safe from the DoS > > > scenario. Hope this sounds reasonable. > > Can you explain your reasoning here? If a subscriber proved possession at > > time of issuance, what scenario is there where that same subscriber saying > > "this key is compromised" could cause a DoS on another legitimate > > subscriber? > > > > Note that by "proved possession" I'm not referring to CAs who just use the > > CSR as a convenient way of receiving the public key. I understand that > > if a CA doesn't validate that the details in the CSR matches the details in > > the issued certificate, that doesn't prevent the DoS scenario, but I also > > don't consider that to provide proof of possession. > > As several people stated in this thread, CSRs are not intended to be kept > "private". They could be found in public repositories. Allowing a > third-party to submit a certificate problem report and use a CSR without any > indication in the signed message that this is to be used as proof that this > key is compromised, can cause a DoS.
Yes, that's why *proved* possession is important, not just "here's a CSR, please revoke", which is why I used that term in my previous message. The unhandled corner case, which I believe Aaron Gable described, is when a key is reused amongst many certificates, and the domain of one of the certificates expires and is re-registered by a miscreant, who uses it to "prove" possession by having a certificate issued with a CSR dug up for that domain. Frankly, I'd prefer to see that problem solved by banning the reuse of keys across certificates (preferably even at renewal time, but at least across unrelated certificates), rather than mandate an even more complicated process for subscribers to legitimately report a compromised key. > I recall having seen certificate problem reports that are submitted by > security researchers for which the CN included text indicating that this is > to report a compromised key. I believe the CN was "this key is compromised" > or something along those lines. The CN you're thinking of is probably "The key that signed this CSR has been publicly disclosed. It should not be used for any purpose.", because I submitted a great many CSRs with that CN to CAs as proof of key compromise. I was reporting so many compromised keys, in fact, that several CAs amended their CPSes to prevent that as a method of proving key compromise. > With that said, if a CA wants to accept a > certificate problem report by a third-party, with a CSR that just includes > CN=mydomain.example.com and treat that as POP for revoking all certificates > that include the public key in that CSR, I don't think there is anything in > the current BRs or Mozilla policy to forbid it. IMO it would be a bad > practice. Yes, that would be a bad practice, but there are lots of things that are bad practices that aren't prohibited by the BRs or Mozilla policy. As far as I can see, there's nothing in the BRs or Mozilla policy that prevents a CA from using a large room full of oompa-loompas[1] to do the arithmetic required to calculate signatures (as long as that room full of oompa-loompas can get a FIPS 140-2 certification[2]). I think we'd both agree that would be a bad practice, but does Mozilla policy really need to explicitly prohibit oompa-loompas in the data centre? - Matt [1] Coming soon to the Mozilla CA requests queue: Willy Wonka's Chocolate Certificates Factory. Certificate expiry time will be limited to whenever the sysadmin gets peckish. [2] the need to destroy the key material on physical compromise might be a bit rough on the poor oompa-loompas, but there's no OSHA mandates in the BRs or Mozilla policy, either. -- 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/20220215005526.GB13429%40hezmatt.org.
