April 2017 CA Communication

ACTION 8: CONFIRM COMPLETION OF PREVIOUS COMMITMENTS Review your CA's response to the previous CA Communication here: https://wiki.mozilla.org/CA:Communications#March_2016_Responses Please confirm completion of those action items by checking the boxes below.

CA Owner/Response We no longer allow issuance of SHA-1 intermediate and TLS/SSL certificates chaining up to our root certificates included in Mozilla's CA Certificate Program. SHA-1 certificates are no longer used in the infrastructure related to our root certificates included in Mozilla's CA Certificate Program. (e.g. SHA-1 is no longer used to sign OCSP responses) The current policy of our CA is that non-technically-constrained intermediate certificates chaining up to our root certificates included in Mozilla's CA Certificate Program will be disclosed in the Common CA Database before they issue publicly trusted certificates, and their corresponding CP/CPS documents and audit statements will also be provided. The current policy of our CA is that all revoked non-technically-constrained intermediate certificates chaining up to our root certificates included in Mozilla's CA Certificate Program will be marked as Revoked in the Common CA Database within one week of revocation. For TLS/SSL certificates chaining up to our root certificates included in Mozilla's CA Certificate Program we do not issue certificates with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix We have reviewed Mozilla's Root Transfer Policy, https://wiki.mozilla.org/CA:RootTransferPolicy, and will notify Mozilla of such changes. Text Input
Grand Total 62 50 60 60 59 61
AC Camerfirma, S.A. We are using SHA1 in OCSP responses. We are working with our customers to change to SHA2 before end of May 2017.
Actalis We are still using SHA-1 to sign OCSP responses.
Amazon Trust Services
Asseco Data Systems S.A. (previously Unizeto Certum)
Atos
Autoridad de Certificacion Firmaprofesional
Buypass
Certicámara We don't issues TLS/SSL certificates in the moment.
Certinomis / Docapost
China Financial Certification Authority (CFCA)
Chunghwa Telecom 1.We have already stop using SHA-1 to sign SSL certificates’ OCSPResponses. 2We will use certlint and x509lint to ensure the compliance of our CA in the near future. 3.Chunghwa Telecom Co., Ltd. - Public Certification Authority - G2 has a new CA certificate ( Chunghwa Telecom Co., Ltd. - Public Certification Authority - G2, F5:FB:67:C8:45:3E:DA:34:DB:EC:8A:76:65:74:F0:7A:03:54:8C:08:4A:F2:F5:E6:45:5E:A7:69:60:8D:9A:D5) issued in Oct 3, 2016. It was updated the CP OID extenison field for supporing pdf signing certificate. But the issuance of the CA certificate was beyond the recently audit report with audit period from during the period from August 15, 2015 through August 14, 2016. We has asked our audtior to arrange time to audit. Maybe it will be accompanyd with the audit of our new ePKI EV SSL CA (not yet operated). To keep all the CAs in ePKI with the same audit period in future version of audit report.
ComSign
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
Cybertrust Japan / JCSI
D-TRUST The requirement #3 is fulfilled for the "D-TRUST Root Class 3 CA2 EV 2009" and "D-TRUST Root Class 3 CA2 2009" TLS/SSL For the S/MIME Root "D-TRUST Root CA 3 2013" are already S/Mime End Entity certificates issued.
Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)
Dhimyotis / Certigna
DigiCert
Disig, a.s.
DocuSign (OpenTrust/Keynectis)
E-Tugra
EDICOM
Entrust We do sign OCSP responses which are validated with a SHA-1 signed OCSP certificate. We do meet the Mozilla policy requirement which states "CAs MAY sign SHA-1 hashes over OCSP responses only if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU."
Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA))
GlobalSign We are no longer issuing any SHA-1 TLS certificates and that we no longer create SHA-1 CAs for this purpose. We do use SHA-1 to sign OCSP messages for the legacy CAs (the OCSP signing certificates contain an EKU extension which contains only the id-kp-ocspSigning EKU), but we do not use SHA-1 for signing any Infrastructure related certificaets. The EPKI, PersonalSign 1/2/3 and Code Signing still have legacy SHA-1 services, and use SHA-1 to sign OCSP and Timestamp.
GoDaddy We currently sign all OCSP responses using SHA-1 via constrained OCSP responder certificates. Our interpretation of Mozilla policy is that this is allowed ("CAs may only sign SHA-1 hashes over OCSP responses if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU."). We do have the capability to sign responses with SHA-2 and are planning a careful transition to SHA-2 OCSP signatures for our SHA-2 chains by July. We’re planning to continue to use SHA-1 for OCSP responses for our SHA-1 certificate chains. Regarding https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix #2, we no longer encode the default value but we do include the BasicConstraints extension instead of following the recommended practice of excluding the extension.
Google Trust Services LLC (GTS) N.B. Due to access / permissions issues, we encountered a slight delay updating the CCADB for 2 recent revocations. We worked with Kathleen to address the issues and do not foresee any future problems. Our policies are clear that we must update the CCADB within one week.
Government of Hong Kong (SAR), Hongkong Post, Certizen Nil
Government of Japan, Ministry of Internal Affairs and Communications
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Currently we use SHA-1 to sign some CRLs as allowed in Mozilla Policy: "CAs MAY sign SHA-1 hashes over CRLs for roots and intermediates only if they have issued SHA-1 certificates." Anyway, we plan to sign all CRLs with SHA-256 within this year.
Government of Taiwan, Government Root Certification Authority (GRCA)
Government of The Netherlands, PKIoverheid (Logius) We currently sign OCSP responses using SHA-1 via constrained OCSP responder certificates for intermediate CAs. The OCSP responder certificates themselves are signed over a SHA256 hash. Our interpretation of Mozilla policy is that this is allowed ("CAs may only sign SHA-1 hashes over OCSP responses if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU."). OCSP responses for end-user certificates are always signed with SHA256. We’re looking into also using signing SHA256 hashes over OCSP responses for the intermediate CAs.
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
HARICA
IdenTrust Services, LLC IdenTrust is still working in the transition away from SHA-1 OCSP Responses. The final steps of the transition are to be completed on by July 1, 2017. This includes revoking legacy subordinate CAs, which no longer issue certificates but have validation systems using SHA-1, and transition to SHA-256 responses for those CAs that still have SHA-1 certificates issued (See action 13 for SMIME certificates)
Internet Security Research Group (ISRG)
Izenpe S.A.
Krajowa Izba Rozliczeniowa S.A. (KIR)
LuxTrust
Microsec Ltd.
NetLock Ltd.
PROCERT The current policy of our CA is that non-technically-constrained intermediate certificates chaining up to our root certificates included in Mozilla's CA Certificate Program will be disclosed in the Common CA Database before they issue publicly trusted certificates, and their corresponding CP/CPS documents and audit statements will also be provided. PROCERT IS A SUBCA THIS POINT CANT APPLY We have reviewed Mozilla's Root Transfer Policy, https://wiki.mozilla.org/CA:RootTransferPolicy, and will notify Mozilla of such changes NO APPLY
QuoVadis Confirmed
SECOM Trust Systems CO., LTD.
SK ID Solutions AS
Sectigo It's not clear to us precisely what "in the infrastructure related to" is intended to mean. 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. We still issue some SHA-1 Server Authentication certificates to subscribers under our "UTN - DATACorp SGC" root. This root is no longer trusted by Mozilla, but it is operated in the same infrastructure as our other roots and intermediates that are trusted by Mozilla. The date on which we will stop issuing such certificates has not yet been set. We still use SHA-1 to sign CRLs that correspond to SHA-1 certificates.
SecureTrust We use SHA1 to sign CRLs for our root CAs as well as intermediate CAs that themselves are signed by SHA1. We use SHA2 exclusively on all OCSP responses and OCSP delegated responder certificates.
Start Commercial (StartCom) Ltd.
SwissSign AG Revokation of Root signed Issuing CAs was announced, but only now documented.
Swisscom (Switzerland) Ltd
Symantec In our previous response for Action #1a on SHA-1 Deprecation dates, we responded “VeriSign Class 3 Public Primary Certification Authority - G5: 02/29/2016”, but the last issuance date from this root was 12/15/2016. This was discussed in a CABF call; minutes are available here: https://cabforum.org/2016/09/29/2016-09-29-minutes/. In an update to our previous response for Action #1c on SHA-1 deprecation, we plan to stop issuance of SHA-1 S/MIME certs by CY-Q3-2017. We have one more ICA to add to our previous response for (e): GeoTrust Global CA: There are 1410 certificates all with a notBefore date of March 8, 2017 or earlier. These will all be expired or revoked by September 30, 2017.
T-Systems International GmbH (Deutsche Telekom) 2. (SHA-1 certificates) Within our infrastructure, there are valid SHA-1 certificates issued before January 01, 2016. Our customers have the opportunity to change these SHA-1 certificates for free. Some of our OCSP responders use SHA-1 to sign OCSP responses until May 12, 2017 5. (#Things_for_CAs_to_Fix) We include the basicConstraints extension default value cA:false in end-entity certificates.
Taiwan-CA Inc. (TWCA)
Telia Company (formerly TeliaSonera)
Trustis
TurkTrust
Visa
WISeKey As per Action 13, we are still forced to maintain compatibility with personal certificates which are generated by older SHA-1 CAs. We expect to remove this dependency during 2017.
Web.com
WoSign CA Limited
certSIGN
Grand Total 62 50 60 60 59 61