> Maybe this is where I’m missing an important point. Why is the key > compromise reason more valuable and why will it happen more efficiently and > timely than other reasons in the case where the CA cannot validate POP? Both > can happen “immediately” and the end result is that (just) the requested > certificate is revoked, so does the reason code matter?
I’m also very interested in learning the rationale for why keyCompromise revocations are seemingly treated as higher priority, especially if Subscribers can self-attest to such compromise without any verification by the CA. Any RP software that selectively ignores certain revocations based on Subscriber-attested reasonCode has a security flaw in that an attacker who can fraudulently issue a certificate can similarly request revocation for that certificate specifying a reasonCode that RP software doesn’t prioritize. The net result in that scenario is that the certificate lifecycle is completed, but the risk to users of such RP software is still very much present as the certificate may be treated as valid. Thanks, Corey From: 'Doug Beattie' via [email protected] <[email protected]> Sent: Thursday, February 3, 2022 7:24 AM To: [email protected] Cc: Kathleen Wilson <[email protected]>; [email protected] Subject: RE: Revocation Reason Codes for TLS End-Entity Certificates Ryan, The intent of my recommendation was not to increase the burden or limit the ability of subscribers to revoke keys, it’s setting the proper/consistent revocation reason codes. In Kathleen’s proposal, if you want to revoke for key compromise but can’t demonstrate pop, then you can do that, but it results in just that one cert being revoked (same as unspecified). If the CA and CRL show revoked for key compromise (when POP is confirmed), then there are other actions to be performed (revoke other certs with the key across all subscribers, block further issuance across all subscribers). If we’re not doing that all the time then how is the relying party to know if this was really a key compromise or not? If we set the reason to unspecified (no reason code in CRLs) when POP is not verified everyone will have the same understanding of what key compromise means – it was confirmed to be compromised and there should not be any active certificates issued from that CA with that key (something 3rd parties will surely want to watch for) You mentioned this below: 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. Maybe this is where I’m missing an important point. Why is the key compromise reason more valuable and why will it happen more efficiently and timely than other reasons in the case where the CA cannot validate POP? Both can happen “immediately” and the end result is that (just) the requested certificate is revoked, so does the reason code matter? If we don’t tighten up the processing of key compromise revocations, then we have 2 different paths to go down when a subscriber requests revocation for key compromise, and we provide a false sense of “security” to those that are looking at the CRL (this key is marked as key compromised, but it’s OK for it to be in other past and future certificates). If it’s compromised, it should be confirmed to be compromised and if we can’t confirm that, then it should be revoked with another reason. Doug From: Ryan Sleevi <[email protected] <mailto:[email protected]> > Sent: Wednesday, February 2, 2022 5:35 PM To: Doug Beattie <[email protected] <mailto:[email protected]> > Cc: Kathleen Wilson <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; Ryan Sleevi <[email protected] <mailto:[email protected]> > Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates On Wed, Feb 2, 2022 at 7:25 AM Doug Beattie <[email protected] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB612905E9689C6038478D1CEFF0289%40PUZPR03MB6129.apcprd03.prod.outlook.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB612905E9689C6038478D1CEFF0289%40PUZPR03MB6129.apcprd03.prod.outlook.com?utm_medium=email&utm_source=footer> . -- 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/DM6PR14MB218683946250B5D0B51274DB92289%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
