Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Mon, Mar 23, 2020 at 2:43 PM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, March 19, 2020 at 2:02:39 AM UTC-4, Matt Palmer wrote: > > > 1. *Are* there explicit prohibitions on issuing a certificate for a > private > >key which has been previously submitted *to that CA* as compromised > >(assuming, of course, that the prior submission was valid), and I'm > just > >not good at finding said prohibitions? > > > BR 6.1.1.3 has a weak key clause, "The CA SHALL reject a certificate > request if the requested Public Key does not meet the requirements set > forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key > (such as a Debian weak key, see http://wiki.debian.org/SSLkeys)." > > I would think that "issuing a certificate for a private key which has been > previously submitted *to that CA* as compromised" is not in the spirit of > the weak key clause. It would be best if the CA would blacklist the public > key to prevent future issuance for the compromised private key. > Yeah, https://github.com/cabforum/documents/issues/171 is filed to track this. I've held off preparing a CA/Browser Forum ballot so that we can make sure to address the issue(s) holistically here, as we see the incidents coming in. (Sorry for the double post, from the right address this time) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thursday, March 19, 2020 at 2:02:39 AM UTC-4, Matt Palmer wrote: > 1. *Are* there explicit prohibitions on issuing a certificate for a private >key which has been previously submitted *to that CA* as compromised >(assuming, of course, that the prior submission was valid), and I'm just >not good at finding said prohibitions? > BR 6.1.1.3 has a weak key clause, "The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys)." I would think that "issuing a certificate for a private key which has been previously submitted *to that CA* as compromised" is not in the spirit of the weak key clause. It would be best if the CA would blacklist the public key to prevent future issuance for the compromised private key. Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 9:58 AM Wojtek Porczyk wrote: > On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via > dev-security-policy wrote: > > [...] but given that some negligent and > > irresponsible CAs kept agitating to reduce revocation requirements than > > protect users, the ballot was kept simple. > > > [...] I worry the same set of negligent and irresponsible > > CAs will try to advocate for more CA discretion when revocation, such as > > allowing the CA to avoid revoking when they’ve mislead the community as > to > > what they do (CP/CPS violations) or demonstrated gross incompetence (such > > as easily detected spelling issues in jurisdiction information). > > > > I would hope no CA would be so irresponsible as to try to bring that up > > during such a discussion. > > If I'm reading this correctly, you're labeling some CAs as negligent, > irresponsible and incompetent basing on the discussion and/or voting in > CA/B > Forum. > No, you're not reading correctly. The adjectives are based on quantifiable, systemic, repeat actions and incidents; they're pre-existing adjectives, independent of the discussion topics they take up. It just happens that those who bear the adjective happen to be the most likely to start those discussions, and were the ones most vocal in the past. Presumably, this is because they're the most likely to benefit, financially and reputationally, from shifting their liability and responsibility onto end users, or because they think in localized instances (such as "their" customer and "their" CA), without appreciating the systemic risk it can be introduced when it's "any" customer and "any" CA. The exception to this would be irresponsibility, which it would be irresponsible to try to attach "poison pill" riders that have been repeatedly discussed and rejected, when there exists real opportunity to keep things simple and improve them. Discussions of revocation requirements always seem to bring out folk who want to relitigate everything, rather than making the necessary progress in meaningful ways. That's the irresponsibility. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via dev-security-policy wrote: > [...] but given that some negligent and > irresponsible CAs kept agitating to reduce revocation requirements than > protect users, the ballot was kept simple. > [...] I worry the same set of negligent and irresponsible > CAs will try to advocate for more CA discretion when revocation, such as > allowing the CA to avoid revoking when they’ve mislead the community as to > what they do (CP/CPS violations) or demonstrated gross incompetence (such > as easily detected spelling issues in jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that up > during such a discussion. If I'm reading this correctly, you're labeling some CAs as negligent, irresponsible and incompetent basing on the discussion and/or voting in CA/B Forum. But those are adjectives that are inverse of what is required of CAs to have roots included in root store [0]. Additionally, I've seen multiple statements, some of them under official hats, that Mozilla treats CA conduct holisticaly when assessing trust (I don't have reference handy). Do you think that Mozilla may in the future consider voting or discussing "wrong" (for any definition of "wrong") as having impact on general trust that Mozilla has placed in a particular CA? (Maybe I'm exaggerating, but just think of it: " Issues. Issue X: failure to vote YES on ballot "). [0] "Including any CA carries a level of risk that is measured, in part, by the past record of the CA (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA during the inclusion process."; "Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility" (both from https://wiki.mozilla.org/CA/Application_Process) -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. (under personal hat) |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Is issuing a certificate for a previously-reported compromised private key misissuance?
Has anyone worked with a site/service like this that could help convey compromised keys between CAs? https://pwnedkeys.com/submit.html -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, March 19, 2020 7:05 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Is issuing a certificate for a previously-reported compromised private key misissuance? On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi wrote: > On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 2. If there are not explicit prohibitions already in place, *should* there > >be? If so, should it be a BR thing, or a Policy thing? > > https://github.com/cabforum/documents/issues/171 is filed to > explicitly track this. That said, I worry the same set of negligent > and irresponsible CAs will try to advocate for more CA discretion when > revocation, such as allowing the CA to avoid revoking when they’ve > mislead the community as to what they do (CP/CPS violations) or > demonstrated gross incompetence (such as easily detected spelling issues in > jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that > up during such a discussion. I shall fire up the popcorn maker in preparation. > > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > >to the issuance of a certificate, via a previously-submitted key > >compromise problem report for the same private key? If so, it would > >seem that, even if the issuance of the certificate is OK, it is a > >failure-to-revoke incident if the cert doesn't get revoked within 24 > >hours... > > Correct, that was indeed the previous conclusion around this. The CA > can issue, but then are obligated to revoke within 24 hours. Excellent, thanks for that confirmation. Incident report inbound. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi wrote: > On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 2. If there are not explicit prohibitions already in place, *should* there > >be? If so, should it be a BR thing, or a Policy thing? > > https://github.com/cabforum/documents/issues/171 is filed to explicitly > track this. That said, I worry the same set of negligent and irresponsible > CAs will try to advocate for more CA discretion when revocation, such as > allowing the CA to avoid revoking when they’ve mislead the community as to > what they do (CP/CPS violations) or demonstrated gross incompetence (such > as easily detected spelling issues in jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that up > during such a discussion. I shall fire up the popcorn maker in preparation. > > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > >to the issuance of a certificate, via a previously-submitted key > >compromise problem report for the same private key? If so, it would > >seem that, even if the issuance of the certificate is OK, it is a > >failure-to-revoke incident if the cert doesn't get revoked within 24 > >hours... > > Correct, that was indeed the previous conclusion around this. The CA can > issue, but then are obligated to revoke within 24 hours. Excellent, thanks for that confirmation. Incident report inbound. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Since I started requesting revocation for certificates with > known-compromised private keys, I've noticed a rather disturbing pattern > emerging in a few cases: > > 1. I find a private key on the Internet. > > 2. I request revocation from the CA on the basis that the private key is >compromised, and provide suitable evidence thereof. > > 3. The certificate is revoked. > > 4. Some time later, I discover that a new certificate, using the same >private key, has been issued by the same CA. (Mad props to CT!) > > 5. "Da wah?!?" I say, and scurry off to the BRs and Mozilla Root Store >Policy, only to find that there doesn't appear to be anything explicitly >covering this rather disconcerting situation. > > So, I'm asking the combined wisdom of this esteemed community the following > questions: > > 1. *Are* there explicit prohibitions on issuing a certificate for a private >key which has been previously submitted *to that CA* as compromised >(assuming, of course, that the prior submission was valid), and I'm just >not good at finding said prohibitions? No. We bandied about changes during the revisions to 4.9.1.1, using the exact scenario you described, but given that some negligent and irresponsible CAs kept agitating to reduce revocation requirements than protect users, the ballot was kept simple. 2. If there are not explicit prohibitions already in place, *should* there >be? If so, should it be a BR thing, or a Policy thing? > https://github.com/cabforum/documents/issues/171 is filed to explicitly track this. That said, I worry the same set of negligent and irresponsible CAs will try to advocate for more CA discretion when revocation, such as allowing the CA to avoid revoking when they’ve mislead the community as to what they do (CP/CPS violations) or demonstrated gross incompetence (such as easily detected spelling issues in jurisdiction information). I would hope no CA would be so irresponsible as to try to bring that up during such a discussion. > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > to >the issuance of a certificate, via a previously-submitted key compromise >problem report for the same private key? If so, it would seem that, > even >if the issuance of the certificate is OK, it is a failure-to-revoke >incident if the cert doesn't get revoked within 24 hours... Correct, that was indeed the previous conclusion around this. The CA can issue, but then are obligated to revoke within 24 hours. There’s not a statute of limitation on “obtains evidence” here, precisely because it could allow a host of shenanigans, such as CAs arguing the require per-cert evidence rather than systemic demonstrations. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On 2020-03-19 07:02, Matt Palmer wrote: 2. If there are not explicit prohibitions already in place, *should* there be? If so, should it be a BR thing, or a Policy thing? I think there should be. I expect them to publish a CRL that says the reason for revocation is a key compromise. I expect them to check for other keys with the same public key at that time, and also revoke them. Before signing a new key, I expect them to have checked it against there list of previously reported key compromises. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
