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
