WoSign new system passed Cure 53 system security audit

[Danny 吴熠]

Hi all,



This is Danny from WoSign.



As per requirements, WoSign new issuing infrastructure has been completed and passed the Cure 53 white box security audit successfully in June 27. Cure53 is approved by Mozilla. The full audit report has been sent to Mozilla and other browsers. The Summary Report for public is available here:

https://www.wosign.com/Docdownload/WoSign%20system%20code%20security%20audit%20report%20summary%2020170627.pdf.



Best regards,



Danny Wu

Compliance Coordinator

Risk Control & Compliance Department

WoSign CA Limited

[Matt Palmer]

On Fri, Jul 07, 2017 at 06:12:58AM +0000, Danny 吴熠 via dev-security-policy wrote:
> As per requirements, WoSign new issuing infrastructure has been completed
> and passed the Cure 53 white box security audit successfully in June 27.
> Cure53 is approved by Mozilla. The full audit report has been sent to
> Mozilla and other browsers. The Summary Report for public is available
> here:
>
> https://www.wosign.com/Docdownload/WoSign%20system%20code%20security%20audit%20report%20summary%2020170627.pdf.

This report doesn't contain anything of value. It says "we found things,
they were fixed". OK, but what *were* those things? How do they reflect
the maturity of the WoSign SDLC processes? Do they indicate anything
meaningful about the larger issues that caused WoSign to be distrusted?

Without the full report being made public, I don't think any useful
conclusions can be drawn from this audit.

- Matt

[Itzhak Daniel]

Mr. Wang is mentioned on the end of the document, what is Richard Wang current official responsibility of Mr. Wang at WoSign?

According to the incident report, release on October 2016 [1], Mr. Wang was suppose to be relieved of his duties as CEO, this is mentioned in 3 separate paragraphs (P.17,P.25,P.26).

Links:
1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf

[Richard Wang]

Mr Wang is the COO now according to Mr. Tan's public announcement on March CAB Forum meeting.

CEO is still N/A, if anyone is interesting in the CEO position, please send your Resume to Mr. Tan.


Best Regards,

Richard

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Eric Mill]

So who acts as the CEO for WoSign when final executive decisions need to be
made?

--
konklone.com | @konklone <https://twitter.com/konklone>

[Richard Wang]

The important thing is by the board of directors, the Company Legal Representative is changed to Mr. Shi Xiaohong, VP of 360.



The daily operation thing is by COO.





Best Regards,



Richard

From: Eric Mill [mailto:er...@konklone.com]
Sent: Monday, July 10, 2017 10:12 AM
To: Richard Wang <ric...@wosign.com>
Cc: Itzhak Daniel <itk9...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

So who acts as the CEO for WoSign when final executive decisions need to be made?





On Sun, Jul 9, 2017 at 9:41 PM, Richard Wang via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

Mr Wang is the COO now according to Mr. Tan's public announcement on March CAB Forum meeting.

CEO is still N/A, if anyone is interesting in the CEO position, please send your Resume to Mr. Tan.


Best Regards,

Richard


-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosig...@lists.mozilla.org<mailto:wosig...@lists.mozilla.org>] On Behalf Of Itzhak Daniel via dev-security-policy
Sent: Monday, July 10, 2017 4:57 AM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: WoSign new system passed Cure 53 system security audit

Mr. Wang is mentioned on the end of the document, what is Richard Wang current official responsibility of Mr. Wang at WoSign?

According to the incident report, release on October 2016 [1], Mr. Wang was suppose to be relieved of his duties as CEO, this is mentioned in 3 separate paragraphs (P.17,P.25,P.26).

Links:
1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf

_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy







--

konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>

[Richard Wang]

Please note that the Mozilla requirement is:

" 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
" [3] The auditor must be an external company, and approved by Mozilla. "

That WoSign did it very well -- PASS the full security audit.

And Richard Wang leading the RD team have done a good job for the new system development and passed the security audit.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Percy via dev-security-policy
Sent: Monday, July 10, 2017 12:41 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

So it seems that Richard Wang still has the final executive decisions regarding security in daily operations. Basically WoSign simply changed the title of the position from CEO to COO and bypassed Mozilla's requirement?

https://lists.mozilla.org/listinfo/dev-security-policy

[Itzhak Daniel]

On Monday, July 10, 2017 at 9:00:04 AM UTC+3, Richard Wang wrote:
> " 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by Mozilla. "

What is the source?

According to this thread [1]:
"1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements."

One of these changes is to remove the person responsible for:
1. Releasing unsecured and not fully tested software that allowed issuing certificates for Github without proper checks.
2. Back-dating SHA1 certificates.
3. Secretly purchasing another CA without disclosing it to Mozilla.
4. Actively lying and misleading about 2 and 3.

To my understanding, from reading the "Remediation Plan", one of the requirements made for WoSign by itself/parent company, is to remove the person responsible for most of the issue caused them to lose the trust bit.

I'm not in *any* position to tell who shell manage the daily operations of WoSign, but it gives a strong indication that nothing had really changed.

Links:
1. https://groups.google.com/d/msg/mozilla.dev.security.policy/BV5XyFJLnQM/_DwiB1PDGQAJ

[Richard Wang]

I think you found the source: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824

Please note this email topic is just for releasing the news that WoSign new system passed the security audit, just for demonstration that we finished item 5:

" 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
" [3] The auditor must be an external company, and approved by Mozilla. "

NOT for the new root inclusion application.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Itzhak Daniel via dev-security-policy
Sent: Monday, July 10, 2017 2:39 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: WoSign new system passed Cure 53 system security audit

On Monday, July 10, 2017 at 9:00:04 AM UTC+3, Richard Wang wrote:

> " 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by Mozilla. "

What is the source?

According to this thread [1]:
"1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements."

One of these changes is to remove the person responsible for:
1. Releasing unsecured and not fully tested software that allowed issuing certificates for Github without proper checks.
2. Back-dating SHA1 certificates.
3. Secretly purchasing another CA without disclosing it to Mozilla.
4. Actively lying and misleading about 2 and 3.

To my understanding, from reading the "Remediation Plan", one of the requirements made for WoSign by itself/parent company, is to remove the person responsible for most of the issue caused them to lose the trust bit.

I'm not in *any* position to tell who shell manage the daily operations of WoSign, but it gives a strong indication that nothing had really changed.

Links:
1. https://groups.google.com/d/msg/mozilla.dev.security.policy/BV5XyFJLnQM/_DwiB1PDGQAJ

[okaphone.e...@gmail.com]

On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>
> Please note this email topic is just for releasing the news that WoSign new system passed the security audit, just for demonstration that we finished item 5:
> " 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by Mozilla. "

It also seems a bit strange to report item 5 "successfully completed" before we hear anything about the other items. How about starting with item 1? What are your plans voor fixing the problems?

[Jonathan Rudenberg]

> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>>

>> Please note this email topic is just for releasing the news that WoSign new system passed the security audit, just for demonstration that we finished item 5:
>> " 5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed. "
>> " [3] The auditor must be an external company, and approved by Mozilla. "
>

> It also seems a bit strange to report item 5 "successfully completed" before we hear anything about the other items. How about starting with item 1? What are your plans voor fixing the problems?

It’s worth noting that the problems have not stopped yet. There are a bunch of certificates issued over the past few months that do not comply with the Baseline Requirements issued from the new "StartCom BR SSL ICA”, for example:

https://crt.sh/?opt=cablint&q=8BDFE4A526BFB35C8A417B10F4D0ABE9E1D60D28A412539D5BC71C19B46FEF21
https://crt.sh/?opt=cablint&q=124AAD38DAAC6B694D65F45226AB5152FC46D229CBC203E0814D175F39977FF3
https://crt.sh/?opt=cablint&q=9B78C78B32F4AC717B3DEFDABDACC4FEFA61BFD17782B83F75ADD82241147721
https://crt.sh/?opt=cablint&q=AAB0B5A08F106639A5C9D720CD37FDB30E7F337AEBAF9407FD854B5726303F7B
https://crt.sh/?opt=cablint&q=9DCE6A924CE837328D379CE9B7CDF4A2BA8A0E8EC01018B9DE736EBC64442361
https://crt.sh/?opt=cablint&q=62A9A9FDCDC04A043CF2CB1A5EAFE33CF9ED8796245DE4BD5250267ADEFF005A
https://crt.sh/?opt=cablint&q=6A72FA5DCC253D2EE07921898B9A9BB263FD1D20FE61B1F52F939C0C1C0DCFEE
https://crt.sh/?opt=cablint&q=238E2E96665748D2A05BAAEEC8BAE6AFE7B7EF4B1ADA4908354C855C385ECD81
https://crt.sh/?opt=cablint&q=C11C00EB0E14EEB30567D749FFD30445E0B490D1DCA7B7E082FD1CB0A40A71C0
https://crt.sh/?opt=cablint&q=4DEF4CFD21A969E8349E4428FDEC73767C01DE6127843312511B71029F4E3836

[Ryan Sleevi]

On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via

dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

>
> > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> >
> > On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
> >>

> >> Please note this email topic is just for releasing the news that WoSign
> new system passed the security audit, just for demonstration that we
> finished item 5:
> >> " 5. Provide auditor[3] attestation that a full security audit of the
> CA’s issuing infrastructure has been successfully completed. "
> >> " [3] The auditor must be an external company, and approved by Mozilla.
> "
> >

It's worth noting that, on the basis of the security audit report full
details shared by WoSign, the system that was security audited does not
comply with the Baseline Requirements, nor, as designed, can it. The system
would need to undergo non-trivial effort to comply with the Baseline
Requirements.

[Alex Gaynor]

Is this a correct summary:

- The report included here is supposed to fulfill the network security test
portion of the BRs
- This report does not attest to BR compliance (or non-compliance)
- To complete an application for the Mozilla Root Program, WoSign would be
required to additionally provide a WebTrust audit (or equivalent, as
described in the Mozilla PKI Policy section 3.1)
- Based on your reading of the complete network security test, you would
not expect WoSign to be able to pass a BR Audit without qualifications

Alex

On Tue, Jul 11, 2017 at 11:35 AM, Ryan Sleevi via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> >
> > > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via
> > dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> > >
> > > On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
> > >>

> > >> Please note this email topic is just for releasing the news that
> WoSign
> > new system passed the security audit, just for demonstration that we
> > finished item 5:
> > >> " 5. Provide auditor[3] attestation that a full security audit of the
> > CA’s issuing infrastructure has been successfully completed. "
> > >> " [3] The auditor must be an external company, and approved by
> Mozilla.
> > "
> > >

[Ryan Sleevi]

On Tue, Jul 11, 2017 at 11:40 AM, Alex Gaynor <aga...@mozilla.com> wrote:

> Is this a correct summary:
>
> - The report included here is supposed to fulfill the network security
> test portion of the BRs
>

No. This is #5 from https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 ,
and relates to the overall security design of the system which in part
stemmed from issues such as the ability to cause arbitrary (backdated)
issuance via manipulation of API parameters. That is, it's orthogonal to
the BRs, and intended to take a more systemic approach to the system design.

> - This report does not attest to BR compliance (or non-compliance)
>

Correct

> - To complete an application for the Mozilla Root Program, WoSign would be
> required to additionally provide a WebTrust audit (or equivalent, as
> described in the Mozilla PKI Policy section 3.1)
>

Correct, as required by #3 and #4.

> - Based on your reading of the complete network security test, you would
> not expect WoSign to be able to pass a BR Audit without qualifications
>

Correct.

>
> Alex
>
> On Tue, Jul 11, 2017 at 11:35 AM, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via
>> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> >
>> > > On Jul 11, 2017, at 06:53, okaphone.elektronika--- via
>> > dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>> > >
>> > > On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>> > >>

>> > >> Please note this email topic is just for releasing the news that
>> WoSign
>> > new system passed the security audit, just for demonstration that we
>> > finished item 5:
>> > >> " 5. Provide auditor[3] attestation that a full security audit of the
>> > CA’s issuing infrastructure has been successfully completed. "
>> > >> " [3] The auditor must be an external company, and approved by
>> Mozilla.
>> > "
>> > >

[Ryan Sleevi]

On Tue, Jul 11, 2017 at 12:09 PM, Percy via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tuesday, July 11, 2017 at 8:36:33 AM UTC-7, Ryan Sleevi wrote:
>
> > comply with the Baseline Requirements, nor, as designed, can it. The
> system
> > would need to undergo non-trivial effort to comply with the Baseline
> > Requirements.
>

> If the system needs significant changes to meet the BR, then does it mean
> the current security audit will no longer applies to the BR-complaint
> system, assuming WoSign is ever able to produce one?


That will be a question for Mozilla to assess with respect to its WoSign
remediation actions.

[Richard Wang]

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

> On 11 Jul 2017, at 23:34, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Tue, Jul 11, 2017 at 11:16 AM, Jonathan Rudenberg via
> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>>
>>> On Jul 11, 2017, at 06:53, okaphone.elektronika--- via

>> dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>>
>>>> On Monday, 10 July 2017 08:55:38 UTC+2, Richard Wang wrote:
>>>>

>>>> Please note this email topic is just for releasing the news that WoSign
>> new system passed the security audit, just for demonstration that we
>> finished item 5:
>>>> " 5. Provide auditor[3] attestation that a full security audit of the
>> CA’s issuing infrastructure has been successfully completed. "
>>>> " [3] The auditor must be an external company, and approved by Mozilla.
>> "
>>>

> comply with the Baseline Requirements, nor, as designed, can it. The system
> would need to undergo non-trivial effort to comply with the Baseline
> Requirements.

[Ryan Sleevi]

On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang <ric...@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.

[Richard Wang]

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 <ry...@sleevi.com<mailto:ry...@sleevi.com>> wrote:

[Matt Palmer]

On Thu, Jul 13, 2017 at 02:24:39AM +0000, Richard Wang via dev-security-policy wrote:
> We got confirmation from Cure 53 that new system passed the full security audit. Please contact Cure 53 directly to verify this, thanks.

Who should we contact at Cure 53? Or should we just use the "business
enquiries" contact address on their website?

- Matt

[Gervase Markham]

On 13/07/17 04:43, Matt Palmer wrote:
> Who should we contact at Cure 53? Or should we just use the "business
> enquiries" contact address on their website?

I doubt Cure53 would be able to tell you anything more than what has
been said in the released summary document.

Gerv

[Ryan Sleevi]

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 <ric...@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 <ry...@sleevi.com> wrote:

[Richard Wang]

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 <ry...@sleevi.com<mailto:ry...@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 <ric...@wosign.com<mailto:ric...@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 <ry...@sleevi.com<mailto:ry...@sleevi.com>> wrote:

[Ryan Sleevi]

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 <ric...@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 <ry...@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 <ric...@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 <ry...@sleevi.com> wrote:

[Ryan Sleevi]

In the description of the remediation of the vulnerabilities, aspects of
the design are shared, particularly in discussing remediation. These
aspects reveal design decisions that do not comply with the BRs, and are
significant enough to require re-design.

I agree that this can be difficult to independently evaluate. However, it
should hopefully be possible for all participants to understand that, given
the Mozilla required remediations, it seems unwise to audit a system before
you've made all of the necessary changes, or demonstrated a comprehensive
awareness of what is required of the BRs. It is good as an incremental
approach, particularly if you don't have a team of qualified security
engineers that can provide that in-house during the design and
implementation phase, but a holistic approach will involve making sure the
system is both compliant and secure, and both should be tackled together.

On Thu, Jul 13, 2017 at 3:13 PM, Percy via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > You will fail #4. Because your system, as designed, cannot and does not
> > comply with the Baseline Requirements.
>

> Is there a design outline in the security audit as well? No one in the
> community can judge either yours or WoSign's statement as this information
> is not shared with us. I suggest either WoSign or Mozilla/Google share such
> information with the community if it's not under NDA. Otherwise, this
> discussion is rather unproductive as we have crucial information missing.

[Richard Wang]

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 <ry...@sleevi.com<mailto:ry...@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 <ric...@wosign.com<mailto:ric...@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 <ry...@sleevi.com<mailto:ry...@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 <ric...@wosign.com<mailto:ric...@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 <ry...@sleevi.com<mailto:ry...@sleevi.com>> wrote:

[Peter Bowen]

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

[Richard Wang]

Hi Peter,

Thanks for your guesses.
Buy no those issues in our system.

Best Regards,

Richard

-----Original Message-----

From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Friday, July 14, 2017 8:55 AM
To: Richard Wang <ric...@wosign.com>

Cc: ry...@sleevi.com; Jonathan Rudenberg <jona...@titanous.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: WoSign new system passed Cure 53 system security audit

[okaphone.e...@gmail.com]

On Friday, 14 July 2017 04:44:39 UTC+2, Richard Wang wrote:
> Hi Peter,
>
> Thanks for your guesses.
> Buy no those issues in our system.
>
>
> Best Regards,
>
> Richard

That's what you say. But you've lied before. :-( So sorry, but that won't go anywhere near regaining trust. You'll have to be quite a bit more transparant before anything you say will be believed.

I really don't see why you post this summary at a time when you have not yet told us anything about the items that went before it. Or should have gone before?

The summary itself doesn't say much. But some things can be read between the lines.

There was a penetration test and they found problems which you then fixed quickly. Sounds like you did not do anything about the reason why those problems were in your code. So there will probably be more. That in itself is not surprising, but a team that quickly fixes those problem is. They should instead have done an an analyses why those problems were there in the first place and fixed there software development practices/process, then let that take care of fixing the problems.

There was a code review. But we don't hear anything about what the outcome was. There may have been findings but more import is what the overall quality of the code is. And still more important is what the quality of your development process is.

Are there unit tests, integration tests, what is the coverage, how complete is the documentation, specs, structure of the code, how good the layering, how complex is it, how maintainable, how correct, are you using version control, release management, code quality scanners?

All that is not covered by a penetration test and only some of it by a code review. So item five is really not all that important. It is just an extra insurance that all is well after all the other work has been done.

I still think that it would make most sense to start by showing us this item one. That would be a real step towards regaining trust.

CU Hans