RE: Incidents involving the CA WoSign
Thanks for your friendly reminder. We can post all 2015 issued SSL certificate to CT log server if necessary. For BR auditor, I think this issue is too technical that fewer auditor can find out this problem. 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. 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: Thursday, August 25, 2016 2:48 PM To: dev-security-policy@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign On Thu, Aug 25, 2016 at 04:03:04AM +, Richard Wang wrote: > For transparency, WoSign announced full transparency for all SSL > certificate from July 5th that post all issued SSL certificate to > Google log server, browsers can distrust WoSign issued SSL certificate > after that day if no SCT embedded data in the certificate. That would be slightly more reassuring if there wasn't a history of certs being issued with seemingly misleading notBefore values... Separately, do you have any thoughts on the reports that WoSign's BR auditor did not note any of the misissuances? Also, 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? - Matt -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -- Alan Kay ___ 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
StartCom's StartPKI
Hi, I stumbled across this service by StartCom: https://startssl.com/StartPKI (archive link: https://archive.is/GRkAK) I got a bit afraid when looking at their nice screenshots (https://archive.is/GRkAK#75%), because they offer intermediate certificates for companies allowing them to issue certificates by themself. So I checked their site to find out what this is about. The certs are "Trusted by all browsers" (https://archive.is/GRkAK#selection-419.0-419.23). So I thought in this case they (StartCom) need to control the process, especially as they allow EV certs to be issued. However here is what they state on their website: "StartPKI, let you control your SSL certificate life cycle management by yourself, not by the CA!" (https://archive.is/GRkAK#selection-517.0-517.96) This does rather sound as if the company would have a web interface where they can issue certificates like they want... So I thought they at least keep the private key on their servers/HSMs. However they mention "FIPS 140 Luna G5 HSM Secured" under "Setup your name issuing CA" (https://archive.is/GRkAK#selection-619.0-631.24), so does this indicate the companies have to setup a HSM? If so, for what if it is not the private key of the intermediate? On the other hand they say it you need no "No PKI infrastructure Investment" (https://archive.is/GRkAK#selection-449.0-449.32), but the "All controlled by yourself" (https://archive.is/GRkAK#selection-673.0-673.26) is not a very appeasing statement when it comes to who can issue certificates. Also they say you can "Issue certificates instantly" (https://archive.is/GRkAK#selection-425.0-425.28) (for free) I am wondering how this can work for EV certificates. On their news page (https://startssl.com/NewsDetails?date=20160428) they say the intermediate CA is "for the exclusive use of the verified organization". But how can they enforce this? At least they say that "the intermediate CA will be provided by StartCom's [...] infrastructure", so it seems they keep the intermediate themself. So at least they keep the private key. However this still does not answer the question how they control the certificates issued by this intermediate - especially when it comes to EV certificates. It is also unclear what kind of verification is made when a company issues a certificate with their own intermediate. Also note that there is a difference to StartResell. On their hompage (https://startssl.com/NewsDetails?date=20160530) they also state, that resellers have their own intermediate certificate. However there they seem to do the verification by themself and "charge the end user identity validation". This obviously does not happen for StartPKI... As StartPKI is "Ready to use in 3 days" (https://archive.is/GRkAK#selection-413.0-413.22) I doubt that they can trust all companies they issue intermediates for to do sane verification. The service is all in all quite questionable and statements like "All controlled by yourself" are horrible to hear. I hope this statement is just wrong and they somehow keep control. Best regards, rugk -- I offer PGP support. To send me a PGP-encrypted mail, please ask for my private mail address. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On Thursday, August 25, 2016 at 12:14:10 AM UTC-7, Richard Wang wrote: > We can post all 2015 issued SSL certificate to CT log server if necessary. Is there any reason not to do that proactively? > For BR auditor, I think this issue is too technical that fewer auditor can > find out this problem. The audit letter included an attestation from Management that, during the time of the audit, management believed that the CA complied with the Baseline Requirements. Management was aware of non-compliance, by virtue of revocation and system and procedural changes to align with compliance. Thus, do you believe it was faithful and accurate for Management to warrant that the CA was operated in compliance with the BRs, given that Management was aware of incidents of non-compliance? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom's StartPKI
On Thursday, August 25, 2016 at 10:11:21 AM UTC-7, rugk wrote: > Hi, > I stumbled across this service by StartCom: > https://startssl.com/StartPKI (archive link: https://archive.is/GRkAK) > I got a bit afraid when looking at their nice screenshots > (https://archive.is/GRkAK#75%), because they offer intermediate > certificates for companies allowing them to issue certificates by > themself. That's not prohibited of CAs to offer. > So I checked their site to find out what this is about. > The certs are "Trusted by all browsers" > (https://archive.is/GRkAK#selection-419.0-419.23). > So I thought in this case they (StartCom) need to control the process, > especially as they allow EV certs to be issued. > However here is what they state on their website: "StartPKI, let you > control your SSL certificate life cycle management by yourself, not by > the CA!" (https://archive.is/GRkAK#selection-517.0-517.96) > This does rather sound as if the company would have a web interface > where they can issue certificates like they want... That's typically known as "Managed CA", and is permitted by the BRs and EVGs, so long as the certificates issued comply with the BRs and EVG. > So I thought they at least keep the private key on their servers/HSMs. > However they mention "FIPS 140 Luna G5 HSM Secured" under "Setup your > name issuing CA" (https://archive.is/GRkAK#selection-619.0-631.24), so > does this indicate the companies have to setup a HSM? If so, for what if > it is not the private key of the intermediate? I'm not sure how you reached that interpretation. It suggests otherwise - that the CA maintains full control of the keys. Which is permitted. > On the other hand they say it you need no "No PKI infrastructure > Investment" (https://archive.is/GRkAK#selection-449.0-449.32), but the > "All controlled by yourself" > (https://archive.is/GRkAK#selection-673.0-673.26) is not a very > appeasing statement when it comes to who can issue certificates. > Also they say you can "Issue certificates instantly" > (https://archive.is/GRkAK#selection-425.0-425.28) (for free) I am > wondering how this can work for EV certificates. The EVGs cover how Enterprise RAs work, and this is permitted. (Section 14.2.2 of the EVGs) > On their news page (https://startssl.com/NewsDetails?date=20160428) they > say the intermediate CA is "for the exclusive use of the verified > organization". But how can they enforce this? > At least they say that "the intermediate CA will be provided by > StartCom's [...] infrastructure", so it seems they keep the intermediate > themself. Correct. > So at least they keep the private key. However this still does not > answer the question how they control the certificates issued by this > intermediate - especially when it comes to EV certificates. > It is also unclear what kind of verification is made when a company > issues a certificate with their own intermediate. It sounds like the core thrust of this post is that their English was not clear, but that's not a particular reason for concern. Everything you've highlighted has a benign, and permitted, interpretation. > Also note that there is a difference to StartResell. On their hompage > (https://startssl.com/NewsDetails?date=20160530) they also state, that > resellers have their own intermediate certificate. > However there they seem to do the verification by themself and "charge > the end user identity validation". This obviously does not happen for > StartPKI... Why do you claim "obviously"? I see no data to support this claim (either obviously or subtley) > The service is all in all quite questionable and statements like "All > controlled by yourself" are horrible to hear. I hope this statement is > just wrong and they somehow keep control. I'm not sure I would agree that it's horrible to hear. It seems the conclusion is based on marketing, written in broken English, rather than evidence of any malfeasance. StartResell allows reselling to end users (e.g. users whose domains you don't control). Most CAs offer some form of reseller agreement - aka revenue sharing - where the CA operates all the infrastructure from end-to-end, and gives you a cut of the profits. StartPKI seems no different than Enterprise RA - where, for domains you control, you can issue unlimited certificates. Provided those certificates and their issuance complies with the BRs and EVGs (which provide language that define how such should work), there appears to be nothing wrong here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Japan GPKI Root Renewal Request
> This request by the Government of Japan, Ministry of Internal > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' > certificate and enable the Websites trust bit. This new root certificate > has been created in order to comply with the Baseline Requirements, and > will eventually replace the 'ApplicationCA - Japanese Government' root > certificate that was included via Bugzilla Bug #474706. Note that their > currently-included root certificate expires in 2017, and will be removed > via Bugzilla Bug #1268219. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=870185 Thank you to those of you who reviewed and commented on this request from Japan GPKI to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit. This discussion is on hold pending completion of the following action items by the CA: 1) Update the CP/CPS documents with sufficient detail to describe the policies and procedures that apply to this root cert and all certs that chain to it. Note that I added a new section to the Recommended Practices wiki page to provide pointers to previous reviews of CP/CPS documents, so CAs can see both good and not-so-good examples. https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21 2) Provide an updated BR audit statement Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FNMT Root Inclusion Request
On Thursday, August 11, 2016 at 4:36:02 PM UTC-7, Kathleen Wilson wrote: > >> FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate > >> and enable the Websites trust bit. > >> > >> Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency > >> that provides services to Spain as a national CA. > >> > >> The request is documented in the following bug: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=435736 > > I believe that these action items have or are being addressed such that we > may move forward with approving FNMT's request to include the “AC RAIZ > FNMT-RCM” root certificate and enable the Websites trust bit. > > If there are no further concerns then I will close this discussion and > recommend approval in the bug. > (https://bugzilla.mozilla.org/show_bug.cgi?id=435736) > Thanks again to all of you who participated in this discussion about FNMT's request to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit. I am now closing this discussion and will recommend approval in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=435736 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom's StartPKI
Okay, thanks for your information. Also note that there is a difference to StartResell. On their hompage (https://startssl.com/NewsDetails?date=20160530) they also state, that resellers have their own intermediate certificate. However there they seem to do the verification by themself and "charge the end user identity validation". This obviously does not happen for StartPKI... Why do you claim "obviously"? I see no data to support this claim (either obviously or subtley) It was obvious to me because they advertise StartPKI as "pay once" and then it is free. (only some maintenance cost) And as they only advertise that they charge for "identity validation" for StartResell, but no not say this about StartPKI this means they at least do not charge for it. Whether/How they do the validation itself is of course another question, but at least they require no money for it - when you use StartPKI. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Amazon Root Inclusion Request
> This request from Amazon is to enable EV treatment for the > currently-included “Starfield Services Root Certificate > Authority - G2 certificate, and to include the following 4 new root > certificates, turn on the Email and Websites trust bits for them, > and enable EV treatment for all of them. > - Amazon Root CA 1 (RSA key with a 2048 bit long modulus) > - Amazon Root CA 2 (RSA key with a 4096 bit long modulus) > - Amazon Root CA 3 (EC key on the NIST P-256 curve) > - Amazon Root CA 4 (EC key on the NIST P-384 curve) > All 4 of these new Amazon root certificates have cross-signed with the > currently-included “Starfield Services Root Certificate Authority - G2” > certificate. > > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1172401 Thank you, Andrew, for your thorough review of this request from Amazon Trust Services. I did not see any show-stoppers, so I think it is OK to proceed with approval of this request in parallel with Amazon updating their CPS. Does anyone else have questions, comments, or concerns about this request? If not, then I will proceed with recommending approval. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: NEW Certificate Manager Add-on
An updated version of the signed Certificate Manager Add-on is available here: https://addons.mozilla.org/en-US/firefox/addon/certificate-manager/ The uninstall bug has been fixed. https://github.com/sidstamm/FirefoxCertificateManager/issues/39 The CA Information that it pulls from the CA Community in Salesforce (e.g. audit data) has been updated to what it was on August 10th. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On Thu, Aug 25, 2016 at 07:11:18AM +, 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. > 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? - 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
Re: Incidents involving the CA WoSign
On Thursday, August 25, 2016 at 4:35:39 PM UTC-7, Matt Palmer wrote: > 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? Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them. It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On Thu, Aug 25, 2016 at 05:15:58PM -0700, Ryan Sleevi wrote: > On Thursday, August 25, 2016 at 4:35:39 PM UTC-7, Matt Palmer wrote: > > 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? > > Clarification: In none of these incidents was Google notified proactively > by WoSign. Instead, Google received communication from internal or > external researchers regarding these issues, either prior to resolution or > much later after the fact, and subsequently contacted WoSign regarding > them. Oh, wow. I totally misread the initial report. That's almost certainly much *worse*, then, because it's not simply a matter of some adjustments to an existing process to improve it, but likely the development and deployment of an entirely new process. - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace "special tool no. 2-112-A"-- Matt Roberds in asr. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Incidents involving the CA WoSign
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 Ryan Sleevi Sent: Friday, August 26, 2016 3:10 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign On Thursday, August 25, 2016 at 12:14:10 AM UTC-7, Richard Wang wrote: > We can post all 2015 issued SSL certificate to CT log server if necessary. Is there any reason not to do that proactively? R: OK, we will post all 2015 issued SSL certificates to CT log server, but this take time since we issued 115K SSL certificate in 2015. Now we are posting the (1) using higher level port validated orders related to incident 0, total 72 certificates. To be clear, those certificates are validated by website control validation method that using other port except 80 and 443; (2) Mis-issued certificate with un-validated subdomain related to incident 1, total 33 certificates. I will list all crt.sh URL to this mail thread. Some certificates are revoked after getting report from subscriber, but some still valid, if any subscriber think it must be revoked and replaced new one, please contact us in the system, thanks. > For BR auditor, I think this issue is too technical that fewer auditor can > find out this problem. The audit letter included an attestation from Management that, during the time of the audit, management believed that the CA complied with the Baseline Requirements. Management was aware of non-compliance, by virtue of revocation and system and procedural changes to align with compliance. Thus, do you believe it was faithful and accurate for Management to warrant that the CA was operated in compliance with the BRs, given that Management was aware of incidents of non-compliance? R: This is my fault that I think it is not serious enough to state in the assertion letter, now I know and every related employee know how to do this in the future. ___ 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: Incidents involving the CA WoSign
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 +, 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
RE: Incidents involving the CA WoSign
Yes, sorry for this. As I admitted that this discussion gives us a big lesson that we know when we need to report incident to all browsers. We guarantee we will do it better. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Ryan Sleevi Sent: Friday, August 26, 2016 8:16 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign On Thursday, August 25, 2016 at 4:35:39 PM UTC-7, Matt Palmer wrote: > 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? Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them. It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread. ___ 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: Incidents involving the CA WoSign
We know how to do in the future, and believe me we will do this better. 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 10:03 AM To: dev-security-policy@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign On Thu, Aug 25, 2016 at 05:15:58PM -0700, Ryan Sleevi wrote: > On Thursday, August 25, 2016 at 4:35:39 PM UTC-7, Matt Palmer wrote: > > 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? > > Clarification: In none of these incidents was Google notified > proactively by WoSign. Instead, Google received communication from > internal or external researchers regarding these issues, either prior > to resolution or much later after the fact, and subsequently contacted > WoSign regarding them. Oh, wow. I totally misread the initial report. That's almost certainly much *worse*, then, because it's not simply a matter of some adjustments to an existing process to improve it, but likely the development and deployment of an entirely new process. - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace "special tool no. 2-112-A"-- Matt Roberds in 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
