Re: Forbid creation of non-constrained intermediates for external entities
On 24/03/15 19:58, Florian Weimer wrote: snip There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. Huh? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Florian Weimer: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? According to the CNNIC CPS, the sub-CA certificate still exists: “According to the agreement of CNNIC and Entrust, CNNIC intermediate root CNNIC SSL is trusted by Entrust root certificate also. The domain certificates issued by CNNIC Trusted Network Service Center may be generated through different route either by CNNIC root or by Entrust root.” Certificate Practice Statement of the Trusted Network Service Center of the China Internet Network Information Center (CNNIC) Version No.: 3.03 Validity from July 1st, 2013 http://www1.cnnic.cn/IS/fwqzs/CNNICfwqzsywgz/201208/W020130929345948738150.pdf However, Entrust does not list the sub-CA certificate here: http://www.entrust.net/about/third-party-sub-ca.htm As far as I can see, there are several explanations for that: * It was omitted by accident. * The CNNIC root was signed (although only signatures on the intermediate CNNIC SSL CA certificate have been documented so far, I think). * Entrust assumes that once an organization has a root in the Mozilla program, any sub-CAs controlled by that organization is exempted from disclosure. * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On 25/03/15 10:12, Florian Weimer wrote: * Rob Stradling: On 24/03/15 19:58, Florian Weimer wrote: snip There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. Huh? The work on name redaction worries me. I wondered if that was what you were referring to. The purpose of the name redaction work is to resolve a major barrier to adoption of CT, without reducing the security. It is absolutely _not_ an effort to defang CT! Please share your concerns on the TRANS list. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Rob Stradling: On 24/03/15 19:58, Florian Weimer wrote: snip There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. Huh? The work on name redaction worries me. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Gervase Markham: On 25/03/15 10:27, Florian Weimer wrote: * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. I believe this is the correct answer. Quoting Bruce Morton in this thread: Please note that the intermediate certificate which Entrust issued to CNNIC expired in 2012 and was not extended. Also note that the Basic Constraints had a path length of 0; as such the trust would not have extended to intermediates issued by CNNIC. Yes, I saw this message only after I had posted the above. This leads to the question why Ernst Young, CNNIC's auditors, have not caught this discrepancy between the CPS and actual business practice. The most recent audit https://cert.webtrust.org/SealFile?seal=1731file=pdf already covers the time period when CNNIC ceased to be an Entrust sub-CA. (I think to clean up this mess, we should focus on formal mistakes by auditors, not things that can be downplayed as operational glitches.) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Wednesday, March 25, 2015 at 6:28:34 AM UTC-4, Florian Weimer wrote: * Florian Weimer: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? According to the CNNIC CPS, the sub-CA certificate still exists: According to the agreement of CNNIC and Entrust, CNNIC intermediate root CNNIC SSL is trusted by Entrust root certificate also. The domain certificates issued by CNNIC Trusted Network Service Center may be generated through different route either by CNNIC root or by Entrust root. Certificate Practice Statement of the Trusted Network Service Center of the China Internet Network Information Center (CNNIC) Version No.: 3.03 Validity from July 1st, 2013 http://www1.cnnic.cn/IS/fwqzs/CNNICfwqzsywgz/201208/W020130929345948738150.pdf However, Entrust does not list the sub-CA certificate here: http://www.entrust.net/about/third-party-sub-ca.htm As far as I can see, there are several explanations for that: * It was omitted by accident. * The CNNIC root was signed (although only signatures on the intermediate CNNIC SSL CA certificate have been documented so far, I think). * Entrust assumes that once an organization has a root in the Mozilla program, any sub-CAs controlled by that organization is exempted from disclosure. * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. The CNNIC CPS is incorrect. The intermediate certificate which Entrust issued to CNNIC has expired in March 1, 2012. The certificate was never reissued. Please note that the intermediate certificate was issued from a 1024-bit RSA root which has been removed from Firefox. Also note that the intermediate certificate had a pathlength of 0. This pathlength means that the Entrust root would not provide trust to any intermediate which CNNIC issued. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On 25/03/15 10:27, Florian Weimer wrote: * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. I believe this is the correct answer. Quoting Bruce Morton in this thread: Please note that the intermediate certificate which Entrust issued to CNNIC expired in 2012 and was not extended. Also note that the Basic Constraints had a path length of 0; as such the trust would not have extended to intermediates issued by CNNIC. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
Le mercredi 25 mars 2015 07:02:06 UTC+1, Daniel Micay a écrit : * Browser people detected this misissuance This one, but not at least several others issued by this CA. Are you still talking about facts? Then please provide other mississued certificates. * CAs don't want to go out of business That's why browser vendors have more far more power than you're willing to admit. You can kill their business by changing one a line of code... Does killing CA business create a shining new good world free of all Evil(tm)? * Even if by some chance you had the solution, you're going to have a hard time getting heard now The people who voiced strong, justified concerns against including this CA weren't heard before. I doubt I'm saying anything that hasn't already been said before on discussions you've read. They were heard. Their concerns were shared and studied. They weren't able to provide convincing arguments that the CA acted badly *as a CA*. That's different *now*, and while we *now* have good arguments they behaved badly, but it doesn't make the past 5 years of rant more true. Get your timeline straight. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Daniel Micay: In other words, if you want the responsible choice to be made in these cases then you should be contacting news publications to shame Mozilla into doing the right thing - not a Mozilla mailing list. Ugh, surely there has to be a better way. I sometimes get carried away and post acerbic comments about things like the dynamics of maintaining a market share (sorry about that), but what you propose is totally over the top. The present can of worms is not just about an unwillingness to do the right thing (whatever that is), but there are one or two unsolved engineering problems involved. You simply can't make those go away by media pressure. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, March 24, 2015 11:26 am, Kai Engert wrote: Thoughts? I don't believe this is reasonable/responsible. For example, is it your intent to prevent Let's Encrypt from becoming cross-certified? That's the effect of this proposal. For example, is your intent to prevent Google from running its own intermediate for its properties? That's the effect of this proposal. If it is, I think you're mistaken. If it is not, then I think that can demonstrate why the proposal is broken. The current Mozilla Policy sets forth sensible guidelines for how to deal with and manage this situation. It, along with the Baseline Requirements, requires both Point-in-Time Readiness Assessments and Period-of-Time Audits for such intermediates; a PITRA before, a POT after 60 and before 90 days. This is no different than Mozilla's requirements for root inclusions. The fundamental difference between a sub-CA such as Let's Encrypt or Google Internet Authority G2 and a Root CA is that the CP/CPS has not yet been publicly reviewed. However, Mozilla updated the program requirements in v2.1 to require disclosure. The work of Kathleen to further streamline such disclosures (via Salesforce) represents a further accumulation of machine-readable data for such discussions and eventual public review. The cross-certifying CA certainly bears responsibility for those that they have certified, a necessary tradeoff of circumventing the public review. However, we must consider such subordinate failures as if it was the root had done it, and carefully evaluate the circumstances surrounding it. Your proposal fails to do this, and in short only recognizes Technically Constrained sub-CAs as valid. I think that is mistaken, for all the reasons that have been discussed repeatedly during such conversations on technical constraints. Name constraints are simply insufficient here, nor is it fair to assume that the failings of one CA are representative of the ecosystem. Hopefully you will be able to incorporate this feedback, as well as the past three years' worth of discussion surrounding this, to find a proposal that doesn't throw the baby out with the bathwater. If this is intended to be a response to CNNIC, I think the policies are and have been clear on this. I also think extreme care is needed before proposing blanket zero-tolerance policies. It's no accident that no program spells those out - it's a recognition of complexities. Even the few places in the Baseline Requirements that spell out hard actions - such as revocation periods - have and do cause real and painful service disruptions, and need revamping. If you're not sure what I'm referring to, [1] provides further context. Cheers, Ryan [1] https://cabforum.org/pipermail/public/2015-March/005288.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
Okay, so if a CA doesn't want to cause a service disruption for their customers when this happens, they will implement CT. You can remove their certificate and make a press release saying you wouldn't have distrusted their old certificates if they implemented CT. I'm sure CT will jump to the top of the priority lists of most CAs. Browser / OS vendors really do hold all of the cards here. The CAs have to beg for inclusion and go to extreme lengths to prove trust if you feel like requiring it, but you don't. I don't see how it's anything but a technical issue, and you're more than up to solving it. That's not a zero tolerance policy. It's an example of compromise where in exchange for more lenience, the CAs have to do something. You have to demonstrate that they have something to gain by showing that the policies have teeth though. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, March 24, 2015 2:50 pm, Daniel Micay wrote: There's no service disruption caused by not trusting any certs from the CA created after say, 3 weeks from now. They utterly failed to comply with numerous rules and if those policies have any real teeth behind them their time as a trusted root is over. If it remains as a trusted root, it's simply demonstrating to every other CA that compliance with those policies is unimportant as has been done in the past. Except this fundamentally doesn't work, on a technology level. The CA is responsible for setting the issuance dates of the certificates. If you don't trust the CA, you cannot use those dates. This is the same problem with Code Signing certificates (and other forms of signatures), and why Time Stamping Authorities exist. You need a counter-signature to assert the time at which the certificate was issued. Now, we could go define a TSA for X.509v3 TLS certs, which is slightly problematic because a TSA is a counter-signature and there's no good means to smuggled counter-signatures for TLS without going proxy certs. Or we could use Certificate Transparency, in which the SCT acts as a lighter weight (but less secure) TSA counter-signature, since the SCT issued by the log has a timestamp (set by the log) as to when it was observed/issued. Regardless, you're extremely optimistic, well beyond the point of realistic, if you think a CA can execute such turn-around on a dime, of which three weeks is. And it would still mean distrusting any/all certificates prior to the 'distrust' date because they lacked actionable establishment of the time at which they're issued. I don't mean to suggest these problems aren't solvable, but they certainly aren't as easy or managable as you might think. On the Chrome side, we're actively investing in and investigating this. To yield the most long-term viable result, supporting CT seems a reasonable path towards having reliable time stamping, so that informed decisions, including Accepting all the certs in the past, but none in the future or Only accepting certs that have been logged can offer a greater degree of public transparency, while minimizing disruption. But zero-tolerance policies aren't the same as that. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
That's not a zero tolerance policy. It's an example of compromise where in exchange for more lenience, the CAs have to do something. You have to demonstrate that they have something to gain by showing that the policies have teeth though. (removing a shiny green bar signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, March 24, 2015 3:11 pm, Daniel Micay wrote: That's not a zero tolerance policy. It's an example of compromise where in exchange for more lenience, the CAs have to do something. You have to demonstrate that they have something to gain by showing that the policies have teeth though. Daniel, It's difficult to have a discussion with you when you mount attacks (This happened because of your negligence / Can you please stop pretending that the people involved in PKI are responsible) and then change the goalposts and definition arbitrarily and capriciously (That's not a zero tolerance policy, when Kai's proposal is just that) I can understand you're excited to discuss this topic, but it would be helpful to be more productive in the commentary, and recognize the messages being replied to. As it stands, Kai's proposal is problematic, for the reasons I've addressed. There is still a service disruption for every CA, it's just a service disruption you view as acceptable because They should have used CT. That doesn't make it not a service disruption, and it doesn't make it not zero-tolerance. Regardless of your feelings towards this particular incident, I think we can agree that a world where every domain holder could, in event of a CA compromise, validate that the compromised CA had not misissued certificates by examining the public logs, of which all certificates were required to be logged, is a good world. A world in which we can say All currently disclosed certificates are and remain trusted; no new certificates are trusted is also a world in which we can make more informed decisions regarding misissuance. Those are worlds we want to go to. But they're neither the end-state nor are they wholly sufficient. And while it's good to keep those potentialities in mind, it's also good to recognize there are some worlds that we wouldn't want. I don't think we'd want a world in which Let's Encrypt could not exist, or which would be functionally delayed for 10 years. That benefits no one. This proposal would require that - and even more, greater disruption for any CA that disagreed and tried to help make Let's Encrypt a reality. These are things we can discuss. Personal attacks? Those would best be left for another forum. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
To be fair, Debian and other projects have even lower security standards. That is, they still mark CACert as secure for SSL in stable (how is that not a security update relevant, even if fixed in Untable?!) CACert is not nearly as bad as many of the CAs Mozilla actually considers to be trustworthy. It still has a pile of crap codebase and their auditing is very lacking, but at least you can see all the information on where they're going wrong and right. AFAIK, they haven't ever been hacked or issued any crazy invalid certs. They were removed because they weren't too big to fail and aren't willing or financially able to bribe their way through auditing. Why are Comodo, TurkTrust, CNNIC and others still in the trust database? It's money that matters, not security. It's a joke. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, March 24, 2015 4:44 pm, Daniel Micay wrote: They're willing to set the security standards *really low* because all that matters is market share. I can't really understand how they ended up in the position of having the dominant trust store used by FOSS projects. Debian and other projects should move away from simply shipping Mozilla's trust store as-is ASAP. To be fair, Debian and other projects have even lower security standards. That is, they still mark CACert as secure for SSL in stable (how is that not a security update relevant, even if fixed in Untable?!), haven't updated the ca-certificates package to remove any of the CAs that Mozilla removed for lack of current audits or modern crypto, and still include *as trusted for SSL* all the certificates that can't even match Mozilla's requirements for SSL (usually because of a lack of audits). The two most important things for managing a root store: - Keep it updated - Keep on top of the audits For what you decry about the Mozilla process, it's community driven and excels at those two things, which is exactly how it became the dominant trust store. But yes, Debian moving away from what they do today would be great, if only because their current use is even worse than you describe Mozilla's. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
Take a few deep breaths. Just breathe. There. Good. If that's what helps you sleep at night. It remains a fact that browser vendors chose to hand the keys to the castle to an organization known at the time to be one of the largest distributors of malware in the world. I'm not talking broadly about the Chinese government but specifically about the CNNIC. Hard to see how this is a surprise... The discovered certificate is the tip of the iceberg. If they weren't following a dozen rules here, do you think they were elsewhere? signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Forbid creation of non-constrained intermediates for external entities
This is a suggestion for stricter rules regarding the creation of intermediate CA certificates that are issued by root CA certificates included in the Mozilla CA list. Every CA organization should be ultimately responsible that the intermediate CA certificates they create will never be used in a MITM device. If an intermediate CA certificate controlled by the CA, or controlled by a subordinate entity of the CA, is used in a MITM device, or used to mis-issue a certificate, the discovery of an unrevoked mis-issued certificate will result in the immediate removal of the respective root CA certificate. If a CA provides an intermediate CA certificate to an external organization, then the intermediate CA certificate must contain a name constraint extension, which restricts the abilities of the intermediate. The constraint must either limit the intermediate to (a) a set of second level domains the external organization controls. or (b) to exactly one TLD The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. If the CA issues an intermediate CA that is constrained to a TLD, then the primary CA is fully responsible for the actions of the external organization, including deliberate and accidental misuse of the intermediate. A misuse of the intermediate, or a misuse of any subordinate certificate, is the full responsibility of the primary CA. Because of the potential consequences of a misuse of an intermediate for the primary CA, it is recommeded that a CA shall be very careful when handing out an intermediate to an external organization, such as enclosing the intermediate's key in an HSM, and requiring a contract with the external organization, which would cover the monetary risk of closing down the business of the primary CA. The discovery of any misuse of where the primary CA has the full reponsiblity shall result in the immediate removal of the CA from the Mozilla list. Thoughts? Thanks, Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, 2015-03-24 at 14:52 -0400, Daniel Micay wrote: Thoughts? I think it's a good policy, but like the current policies it cannot really be enforced because there is no way to validate compliance. At least there'd be clarity about the immediate removal on discovery. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
At least there'd be clarity about the immediate removal on discovery. I find it hard to believe that a business centered entirely around the CA business would self-report this or any other issue if they knew it would lead to removal. At the moment, the only incentive to report is the potential greater damage from not doing it. If the entire business is a CA and it's removed, then it's over. They have no incentive to comply with a policy that would bankrupt them. In fact, I'd expect that they could easily get in trouble for not looking out for shareholder interests if they comply with a policy that's above and beyond what is required by law. Is there any legal weight behind the policies? Mozilla is fine with continuing to empower a Chinese government apparatus with the ability to MITM people around the world, even after they are caught red-handed with such a certificate issued. Hard to believe any explanation they offer about the existence of said certificate. It's not hard for the Chinese military to set up a shell company in the Middle East. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? Clearly, the removal of an actually relevant root CA from the trust store is not going to happen because the user impact and subsequent reduction in browser market share. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tuesday, March 24, 2015 at 3:41:50 PM UTC-4, Florian Weimer wrote: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? Clearly, the removal of an actually relevant root CA from the trust store is not going to happen because the user impact and subsequent reduction in browser market share. Please note that the intermediate certificate which Entrust issued to CNNIC expired in 2012 and was not extended. Also note that the Basic Constraints had a path length of 0; as such the trust would not have extended to intermediates issued by CNNIC. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Daniel Micay: These rules would be a lot more meaningful if any new additions to the trust store were required to have Certificate Transparency implemented for the sake of auditing, along with a deadline for other CAs to put it in place. CT would have meant this was trivially caught *much* earlier by security researchers. That depends on how many legitimate gmail.com certificates are out there. Organizations struggle to keep track of their own certificates. It's difficult to see how relative outsiders (and most “security researchers” are) can cope with that, except by raising an alarm about everything they see (which is not generally helpful). There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On 24/03/15 04:10 PM, Daniel Micay wrote: On 24/03/15 03:40 PM, Florian Weimer wrote: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? Clearly, the removal of an actually relevant root CA from the trust store is not going to happen because the user impact and subsequent reduction in browser market share. They are not going to enforce the policies unless there is negative news coverage that outweighs whatever risk of losing market share they see from calling connections insecure when are known to be insecure. In other words, if you want the responsible choice to be made in these cases then you should be contacting news publications to shame Mozilla into doing the right thing - not a Mozilla mailing list. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On 24/03/15 03:58 PM, Florian Weimer wrote: * Daniel Micay: These rules would be a lot more meaningful if any new additions to the trust store were required to have Certificate Transparency implemented for the sake of auditing, along with a deadline for other CAs to put it in place. CT would have meant this was trivially caught *much* earlier by security researchers. That depends on how many legitimate gmail.com certificates are out there. Organizations struggle to keep track of their own certificates. It's difficult to see how relative outsiders (and most “security researchers” are) can cope with that, except by raising an alarm about everything they see (which is not generally helpful). There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. In the case of gmail.com, any certificate not valid with the pinning in Chromium is highly suspicious. There may be some false positives, but running it by the organization behind the domain can confirm it. You may even get a bounty for finding something like this... If they're not able to confirm or deny the validity of the certificate, that's a separate juicy scandal. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On 24/03/15 03:40 PM, Florian Weimer wrote: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? Clearly, the removal of an actually relevant root CA from the trust store is not going to happen because the user impact and subsequent reduction in browser market share. They are not going to enforce the policies unless there is negative news coverage that outweighs whatever risk of losing market share they see from calling connections insecure when are known to be insecure. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
