Thanks for your so detail instruction. Yes, we are improved. The two case is happened in 2015 and the mis-issued certificate period is only 5 months that we fixed 3 big bugs during the 5 months. For CT, we will improve the posting system.
Regards, Richard > On 1 Sep 2016, at 12:44, Ryan Sleevi <[email protected]> wrote: > >> On Wednesday, August 31, 2016 at 8:05:57 PM UTC-7, Richard Wang wrote: >> First, please treat WoSign as a global trusted CA, DON'T stamp as China CA. >> We need a fair treatment as other worldwide CAs that I am sure WoSign is not >> the first CA that have incident and not the serious one; > > I would have hoped, through all of this, that you would have come to realize > the seriousness and gravity of the multiple problems that WoSign has had over > the past 18 months, rather than continue to dismiss it. > > You misissued certificates to people who were not authorized. Repeatedly. In > multiple separate instances. > > You have had multiple issues with adhering to the Baseline Requirements, and > those have not been disclosed, to your auditors or browsers. Consider > Incident -1, which was not listed here in this thread yet, on April 4, 2015, > which caused you to update your CPS ( > http://www.wosign.com/policy/wosign-policy-1-2-10.pdf ) to correct several > issues that Google reported to you regarding non-compliance to your stated > policies and to the BRs. > > Ultimately, CAs are based on trust: > - Trust that they're performing the necessary validation and vetting > procedures > - Trust that they are securing their internal systems from both internal and > external threats > - Trust that they understand the seriousness of their role as a provider of > global certificates, any of which might be used to compromise or attack > users, and take adequate steps to ensure the correctness of those operations. > > Your responses, unfortunately, have done little to instill or affirm that the > trust is well placed. Even more so, you're a CA authorized to issue the most > rigorous certificates available (Extended Validation), and so the bar is set > even higher for your operational controls and processes! > > - You failed to understand the gravity of the misissuance, and thus failed to > revoke these certificates. I would argue this constitutes a further BR > violation itself, per Section 4.9.1.1 of the BRs ( > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf ), in > particular, Items 4 and Items 9 in that list, but would be curious if you > disagree. > - You have repeatedly suggested this was an honest mistake, suggesting it was > a singular issue, when the reality is that it is a pattern of mistakes that > have spanned over a year and have led to multiple misissued certificates. > - These incidents - including the issue with the CPS page - suggest a > software development methodology that fails to adequately ensure the > robustness of the systems, and fails to understand the security risks that > must be mitigated in such systems. > > When there are concerns that undermine trust, it's important to engage to > restore trust, and so I truly appreciate your involvement in these > discussions, and your efforts to restore that trust. And while it's > understandable that, in any security incident, there will be disagreements > regarding severity or impact, it's vitally important for an entity whose > product depends on trust takes steps to understand the issues, understand the > perspectives, and takes a careful look to understand why so many people are > disagreeing with the risk assessment or mitigation strategy. > >> Third, I believe no one dare to say his system no bug, WoSign admitted we >> have system bug that issued the wrong certificate and fixed. > > Alternatively, WoSign dismissed the need to revoke the certificates, despite > knowing that they were not validated according to the BRs, routinely violated > their CPS, failed to notify either browsers or their auditors of these > issues, all while violating other provisions of the Baseline Requirements > that were disclosed - such as duplicate serials and SHA-1 certificates. > > This is a vast departure from, say, the thread last month - > https://groups.google.com/d/msg/mozilla.dev.security.policy/9QKw1C3m4Lo/nkg1rcJyAgAJ > - and shows how significant the gap in perception and user trust can be, > based on how a CA handles an incident and the subsequent public discussion. > >> This is why WoSign is the first CA in the world for volunteering to "Require >> CT", we like to use CT mechanism to find out the bug quickly and reduce the >> lost to minimum, we logged all issued certificate to CT log server and >> embedded SCT data to certificate since July 5th. Thanks for Google invent so >> good transparency system. > > And yet, although you've committed to logging your certificates, your logging > has failed to abide by the one policy that exists for CT logging - the > Chromium CT policy ( > https://www.chromium.org/Home/chromium-security/certificate-transparency ). > > While it's laudable that you're logging your certificates at all, there's two > important pieces being omitted here: > - By only logging to Google logs, you're not necessarily improving trust, > because now the burden is to trust Google. > - This is an issue I personally informed you about and discussed at length > with you on May 25, 2016. > > For example, as highlighted in the message you're replying to, if Chrome were > to do what you requested - and require CT for WoSign certificates - few to > none of the WoSign certificates issued since would be trusted. > > Consider this Precertificate - https://crt.sh/?id=30466652 - and its > associated certificate, https://crt.sh/?id=30468277 - which you only logged > to Google's Pilot and Aviator logs. That means that in order to trust WoSign > certificates, you'd have to trust Google as a single point of trust - which, > as I highlighted earlier, is something even Google isn't willing to ask of > the public. > >> Finally, I am very sorry to all browsers that we don't execute the incident >> report policy properly, WoSign get a deep lesson for how to deal with this >> kind of incident now, I wish everyone give us a chance to be a good boy, at >> least one-time chance. Thanks a million. > > Don't you believe the evidence shows you've already been given multiple > chances, and yet continue to unfortunately find new and distinct ways to > misissue certificates? At what point should the community say that enough is > enough? That's fundamentally the question here. > > I realize this may seem like a debate between there "three incidents" > (although there have been at least two more BR violating incidents, as > highlighted in this message) and "four incidents" (giving you one more > chance), but a key goal of this thread was to question whether or not it was > believed that WoSign would improve. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
