Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 12/07/2017 16:47, Ryan Sleevi wrote:

On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


* Comodo re-issued certs with the same key. I wonder if there should be
   a rule that once a key compromise event is known to the CA it must
   make sure this key is blacklisted. (Or maybe one of the existing
   rules already apply, I don't know.)



BRs 1.4.5 6.1.1.3 only requires the CA to reject a certificate if it
doesn't mean 6.1.5/6.1.6 or is known weak private key.

While the example is given (e.g. Debian weak keys), one could argue that
'weak' includes 'disclosed'. Of course, given that the specific term "Key
Compromise" is also provided in the BRs, that seems a stretch.

One could also argue 6.1.2 is applicable - that is, revocation was
immediately obligated because of the awareness - but that also seems
tortured.

Probably the easiest thing to do is update the BRs in 6.1.1.3 to replace
"known weak private key" to just say "If the private key is suspected or
known to have suffered Key Compromise" - which includes known weak private
keys, as well as the broader sense.



But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).


One challenge to consider is how this is quantified. Obviously, if you
reported to Comodo the issue with the key, and then they issued another
certificate with that key, arguably that's something Comodo should have
caught. However, if you reported the compromise to, say, ACME CA, and then
Comodo issued an equivalent cert, that's questionable. I'm loathe to make
CAs rely on eachothers' keyCompromise revocation reasons, simply because we
have no normative guidance in the BRs (yet) that require CAs be honest or
competent with their revocation reasons (... yet). Further, we explicitly
don't want to have a registry (of compromised keys, untrustworthy orgs,
etc), for various non-technical reasons.

I'm curious if you have thoughts there - particularly, how you reported the
private key was compromised (did you provide evidence - for example, a
signed message, or simply a link to "Here's the URL, go see for yourself"?)
- and how you see it working cross-CA boundaries.



Maybe it would be better stylistically to add this to one of the other
BR clauses.

Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
be obvious to the CA that they should have set up checks for this, since
most key compromise reports come from the subscriber, who would be a lot
less likely to make this mistake after revoking the key themselves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

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 
Cc: r...@sleevi.com; Jonathan Rudenberg ; 
mozilla-dev-security-policy 
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 
 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 
> > 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 
> > 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 
> > 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 
> > 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 
> > 

Re: WoSign new system passed Cure 53 system security audit

[Peter Bowen via dev-security-policy]

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

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

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 > 
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 
> 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 > 
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 
> 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 > 
wrote:



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

Re: WoSign new system passed Cure 53 system security audit

[Ryan Sleevi via dev-security-policy]

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-security-policy@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.
> ___
> 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

Re: WoSign new system passed Cure 53 system security audit

[richardsmeizumx--- via dev-security-policy]

2017年7月10日月曜日 15時00分04秒 UTC+9 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=wosign@lists.mozilla.org] On 
> Behalf Of Percy via dev-security-policy
> Sent: Monday, July 10, 2017 12:41 PM
> To: mozilla-dev-security-pol...@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?
> 
> On Sunday, July 9, 2017 at 7:26:28 PM UTC-7, Richard Wang wrote:
> > 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:e...@konklone.com]
> > Sent: Monday, July 10, 2017 10:12 AM
> > To: Richard Wang 
> > Cc: Itzhak Daniel ; 
> > mozilla-dev-security-pol...@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 
> > >
> >  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=wosign@lists.mozilla.org]
> >  On Behalf Of Itzhak Daniel via dev-security-policy
> >Sent: Monday, July 10, 2017 4:57 AM
> >To: 
> > mozilla-dev-security-pol...@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-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
> >
> >
> >
> >
> >
> >
> >
> >--
> >
> >konklone.com | 
> > @konklone
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

It seems really interesting to me that Richard Wang himself is confirming 
Richard Wang did a good job on leading the new team, who caused all these 
problems in the first place.

Also admitting that CEO is N/A and COO runs everything. So, nothing has changed 
except possibly lower salary.

Chinese company are really mastermind when it comes to bypass regulations.

Richard Leung
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[Percy via dev-security-policy]

> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[Ryan Sleevi via dev-security-policy]

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

Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

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 > 
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 
> 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 > 
wrote:



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

Re: WoSign new system passed Cure 53 system security audit

[Ryan Sleevi via dev-security-policy]

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

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/07/17 15:47, Ryan Sleevi wrote:
> > One challenge to consider is how this is quantified. Obviously, if you
> > reported to Comodo the issue with the key, and then they issued another
> > certificate with that key, arguably that's something Comodo should have
> > caught.
>
> I'd say so.
>
> > However, if you reported the compromise to, say, ACME CA, and then
> > Comodo issued an equivalent cert, that's questionable.
>
> Sure. This would be a provision to deter accidental stupidity, not
> wilful stupidity. The common case is a clueless person just resubmits
> the same keypair to their current CA.
>

Right. My point in that was that it's easy to rathole into a definition of
"known Key Compromise" that  implies an obligation to check others
revocation lists to see if a certificate with the same public key has been
revoked due to keyCompromise, which is further undesirable given that CAs
can't be trusted with the revocation reasons in the first place.

My goal was to try to capture that, to some extent, the burden of knowledge
can only be on the CA's own direct knowledge - which means it only prevents
the subscriber from getting a cert (from the same CA), and not from another
CA. This is both a limitation of the mitigation - it doesn't prevent
another CA from issuing - and a potential concern from CAs - others can
issue what they cannot.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec meeting and status

[Vincent Lynch via dev-security-policy]

Hi Gerv,

I interpreted your wording as meaning that Symantec will be publicly posting a 
new document (presumably to this list or blink-dev). Is this accurate?

If so, do you (or anyone else at Mozilla, since your vacation has now started) 
know when Symantec plans on doing so?

-Vincent


On Monday, July 3, 2017 at 10:20:31 AM UTC-4, Gervase Markham wrote:
> Hi everyone,
> 
> As I was in the Bay Area for the Mozilla All Hands, Symantec requested a
>...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[Gervase Markham via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Gervase Markham via dev-security-policy]

On 12/07/17 15:47, Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued another
> certificate with that key, arguably that's something Comodo should have
> caught. 

I'd say so.

> However, if you reported the compromise to, say, ACME CA, and then
> Comodo issued an equivalent cert, that's questionable. 

Sure. This would be a provision to deter accidental stupidity, not
wilful stupidity. The common case is a clueless person just resubmits
the same keypair to their current CA.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy