On Wed, Feb 2, 2022 at 7:25 AM Doug Beattie <[email protected]> wrote:
> Will the CA block further issuance when the request for revocation does > not include PoP which could DoS them for renewal using the same key pair? > To me, if the subscriber can’t provide PoP of the private key the > unspecified reason code would be more accurate. What’s the value to the > subscriber, CA and ecosystem to treat that case as key compromise vs. > unspecified? > > > > I’m probably just not understanding the background and value for the > second rule around processing requests for revocation with key compromise > without PoP. > As hopefully my reply to Aaron captured a little, it's about where the burden rests. Today, for most TLS issuance, no POP is required. That's because TLS itself doesn't need a POP, because it's an online protocol - the POP is delivered in-band, and it's not an identity-attestation system based on a directory (e.g. compared to S/MIME, where a sender needs to look up your public key ahead of time to encrypt something to you) So the functional change of requiring the POP is that very few people, today, could request keyCompromise without doing more work. That's not ideal. Further, however, is that for situations that are not uncommon, such as malicious deletion or ransomware, there is zero guarantee the victim would be able to prove keyCompromise at that time. This is very similar to the discussions in the past of how many hoops a CA can place to request revocation (i.e. "You can only request revocation on the fifth Tuesday of every February under the full moon"). For Subscribers, and users, this matters. However, an additional consideration is that keyCompromise revocations *are* likely more valuable than other forms of revocations, both in terms of efficient and timely delivery and in user risk. A policy that restricts when and how Subscribers can request this revocation is thus one that limits the value of that, by making it harder, which harms end users more. The more barriers placed for Subscribers, the harder it is to get this information in a timely fashion. So, to end users, it's ideal where Subscribers can request any revocation reason that they want (... within reason), and for imposing obligations on CAs, to use particular revocation reasons when they're made aware, either internally or by externally reports. That protects users the most. However, because there's no POP, that does offer _some_ abuse scenarios from malicious entities wishing to abuse the policies, and so some safeguards are needed. The question posed to this group is, seemingly, do we want to throw the baby out with the bathwater? Namely, should Subscribers have flexibility to (as easily as possible) request the method of their choice, or is the risk of abuse too great to trust them? I'd like to find a solution where we can empower Subscribers as much as possible, because that can help protect Users the greatest. I think you're right that we want to figure out how to narrowly scope the abuse scenarios, so definitely, thanks for raising 6.1.1.3. We should try to find a way to best balance things, don't you agree? -- 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/CAErg%3DHEaptK1R7PMBFNYvp6_hHcMD4FRL7C3b4OP1yK2YaJFzQ%40mail.gmail.com.
