On Friday, October 7, 2016 at 4:13:42 AM UTC-7, Gervase Markham wrote: > As noted by Richard Wang, WoSign have just published an updated Incident > Report: > https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf > > I think we are now in a position to discuss whether the plan proposed here: > https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit# > is still appropriate for WoSign. > > Because it contains repeated or lightly-updated information about all of > the issues on the issues list, the updated Incident Report rather > "buries the lede" (hides the important news). Therefore I felt it might > be worth highlighting some of the things within it: > > * WoSign admits that it has issued 64 back-dated SHA-1 certificates. The > cause was a mixture of intentional issuance using a created pathway, and > bugs which triggered that pathway by mistake. > > * This includes admitting the misissuance of the certificates for > tyro.com by StartCom, which were the subject of Mozilla's most recent > investigation; this issuance was approved by Richard Wang. > > * WoSign agrees it should have been more forthcoming about its purchase > of StartCom, and announced it earlier. > > * WoSign and StartCom are to be legally separated, with the corporate > structure changed such that Qihoo 360 owns them both individually, > rather than WoSign owning StartCom. > > * There will be personnel changes: > > - StartCom’s chairman will be Xiaosheng Tan (Chief Security Officer > of Qihoo 360). > - StartCom’s CEO will be Inigo Barreira (formerly GM of StartCom > Europe). > - Richard Wang will be relieved of his duties as CEO of WoSign and > other responsibilities. It is not decided who will replace him. > > * StartCom will soon provide a plan on how they will separate their > operations and technology from that of WoSign. > > * In the light of these changes, Qihoo 360 request that WoSign and > StartCom be considered separately. > > > Mozilla is minded to agree that it is reasonable to at least consider > the two companies separately, although that does not preclude the > possibility that we might decide to take the same action for both of > them. Accordingly, Mozilla continues to await the full remediation plan > from StartCom so as to have a full picture. However, I think we can work > towards a conclusion for WoSign now. > > Gerv
Gerv, Could you explain how Mozilla feels this line of reasoning and explanation is different than, say, how Mozilla handles Symantec inclusion requests? For example, it seems you're suggesting that: * This was the result of rogue employees acting outside of appropriate policies * The people responsible have been sacked, and everyone will undergo retraining * Systems will be updated to prevent misissuance in the future This response is very similar to that offered by Symantec when news of their misissuance first came to light, but it was later revealed that the issues were much deeper, much more systemic, and continued to persist well beyond the dates it was claimed for remediation. I mention this not to suggest that StartCom is the same as Symantec, but to highlight precisely how this seems like this seems to move from a neutral, consistent standard, into one that favors some CAs while not treating others equally. For example, it was suggested that there would be a similar investigation into StartCom as there was with WoSign, with a gathering of issues for public discussion. Is that still the plan? It sounds like you're suggesting that Mozilla has reached some agreement for remediation with StartCom independent of WoSign, despite these two companies having the same management structure for the past year, despite having undergone significant infrastructure changes (which are trivially observable by outsiders, both via CT and via interactions with the CA), and, as evidenced by StartEncrypt, sharing significant development infrastructure. Both represent to the same parent company, which allowed these issues to happen in the first place, so what assurances do the public have that they won't happen again? I appreciate the consideration to the ecosystem - particularly, the desire to avoid the need to distrust a CA, which might result in a poor user experience. However, I'd be curious to better understand how Mozilla prioritizes that over the ecosystem risk and implications of such a decision. For example, this would suggest that, if a company wished to minimize risk of it's misissuances - or to actively engage in the practice while limiting liability - it might separate out certificates into subsidiary companies. They could then fully share infrastructure, development, etc - but only the one that actively "misissued" would be penalized, while the other sister companies (which share the same 'everything') could continue to be trusted, so long as the deck chairs were reshuffled after every iceberg. I appreciate the sensitivities towards a situational approach - considering the facts around the misissuance and not just the policies themselves - but this does seem to create a dangerous precedent, if gone forward with, that could have significant negative consequences to the ecosystem in the future. The issues we've seen here are clearly systemic, and reflected throughout the organization - the development and security practices, the clear disregard for the stated policies and practices, and the obvious disconnect in messaging. I can appreciate that Qihoo 360 may not have realized how problematic some of these practices were with respect to WoSign, but that should moreso be a cause for concern, rather than reprieve, since we have no assurances things will improve. In a separate thread regarding SHA-1 exception process, you highlighted that the ecosystem around root inclusion has failed to improve, resulting in risks being borne by the WebPKI, due to the lack of risk or cost for these "exceptional" situations where customers ignore communications and changes in the security landscape. I'm curious if Mozilla feel's that the CA market is different, as it would seem to be suggested here. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
