I might say instead, "... the CA SHOULD revoke all certificates associated with that subscriber that contain that public key. The CA SHOULD NOT assume that it has evidence of private key compromise for the purposes of: revoking the certificates of other subscribers or blocking issuance of future certificates with that key."
On Thu, Feb 3, 2022 at 11:25 AM 'Aaron Gable' via [email protected] <[email protected]> wrote: > I think there's been one additional piece of confusion here that I'd like > cleared up. > > Kathleen's proposed text says: > > - If the certificate subscriber requests that the CA revoke the > certificate for keyCompromise, and has not previously demonstrated and > cannot currently demonstrate possession of the associated private key of > that certificate, the CA SHOULD limit revocation to only certificates that > are associated with that subscriber and which contain that public key. > > In response to this, Doug Beattie said: > > 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). > > To which Ryan Sleevi replied: > > Correct. > > I originally interpreted that sentence of Kathleen's proposal not to mean > "only the single requested cert gets revoked", but rather "all certs > associated with that key *and that subscriber* get revoked". But on > further close reading, I think the phrasing of that sentence is confusing > and it should either be rephrased or left out entirely. > > In particular, the sentence causes confusion with regards to the existing > phrasing in 4.9.1.1 of the BRs: > > The CA SHALL revoke a Certificate within 24 hours if... The CA obtains > evidence that the Subscriber's Private Key corresponding to the Public Key > in the Certificate suffered a Key Compromise; > > If the CA is *not* revoking *all* certs associated with that keypair, > then clearly they do not have "evidence" that the private key has suffered > a key compromise. If they had such evidence, then they would be revoking > all such certs, regardless of subscriber. But if a CA does not have > evidence of a key compromise, rather they only have a request for > revocation of a single certificate with subscriber-attested reason > keyCompromise, then why are they revoking any additional certificates at > all? > > The same issue arises with regards to BRs 6.1.1.3: > > The CA SHALL reject a certificate request if... The CA has previously > been made aware that the Applicant's Private Key has suffered a Key > Compromise, such as through the provisions of Section 4.9.1.1; > > Does a subscriber-attested revocation of a single certificate count as > "being made aware"? Or does the reference to Section 4.9.1.1 mean that it > takes "evidence" to be "made aware", and that a CA should not block > issuance for a key that has only had subscriber-attested key compromise > with no proof of possession? > > I suspect that this is where Rob Stradling's point comes into play: the CA > doesn't have "evidence" of key compromise, but they do "suspect" that the > key may have been compromised, so they SHOULD revoke other certificates > with that key issued to the same subscriber. If that is the desired > interpretation, I would like that chain of reasoning to be made explicit in > the new requirements. Otherwise I think the risk of confusion between the > new requirements and the existing BRs is too high. > > I think that the phrasing of the current proposal in terms of "limit[ing] > revocation" is the crux of the confusion, so I propose the following > alternative phrasing: > ``` > - If the certificate subscriber requests that the CA revoke the > certificate for keyCompromise, and has not previously demonstrated and > cannot currently demonstrate possession of the associated private key of > that certificate, the CA SHOULD revoke all certificates associated with > that subscriber and which contain that public key, but is not considered to > necessarily have evidence of private key compromise for the purposes of > revoking certificates associated with other subscribers or blocking > issuance of future certificates with that key. > ``` > > Aaron > > On Thu, Feb 3, 2022 at 6:52 AM Ryan Sleevi <[email protected]> wrote: > >> >> >> On Thu, Feb 3, 2022 at 7:24 AM Doug Beattie <[email protected]> >> wrote: >> >>> 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). >>> >> >> Correct. >> >> >>> 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) >>> >> >> I'm not sure I follow this concern at all? It sounds like your goal is >> "KeyCompromise should only mean revocations with proof of possession" - but >> if so, I think we disagree on that goal. Is that the case? >> >> As to why that goal may be seen as useful, this sounds like the case of >> believing that CA X should be able to watch CA Y's revocations, but I'm not >> sure that's necessarily good or positive, because it's an assumption that >> CA Y performed all steps correctly. Just like we don't allow CA X to issue >> a cert to a Subscriber with {Key 1, Domain} just because CA Y issued a cert >> to a Subscriber with {Key 1, Domain}, we shouldn't trust the revocation >> information either >> >> >>> >>> >>> 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. >>> >> >> Hopefully Rob successfully showed why this conclusion is flawed. "It >> should be confirmed to be compromised" is wholly unnecessary for relying >> parties, and does not grant a false sense of security. Revocation is first >> and foremost about a certificate, not about a key; while it's nice to be >> able to more affirmatively express something about a key, that's not how >> the system works, nor designed, nor needs to. >> >> As to the other part of your questions, didn't Kathleen already address >> this with >> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SIqvgTmKnno/m/UPsTMDGAAwAJ >> ? "Why will it happen more efficiently and timely" is precisely because >> there are bounds to how effectively one can deliver information to browsers >> in an efficient, privacy preserving, data-respecting way. The whole effort >> of harmonizing reason codes is to provide consistent expectations that >> would allow user agents to prioritize multiple methods of delivery, based >> on the semantic meanings of the codes, reflecting the relative importance >> and need. >> >> Maybe you can elaborate on how you've been thinking about how this >> information is delivered. Have you been thinking solely in terms of OCSP >> and CRLs? That may explain the disconnect, given that those are not widely >> used directly by end clients. >> >> -- >> 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%3DHGxZM9cULfqw0HYOvK57JR7YnJPQ0-ruLPqb%3DF2Y%2B_DLw%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGxZM9cULfqw0HYOvK57JR7YnJPQ0-ruLPqb%3DF2Y%2B_DLw%40mail.gmail.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/CAEmnErfVAO-H1LdpJ50ZgrxEPnXGXUiBt5QKY-N1XiPBCcbuJw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfVAO-H1LdpJ50ZgrxEPnXGXUiBt5QKY-N1XiPBCcbuJw%40mail.gmail.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/CA%2B1gtaZtic2KgHqxLfyEw-84Fh1N2ahBauXFHdmPqcKHeqo76Q%40mail.gmail.com.
