I believe transparency is the best policy. I think it'd be helpful to the community if we could post the email exchange about the revocation. We can redact the agreement termination portions if you'd like, but that'd give a lot more clarity around what's going on. Do I have your permission to post those emails?
-----Original Message----- From: dev-security-policy <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org> On Behalf Of google.manager--- via dev-security-policy Sent: Wednesday, February 28, 2018 11:54 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: How do you handle mass revocation requests? Jeremy, Today many of our customers experienced lengthy delays when attempting to contact us via phone, e-mail and live chat. The reason for the delays were due to an unexpected e-mail that DigiCert sent to our customers containing some inaccurate information. We were not informed that the e-mail would be sent and were caught by surprise. We had disabled this e-mail within your control panel and opted to send our own notices, though you took it upon yourselves to send my personal details to 20,000 customers. We didn't authorise DigiCert to contact our customers and we didn't approve the content of their e-mail. At no time had any private keys been compromised, nor had we ever informed to you that any private keys had been compromised. During our many discussions over the past week we put it to you that we believe Symantec to have operated our account in a manner whereby it had been compromised. Your usage of the word compromise has been twisted by you to your benefit and is absolutely defamatory. We believe the orders placed via our Symantec account were at risk and were poorly managed. We have been questioning Symantec without response as to concerning items for about a year. Symantec simply ignored our concerns and appeared to bury them under the next issue that arose. There are a range of issues that Trustico intends to investigate via legal means. In good conscience we decided it wasn't ideal to have any active SSL Certificates on the Symantec systems, nor any that didn't meet our stringent security requirements. Our concerns also relate to the upcoming distrust of all Symantec SSL Certificate brands within Google Chrome and the reasoning behind it. The same management team responsible for that situation is duly employed at DigiCert and are fully managing our account, causing grave concern on our part as it appears to be business as usual with a new name. We were also a victim whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were asked to keep the matter quiet, under a confidentially notice. We had implemented a system to ensure that all customers would receive a replacement SSL Certificate, though today it had failed to perform this function. In our view it is absolutely critical that an SSL Certificate performs its intended function. Symantec's issue with Google appeared to seal that deal, whereby they will all eventually fail due to distrust. In accordance with CAB Forum guidelines we acted to immediately revoke active SSL Certificates whereby trust was questionable. Trustico absolutely distrusts the Symantec brand due to the issues that forced Symantec into having to hand over its entire authentication business to an alternate CA and a range of issues beforehand. Though, Symantec was ultimately acquired by DigiCert - though now DigiCert appears to be influenced by the Symantec management team - that to date still is managing our account. Trustico stopped offering the Symantec brands early February after a meeting with your Symantec management team, whereby they had disclosed to us that various reckless issues had occurred (recording available). We realize that this mass revocation is bothersome and time consuming for all that have been affected. We're working to contact all customers to get orders replaced as priority and working through a backlog of enquiries. Unfortunately, things didn't go very well for us today and we are extremely sorry for all the confusion and inconvenience that has been caused. We were relying on systems that would easily replace and issue SSL Certificates automatically, though that didn't occur and we ended up in quite a mess. DigiCert didn't work with us to understand the issues and resolve them, we felt we were at a dead end. We'll be following up again shortly with an update surrounding what occurred and more information about where we experienced failures. In the meantime, our staff are concentrating on getting SSL Certificates issued as quickly as possible from a reputable and trusted CA. As for the question of who is the subscriber, well ultimately that came down to the agreement that we had made with you and the agreement on the website. The conditions of the subscriber agreement were not honoured by you when it came to our requests anyway – so it’s hard to comment on who you refer to be a subscriber – even though your subscriber agreement clearly states that the reseller is the subscriber in our case. We instigated revocation of SSL Certificates as per your subscriber agreement. I shall like to further note that DigiCert terminated our contract on Sunday 25th February immediately after we put to you that we intended to seek a legal opinion in respect to the operation of our account and security concerns. Jeremy, the evidence that we have at hand as per the issues surrounding the revocation is somewhat different to what you are disclosing here today. As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with. Zane Lucas _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/agKxz5YN2oS2j3aBKGdI3rd5u57u8Xu5UsUNv9qPbXg=?d=KSM3YiopOvVUIKUCYWim2psjXx0oJUTN3GJYVvv86cH2hgAOuX0A4yUCYWJCrf8DxvICOyaAgSOSsQuBhgT-fwrAhvYJcuiMS5v21RcS10hnpz5YP_t7wqIWFHDiFcsXTRaUzlEsq157OU9akewIgfvDdgoovCCDhFXMsSO0Qz9-IsjYuLcY2r5XBg_U0za-RAQVdms513WgdS689UdoNpphZVMIsrO9rGs_qyRWVeAdA8xwkhsRgfAw3SP_TS7sCdki2kvz6t5uiO6j-BwoRUjAoVFRQtmxKYxWnvnGTjkZ-wHx9WGaqLsiP86sx_Dn1ve-_wY3O6scnyKHEz-UebwmKoH_wtXjc6f3fXxsTzV6Q7aQSiD21hpz98AC9_ZI7lf3ZXhg--cecs5fBcwAQf0XYkYpeAQqfp1i3UtBpVvxuFCa6LzeG0ONfbF_i08rNP8986U0v0nJ54W_m0eI&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy