Hi Peter, Thanks for your guesses. Buy no those issues in our system.
Best Regards, Richard -----Original Message----- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Friday, July 14, 2017 8:55 AM To: Richard Wang <rich...@wosign.com> Cc: r...@sleevi.com; Jonathan Rudenberg <jonat...@titanous.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: WoSign new system passed Cure 53 system security audit Richard, I can only guess what Ryan is talking about as the report wasn't sent to this group, but it is possible that the system described could not meet the Baseline Requirements, as the BRs do require certain system designs. For example, two requirements are: "Require that each individual in a Trusted Role use a unique credential created by or assigned to that person in order to authenticate to Certificate Systems" and "Enforce multi-factor authentication for administrator access to Issuing Systems and Certificate Management Systems" If the system does not do these things, then it "cannot meet the BRs, you would have to change that system to meet the BR" (quoting Ryan). Please keep in mind that these are only guesses; there are numerous other things that could be the report that could lead to the same conclusion. Thanks, Peter On Thu, Jul 13, 2017 at 5:04 PM, Richard Wang via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
