March 2016 CA Communication

ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties. Please check all the boxes below that apply.

CA Owner/Response (a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates. (b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (c) We use SHA-1 to sign OCSP responses, directly under a CA certificate. (d) We use SHA-1 to sign certificates. (e) We use SHA-1 signing in some other way. Text Input
Grand Total 20 29 3 19 23
AC Camerfirma, S.A. d) We use SHA1 EE certificates for SMIME and client authentication. We issue those certificates in some spanish public organizations that wasn't able to change their tecnology in time. We change this along 2016. e) We use SHA-1 in some TSA services responses. We are moving our customers to SHA256 along this 2016 year.
Actalis We accept Certificate Signing Requests (CSRs) signed with SHA-1.
Amazon Trust Services
Asseco Data Systems S.A. (previously Unizeto Certum) We use the SHA-1 certificates for S/MIME and client authentication We use the SHA-1 to sign CRLs that correspond to SHA-1 certificates
Atos
Autoridad de Certificacion Firmaprofesional We still sign SHA­1 certificates for natural and legal person, pursuant eIDAS (REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL, of 23 July 2014, on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC). We do not sign any TLS/SSL SHA­1 certificates. We plan to stop signing/issuing any kind of certificate or certificate status information by December the 1st. Spanish regulation force to all Spanish TSP to stop issuing end entity certificates of any type before January the 1st, 2017.
Buypass
Certicámara We are using SHA1 certificates to sign TSA responses. We do, however have a plan to migrate those certs to SHA2.
Certinomis / Docapost PKI SHA1: the PKI has been stop on 06/18/2015 but we still use the CA key to sign SHA1 CRL till the end of validity of the intermediate CA : 12/12/2018 as there is no more valid cert, we could stop issuing SHA1 CRL....
China Financial Certification Authority (CFCA) We are using SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. and we are upgrading it to SHA256.
China Internet Network Information Center (CNNIC) CNNIC have 2 root certificates included in Mozilla CA program, CNNIC Root and CNNIC EV Root. From Jan 28th 2015, CNNIC issue SHA256 OV certificates and stop issue SHA1 OV certificate. The DV and EV are still using SHA1. CNNIC stop issuing SHA1 certificate by the end of 2015. We plan to upgrade device and software and also deploy new SHA 256 intermediate Root (operated by CNNIC ) to issue SHA256 DV and EV cert by the end of May, 2016.
Chunghwa Telecom
ComSign We use the SHA-1 algorithm to periodically generate and sign CRL by the two Root CAs and by some Sub CAs under these roots. The CRLs are distributed as plain files on our public web servers. No signing operations take place by any server except for the CA servers themselves.
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) We will be issuing signatures and identification certificates for individuals and applications until 31/12/2016 when all end-entity and infraestructure certificates will be issued in Sha-2 from then on.
Cybertrust Japan / JCSI
D-TRUST
Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
Dhimyotis / Certigna
DigiCert SHA-1 is used only to sign OCSP Responses for certificates signed using SHA-1.
Disig, a.s.
DocuSign (OpenTrust/Keynectis) * (d) some OCSP responder certificates are SHA1-signed. This will end on 12/31/2016, at the latest * (e) some CRLs are SHA1-signed. This will end on 12/31/2016, at the latest * in the two previous cases, the signatures are not computed on any externally provided data, so a chosen-prefix collision attack is not possible
E-Tugra
EDICOM Our "ACEDICOM Root" sign OCSP responses, using the nonce extension wich overcomes the reply atack.
Entrust Not applicable
GlobalSign For (d), We use SHA-1 to sign Code Signing and S/MIME certificates, as required from our customers, - Code Signing: Windows Vista and Windows Server 2008 still need Kernel mode driver code signing to be SHA-1. - S/MIME: We will encourage customers to make their environments to support SHA-2, and to migrate to SHA-2, asap. We don’t have explicit end of issuing date now. We also use SHA1 to sign SHA1 CAs’ OCSP responder certs For (e), we create CRLs of SHA1 CAs.
GoDaddy (d) We are still issuing subscriber code signing certificates from our SHA-1 chains. We have not set a date at which we will stop issuing these certificates. We plan to adhere to Mozilla, Microsoft, and CA/Browser forum policies. We include 64 bits of entropy in the serialNumber field. (e) We use SHA-1 to sign CRLs that correspond to SHA-1 certificates.
Government of France (ANSSI, DCSSI) Certificates signed by the root certificate IGC/A are CA certificates able to issue certificates for ministries' agents (identification, signature, encryption) as well as server certificates (SSL/TLS). These certificates will be in use until December 31st 2016. Ministries are currently in the process of renewing their certificates with an alternate solution (through an interministerial market with an external trust service provider). Measures currently in place are : (1) revocation of the certificate in case there is a compromise or a suspected compromise and (2) a compulsory migration measure of all SHA-1 certificates to SHA-2 certificates before the end of 2016.
Government of Hong Kong (SAR), Hongkong Post, Certizen (d) We use SHA-1 to sign certificates - Our root certificate has issued one SHA-1 sub CA, which also issues SHA-1 client authentication certificates for S/MIME and PDF document signing and user authentication to legacy systems. (e) We use SHA-1 signing in some other way - Our root certificate and that SHA-1 sub CA also sign CRLs with SHA-1 signatures. There is no third party who possesses any certificate of our root certificate capable of issuance of digital certificates. We plan to commence migration of such certificates along with our root certificate rollover to a new SHA-256 PKI structure as soon as possible, and no later than end of 2018.
Government of Japan, Ministry of Internal Affairs and Communications
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
Government of Taiwan, Government Root Certification Authority (GRCA)
Government of The Netherlands, PKIoverheid (Logius)
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
HARICA
IdenTrust Services, LLC IdenTrust issues SHA-1 S/MIME Client Authentication certificates and some device certificates (not TLS). CRLs and OCSP responses associated to those certificates are signed using the SHA-1 algorithm. IdenTrust is progressively migrating those customers to another SHA-256 root included in the Mozilla program. The migration is driven by expiration of intermediate certificates issuing those certificates, an no intermediate expires beyond 2019. All certificates signed with SHA-1 algorithm include serial numbers with 20+ bits of entropy. All OCSP responders are under the delegated model.
Izenpe S.A.
Krajowa Izba Rozliczeniowa S.A. (KIR)
Microsec Ltd.
NetLock Ltd.
OISTE Related to the (d) response: WISeKey still issues personal certificates (never SSL) using SHA-1 for certain customers, that aren't ready to fully accept SHA-1 signatures. This occurs mainly in Peru, where the Government must still include in their Trust List our newer CAs ready to Issue SHA-256 certificates. We expect this situation to be solved during the first half of 2016 and from that point we'd stop issuing SHA-1 personal certificates. Related to the (e) response, and derived of the above situation, we're forced to keep issuing some CRLs signed with SHA-1. OCSP responses are always signed with SHA-256 certificates.
PROCERT
QuoVadis We still issue SHA-1 end user certificates (S/MIME, auth etc) in some cases. CRLs for those SHA-1 issuing CAs are signed with SHA1. We still can offer SHA-1 time-stamps (although default is SHA-2).
RSA the Security Division of EMC SHA-1 S/MIME certificates are issued by a different subordinate CA. There is a plan in place to change this to SHA-2 by June 15, 2016 after which no further SHA-1 signing will occur.
SECOM Trust Systems CO., LTD. We use the SHA-1 certificates for S/MIME and client authentication We use the SHA-1 to sign CRLs that correspond to SHA-1 certificates
SK ID Solutions AS
Sectigo (d) We use SHA-1 to sign certificates: - We still issue some SHA-1 Code Signing Certificates to software developers that target old versions of Windows, as permitted by Microsoft: "With the exception of issuing certificates to developers who intend to develop only applications for Windows Vista, Windows Server 2008, CAs may not issue new SHA-1 code signing certificates after January 1, 2016." [https://aka.ms/sha1] - We still issue some SHA-1 Client Authentication / Secure Email Certificates to subscribers. The date on which we will stop issuing such certificates has not yet been set. (e) We use SHA-1 signing in some other way: - We use SHA-1 to sign CRLs that correspond to SHA-1 certificates. The measures we have in place to prevent SHA-1 based attacks are: - We no longer issue SHA-1 Server Authentication certificates. - We no longer use SHA-1 to sign OCSP responses. - We include plenty of entropy in certificate serial numbers.
SecureTrust d: We issue code signing certificates signed with SHA1 upon customer request for supporting older Microsoft operating systems that cannot support SHA2. These certificates are all issued from a single intermediate CA controlled by Trustwave. We add 95 bits of entropy to the serial number of all of our end entity certificates, including these, to mitigate against collision attacks. e: We sign CRLs with SHA-1 for our root CAs as well as our intermediate CAs that themselves are signed with SHA-1. We use SHA-2 in CRLs for all of our SHA-2 signed intermediate CAs.
Start Commercial (StartCom) Ltd. (b) If the intermediate CA is SHA1, then we use SHA-1 to sign OCSP response; There are SHA1 intermediate CA for code signing and client certificate; (e) We use SHA1 to sign CRL for SHA1 intermediate CA, and we use SHA1 to issue code signing and client certificate.
SwissSign AG We are using the Time Stamping Certificates issued by the SwissSign Platinum CA that still using SHA1. We will Change this to SHA2 until August 2016.
Swisscom (Switzerland) Ltd SHA-1 based S/MIME certificates (e-mail client certificates). We plan to stop issuing them not later than the 06/30/2016 and to revoke them on 12/31/2016.
Symantec For TLS/SSL certificates that chain to roots with the Websites trust bit enabled, no explanation is required because the answer is (b). For those certificates for which we answered (c) and (d): * Administrator user certificates are issued under VeriSign Class 3 Public Primary Certification Authority - G3, which has the Websites trust bit enabled. Symantec are the only consumers of such certificates in a closed environment. The certificates are used via Symantec client software such that SHA-1 injection isn't feasible. * Individual S/MIME certificates and Adobe document signing certificates are issued under VeriSign Class 2 Public Primary Certification Authority – G3. We moved to SHA-2 on 04/01/2016. * Personal S/MIME certificates are issued under VeriSign Class 1 Public Primary Certification Authority.
T-Systems International GmbH (Deutsche Telekom) We still use SHA-1 certificates to sign CRL’s . We plan to switch to SHA-2 until Q3/2016.
Taiwan-CA Inc. (TWCA)
Telia Company (formerly TeliaSonera)
Trend Micro
Trustis d) We do not issue SHA-1 SSL/TLS Certificates. The only ones we issue are for document signing and encryption. (This is in the 100's) e) We issue CRLs from our FPS-TT IA, which is signed by the FPS ROOT (Which is SHA-1 based).
TurkTrust
Visa
Web.com We use SHA-1 to sign CRLs that correspond to SHA-1 certificates. The measures we have in place to prevent SHA-1 based attacks are: - We no longer issue SHA-1 certificates. - We no longer use SHA-1 to sign OCSP responses. - We include plenty of entropy in certificate serial numbers.
Wells Fargo Bank N.A.
WoSign CA Limited (b) If the issuing CA is SHA1, then we use SHA-1 to sign OCSP response; There are SHA1 issuing CA for code signing and client certificate; (e) We use SHA1 to sign CRL for SHA1 issuing CA, and we use SHA1 to issue code signing and client certificate.
certSIGN
Grand Total 20 29 3 19 23