See below inline, thanks

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On 
Behalf Of Matt Palmer
Sent: Friday, August 26, 2016 7:35 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Thu, Aug 25, 2016 at 07:11:18AM +0000, Richard Wang wrote:
> We can post all 2015 issued SSL certificate to CT log server if necessary.

That doesn't provide any assurance, in the face of misleading notBefore values 
in certificates.  Without strong assurances that whatever failure of systems or 
processes allowed misleading notBefore values to end up in certificates has 
been corrected, the only way to be sure that there are no shenanigans going on 
is for *all* certificates issued by WoSign,
*regardless* of their purported issuance date, to carry SCTs from a qualified 
log (or have them presented at TLS establishment), and have the "effective 
date" for the purposes of compliance with relevant standards and guidelines to 
be the date of the earliest SCT presented.  This is because the notBefore value 
in the certificate, being produced by a flawed process which allows misleading 
values to be used, is useless for the purposes of determining when the 
certificate was *actually* issued.  Any TLS connection using a WoSign-issued 
certificate which does not present SCTs would have to be considered completely 
untrustworthy.

R: As I declared in the Bugzilla, only two certificate is the backdated 
certificate that not issued by normal system, it is a API bug that found and 
used by Computest to get the two backdates certificate, not WoSign normally 
issued this two cert. And this two test certificate are revoked after we got 
report, we stopped this API and delete the bug code.

As we stated in WoSign website, browsers can distrust WoSign issued certificate 
after July 5th that no SCT embedded data, this is for full transparency.  


> For BR auditor, I think this issue is too technical that fewer auditor 
> can find out this problem.

I believe Ryan has done an excellent job of outlining the concerns with this 
statement.

> We will add the quality control system to PKI system before issuing 
> the certificate, and will check the crt.sh or use the CABF lint and 
> X590 Lint to check the certificate before and after the certificate is 
> issued to prevent such case, if such case happen, we will notify all 
> browsers instantly.

This neither addresses the question I posed, nor does it contain sufficient 
specificity to be reassuring.  I asked:

> what changes, exactly, has WoSign implemented to its policies and 
> procedures to ensure that all trust programs in which WoSign is a 
> participant are notified of future incidents, in line with each 
> program's requirements?

I'm after the specifics of the changes to WoSign's policies and procedures 
regarding *notification*, not quality control.  What were WoSign's previous 
policies and procedures regarding notification (obviously there was something 
in place, since Google was notified), and what changes have been made to 
improve those policies to ensure that all root programs are notified in line 
with each program's requirements in the future?

R: Sorry, I don't say it clear, please forgive my bad English since my native 
language is Chinese.
As I said this is my fault that we don't understand the Mozilla policy clearly 
that we don't think we need to report. But now we are clear that all mis-issued 
certificate case and any reported bug related system change also need to 
report. I and every related employee all clear now, then we can guarantee we 
will do it well in the future. 
Why we log all SSL certificate from July 5th is for full transparency to let 
all related parties can report to us in the first time after the certificate is 
issued.


- Matt

--
I told [my daughter] that if I see her digging a hole that she might not be 
able to crawl out of, my job isn't to stand back and say "That's a *real* nice 
hole you're digging there".
                -- Paul Tomblin, ASR

_______________________________________________
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

Reply via email to