Hi Ryan, Thanks for your detail info.
But I still CAN NOT understand why you say and confirm that the new system cannot and does not comply with BR before we start to use it. We will do the BR audit soon. Best Regards, Richard On 14 Jul 2017, at 00:50, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> wrote: You will fail #4. Because your system, as designed, cannot and does not comply with the Baseline Requirements. As such, you will then (4.1) Update new system, developing new code and new integrations (4.2) Engage the auditor to come back on side (4.3) Hope you get it right this time (4.4) Generate a new root (4.5) Do the PITRA audit and hopefully pass (4.6) Hope that the security audit from #1 still applies to #4.1 [but because the changes needed are large, it's hard to imagine] (5) Apply for the new root inclusion The system you had security audited in #1 cannot pass #4. That's why working with an auditor to do a readiness assessment in conjunction with or before the security assessment can help ensure you can meet the BRs, and then ensure you can meet them securely. On Thu, Jul 13, 2017 at 11:04 AM, Richard Wang <rich...@wosign.com<mailto:rich...@wosign.com>> wrote: Hi Ryan, I really don't understand where the new system can't meet the BR, we don't use the new system to issue one certificate, how it violate the BR? Our step is: (1) develop a new secure system in the new infrastructure, then do the new system security audit, pass the security audit; (2) engage a WebTrust auditor onsite to generate the new root in the new system; (3) use the new audited system to issue certificate; (4) do the PITRA audit and WebTrust audit; (5) apply the new root inclusion. While we start to apply the new root application, we will follow the requirements here: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 to demonstrate we meet the 6 requirements. We will discard the old system and facilitates, so the right order should be have-new-system first, then audit the new system, then apply the new root inclusion. We can not use the old system to do the BR audit. Please advise, thanks. Best Regards, Richard On 13 Jul 2017, at 21:53, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> wrote: Richard, That's great, but the system that passed the full security audit cannot meet the BRs, you would have to change that system to meet the BRs, and then that new system would no longer be what was audited. I would encourage you to address the items in the order that Mozilla posed them - such as first systematically identifying and addressing the flaws you've found, and then working with a qualified auditor to demonstrate both remediation and that the resulting system is BR compliant. And then perform the security audit. This helps ensure your end result is most aligned with the desired state - and provides the public the necessary assurances that WoSign, and their management, understand what's required of a publicly trusted CA. On Wed, Jul 12, 2017 at 10:24 PM, Richard Wang <rich...@wosign.com<mailto:rich...@wosign.com>> wrote: Hi Ryan, We got confirmation from Cure 53 that new system passed the full security audit. Please contact Cure 53 directly to verify this, thanks. We don't start the BR audit now. Best Regards, Richard On 12 Jul 2017, at 22:09, Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> wrote: On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang <rich...@wosign.com<mailto:rich...@wosign.com>> wrote: Hi all, Your reported BR issues is from StartCom, not WoSign, we don't use the new system to issue any certificate now since the new root is not generated. PLEASE DO NOT mix it, thanks. Best Regards, Richard No, the BR non-compliance is demonstrated from the report provided to browsers - that is, the full report associated with this thread. That is, as currently implemented, the infrastructure for the new roots would not be able to receive an unqualified audit. Further system work is necessary, and that work is significant enough that it will affect the conclusions from the report. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
