.

OwnerAction #1 Policy Update ReadinessAction #2 Baseline Requirements ReadinessAction #3 Scan Certificate DatabaseAction #4
Stop including reserved IP address in SSL certificates
Action #5 URL to Test WebsiteComments

.

A-TrustAAB*A**Provided* Certificates with key sizes smaller than 2048 will be revoked by the end of 2013.
** Stopped issuing such certs in January 2013.

.

ActalisBC*AAProvided* Appendix B, Appendix C, update CPS. March 2013.

.

AOLAAAB*Provided* September 2016

.

AS Sertifitseerimiskeskuse (SK)BC*B**AProvided* We have analysed the issues and have a plan to fix the deficiencies.
** We have a plan to revoke all end-entity SSL certificates with RSA key sizes smaller than 2048 bits no later than December 2013. Certificates issued to natural persons with 1024-bit keys in SSCD will remain active after 2013. We have a roadmap in place to replace them. Certificates with sequential serial numbers are no longer being issued, will allow the previously issued certs to expire.

.

Autoridad de Certificacion FirmaprofesionalAAB*AProvided* There are end entity certificates with keys smaller than 2048 that expire after December 2013 These certificates are issued to natural or legal persons in Secure Signature-Creation Devices (SSCD) and the SSCD can not manage bigger key-lengths. Problematic certificates will NOT be revoked since we consider that the use of SSCD provides an extra of security. We will start to issue EE certificate in SSCD with 2048 bit key-size when the use of such devices is generalised.

.

BuypassBAAAProvided

.

CA Disig a.s.BAAAProvided

.

CamerfirmaAC*B**B***Provided* Working on OCSP and OCSP stapling.
** Certificates with key sizes smaller than 2048 will be revoked by Dec 2013.
*** End of 2013

.

CATCertAAB* B**Provided* End-entity certs with 1024-bit keys will expire or be revoked by end of 2014. One of the subCAs issues certs with sequential serial numbers. This subCA will be upgraded to resolve this issue by end of 2013.
** 31/12/2016

.

Certicámara S.A.AB*AANot Applicable* No longer issuing SSL certs under this root.

.

Certigna (Dhimyotis)AAAAProvided

.

CertinomisAC*A**B***Provided* OCSP, alignment of cert fields, internal server names. This year, before next audit.
** There are 15 personal certificates with 1024-bit keys that will be allowed to expire in 2014.
*** November 2014

.

certSIGNAAAAProvided

.

China Internet Network Information Center (CNNIC)B*AB*AProvided* Certs issued with sequential SN. Email received on January 16, 2014, stating that the serial numbers of all new end-entity certs now contain 20 bits of random data.

.

Chunghwa Telecom CorporationAC*B**B***Provided* We have completed <add id-kp-serverAuth and id-kp-serverAuth in ExtKeyUsage Field as specified in the item F of Subscriber Certificate requirements in Appendix B of CA/Browser Forum's Baseline Requirements.
** Certs with 1024-bit keys will be revoked and replaced by end of 2013.
*** Stop issuing by Jan 2014. Revoke remaining by end of 2015.

.

Comodo (AddTrust, Comodo, USERTRUST)AAB*B**Provided* Many certs with RSA key size smaller than 2048 were issued before December 2010. We do not have a fixed date in mind by which we will revoke these certificates – but we understand that browsers and platforms may cease to support <2048 bit RSA keys after 2013 and we are prepared for that event.
** November 2015. We are working to transition our customers away from this practice well before then in as many cases as possible.

.

ComSign (Comda)AAAB*Provided* Will stop issuing such certs November 2015.

.

DanID (TDC)A* **B* **A***AProvided* The TDC OCES CA (not SSL) cannot sign intermediate certificates due to the national OCES Certificate Policy (OCES CP). We request Mozilla to remove the TDC OCES CA certificate by December 31 2013.
** TDC Internet Root CA -- no new certificates issued in this hierarchy since June 30, 2012.
*** Have not scanned all the end user certs, but have requested that the TDC OCES CA be removed.

.

Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV)C*BAANot ApplicableWe do not issue SSL certificates. Only the S/MIME trust bit is enabled for our root cert.

* our root certificate has pathlength=0. In order to change this, we would have to create a new root certificate, have it included in Mozilla products, and allow for migration of thousands of client certificates (issued to smart cards) to the new hierarchy. Therefore, we request that either the fourth bullet point of item #6 be changed to not apply to client (S/MIME) certificates, or that we be granted a long-term exception to the fourth bullet point of item #6.
For the same reason we can not operate this root offline as required indirectly by ETSI TS 102 042 V2.3.1 because it  includes the "Network and CA  system security requirements"  of the CA/Browser Forum. Therefore, we also request to update the text regarding the ETSI criteria version and make ETSI TS 102 042 V 2.1.2 applicable to our type of root certificate

.

DigiCertAAB*B*** End user certificates with 1024-bit keys will be revoked by end of 2013.
** November 2015

.

e-Guven Elektronik Bilgi Guvenligi A.S.BC*AB**Provided* Root certificate generation request due to SHA -1 hash algorithm in regulation given by Turkish Government on 30.01.2013. Planning to be done in 6 months. (30.07.2013)
** Will stop issuing such certs by January 31 2013.

.

e-tugraB*AAAProvided* intermediate certificates

.

EDICOMAAAAProvided

.

EntrustB*AB**B***Provided* subCAs
** End user certificates with 1024-bit keys will expire by March 2014. End user certificates with sequential serial numbers. The majority of these certificates have 3-bytes of randomness in the valid to/from date fields. Entrust will be changing the issuance to have random data in the serial number.
*** November 1, 2015

.

GlobalSignBAAB*Provided* We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by Nov 1st 2015

.

GoDaddy (GoDaddy, Starfield, ValiCert)AAB*B**Provided* End-entity certs with 1024-bit keys were issued before the effective date of the Baseline Requirements, and will be allowed to expire after 12/31/2013.
** We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by November 1, 2015, in accordance with the sunset timeline established in the CA/Browser Forum Baseline Requirements. We are also monitoring the work ICANN is doing with new gTLDs and will take any action prior to November 1, 2015 that is necessary to ensure that any existing or newly issued certificates are valid under newly-created public DNS namespaces.

.

Government of France (PM/SGDN, IGC/A)C*C*AAProvided* We need to add OCSP responders; add the Subject Alternative Name field in all SSL certificates; provide a web page with valid, revoked and expired certificates for each CA; retain audit logs and documentation for seven years instead of five years; conduct an annual risk assessment; and verify conformance with CPS four times a year.
Furthemore, these requirements will be included in the next version of the French reference document called “référentiel général de sécurité” for all administrations in France.
Modifying the current PKIs involves heavy government administrative procedures and additional budgets which have not been provisioned by the ministries for 2013. Therefore, the following schedule will be used:
- May to October 2013: Formalize specifications to be fully compliant with requirements of Mozilla policy and CA/BrowserForum;
- December 2013: Finalize budget plan for 2014
- January to May 2014: Set up a government contract to implement the changes
- June 2014 to June 2015: Contract execution
- July 2015 to December 2015: Issue new compliant certificates, replace and revoke non-compliant certificates.

.

Government of Hong Kong (SAR), Hongkong PostC*C**B***B****Provided* Only issue with Mozilla policy version 2.1 is in regards to BRs.
** Work in progress: subjectAlternateName (BR 9.2.1), 20 bits of entropy (BR 9.6), OCSP GET (BR 13.2.2), cert extensions (Appendix B). Need until mid 2015 to be in full compliance with the BRs because the work involves system and infrastructure upgrades.
*** Internally-operated intermediate cert missing cRLDistributionPoint. Certs issued with sequential serial numbers. Software and infrastructure upgrades required, will complete by Q2 2014.
**** May issue SSL certs with internal or private domain names, but plan to comply with BR #9.2.1.

.

Government of Japan, Ministry of Internal Affairs and Communications (GPKI)C*C**B***AProvided* GPKI had already planned to create a new root certificate, so the new root certificate and hierarchy will be in full compliance with the BRs.
** Creating a new root certificate in 2013 to meet the BRs. This will need to be included in Mozilla products and certificates transitioned to the new hierarchy.
*** As of January 11, 2013, new end-entity certificates are not issued with sequential serial numbers, and they contain at least 20 bits of random data.

.

Izenpe S.A.AAAB*Provided* Our SSL certs last for 3 years, so we´ll stop issuing them in October 2013.

.

Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)AAAAProvided

.

Government of Taiwan, Government Root Certification Authority (GRCA)AC*B**B***Provided* add id-kp-serverAuth and id-kp-serverAuth in ExtKeyUsage Field as specified in the item F of Subscriber Certificate requirements in Appendix B of CA/Browser Forum's Baseline Requirements, and we verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 36 months. We plan to have this completed by Dec 31, 2013.
** End-entity certs with 1024-bit keys expire or will be revoked by the end of 2013.
*** Will stop issuing such certs by Jan 1, 2015. Will revoke such certs by Dec 31, 2015.

.

Government of The Netherlands, PKIoverheid (Staat der Nederlanden, Logius)AAB*B**Provided* Two CSPs have certificates with 1024-bit keys. The SSL certs with small key sizes will be revoked/replaced by end of 2013. The end user certs with small key sizes will be replaced by July 2014.
** November 2015

.

Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)A*C**AAProvided* Mozilla’s CA Certificate Policy #9 will be available in our new
root, which we will submit to Mozilla for inclusion in Q4, 2013.
**We will have this done by July 2013. We are working on audit
recently.

.

Hellenic Academic and Research Institutions Certification Authority (HARICA)AC*AAProvided* Work to comply with BRs has been completed. BR audit statement received by Mozilla on March 4, 2014.

.

IdenTrustC*A** & C**A & D***AProvided* Subordinate CA certificates. Under normal circumstances, we would be able to deliver in the allotted timeframe. However, the timing is challenging because all four of the current IdenTrust roots stored in the Mozilla browser (E1, E2, X3, and X6) will go through rollover during the 2014 calendar year. As a result, our current proposed plan is to update our CA operations to comply with the proposed version 2.1 of the Mozilla’s CA Certificate Policy by December 31, 2014.
** IdenTrust CA operations conform to the BRs. There is one particular subCA chaining up to the X3 root that needs more time to implement OCSP, policy updates, hostname in subjectAltNames. Plan is for this subCA to comply by March 31, 2013.
*** One subCA chaining up to the X3 root found noncompliant certificates that have been revoked and replaced in January 2013. These revoked certificates had incorrectly enabled keyCertSign (within Key Usage). However, these certificates DID NOT have 'cA' enabled in basicConstraints. As such, we do not believe these certificates pose security risk as Mozilla based browser would require 'cA' enabled in basicConstraints to form a valid path back to a trusted anchor. In addition, the Sub CA that has issued the revoked certificates has a path length constraint set to 0. This provides an additional protection because in standard path validation any chain containing the revoked certificates would be rejected because the length of the chain formed using the revoked certificates would not satisfy the path length constraint set to 0.

.

Japan Certification Services, Inc. (JCSI)****** This root certification only has internally-operated subordinate CAs.
** New certificate issuance is currently suspended. A new issuing intermediate certificate will be created before new certificate issuance resumes.

.

KEYNECTIS (Certplus)BAB*AProvided* The 1024-bit subscriber certificates have been revoked, and the platform has been configured so the minimum acceptable key size is 2048 bits. There is one internal (employees) CA without a CRLDP extension, which will be revoked and replaced this year. A subCA has issued certs with sequential serial numbers; this subCA certificate is not signing new certs, and will be revoked soon.

.

Microsec e-Szignó CAAAAAProvided

.

NetLock Ltd.AAB*A* End-entity certs with 1024-bit keys expire or will be revoked by end of 2013.

.

QuoVadisBAB*B**Provided* End user certificates with 1024-bit keys, will be replaced by end of 2013. Two intermediate certs (for issuing end user certs, not SSL certs) with OCSP in AIA but they don't include a CRL URI. One already replaced, the other being replaced.
** November 2015

.

RSA the Security Division of EMC (RSA, ValiCert)B*C**AAProvided* Subordinate CAs. RSA is still considering whether to technically constrain subordinate CA certificates or to publicly disclose them and will reach a decision by the specified dates.
** RSA Root CA does not issue SSL certificates to end users; Intermediate Customer CAs do issue SSL certificates, and in the process of verifying compliance.  Target compliance for Intermediate CAs will be by end 2014.

.

SECOM Trust Systems Co. Ltd. (SECOM, ValiCert)AC*B**B***Provided* 1024 bit certs, Appendix A. We plan to have this completed by the end of 2013. However, it might be still many certificates active after 2014. OCSP requirements for SubCAs are still working. It depends on the environments of devices/ software and economic outlay of the customers. We need to discuss and plan with our customers.
** SSL certificates smaller than 2048bits expire after 2014 and certificates have been issued with contiguous serial numbers. Problematic certificates will be revoked and replaced by the end of 2013.
*** Stop issuing such certs by November 2015.

.

Start Commercial (StartCom) Ltd.AAAAProvided

.

Swisscom Solutions AGAAAAProvided

.

SwissSign AGBAAB*Provided* May 15, 2014

.

Symantec / TC Trust CenterBAAB*Provided* Will stop issuing such certs by November 2015.

.

Symantec / ThawteBAB*B**Provided* SSL end-entity certs with 1024-bit keys will expire or be revoked by the end of 2013. Non-SSL certs with 1024-bit keys will be allowed to expire, and customers will be upgraded to bigger key sizes when they renew their certificates.
** Will stop issuing such certs by November 2015.

.

Symantec / VeriSignBAB*B**Provided* SSL end-entity certs with 1024-bit keys will expire or be revoked by the end of 2013. Non-SSL certs with 1024-bit keys will be allowed to expire, and customers will be upgraded to bigger key sizes when they renew their certificates.
** Will stop issuing such certs by November 2015.

.

Symantec / GeoTrust (includes Equifax, USERTRUST)BAB*B**Provided* SSL end-entity certs with 1024-bit keys will expire or be revoked by the end of 2013. Non-SSL certs with 1024-bit keys will be allowed to expire, and customers will be upgraded to bigger key sizes when they renew their certificates. Certs are issued with sequential serial numbers, but there is unpredictable data in the cert.
** Will stop issuing such certs by November 2015.

.

Symantec / RapidSSLBAB*B**Provided* SSL end-entity certs with 1024-bit keys will expire or be revoked by the end of 2013. Non-SSL certs with 1024-bit keys will be allowed to expire, and customers will be upgraded to bigger key sizes when they renew their certificates. Certs are issued with sequential serial numbers, but there is unpredictable data in the cert.
** Will stop issuing such certs by November 2015.

.

T-Systems International GmbH (Deutsche Telekom)BAB*B**Provided* End-entity certificates with 1024-bit keys will be revoked/replaced by the end of 2013.
** Will stop issuing such certs in accordance with BR #9.2.1.

.

Taiwan-CA Inc. (TWCA)AAAAProvided

.

TeliaSoneraBC*B**B***Provided* The next TeliaSonera CA audit is starting in February 2014, and is expected to confirm full compliance with BRs. The first BR audit identified improvements needed in order to fully comply with BRs # 9.5, 10.3.1, 13.1.3, 15.3.2, 16.2. 16.3, and 16.4.
** Certificates with 1024-bit keys were previously used for older smart cards and older VPN connections managed by TeliaSonera. Those will be allowed to expire, and will be upgraded to bigger key sizes when they expire. Those will expire in 2013-2016.
*** Will expire or be replaced by October 2016.

.

Trend Micro (AffirmTrust)AAAA*Provided* Reserve the right to issue this type of certificate, but would observe the expiry date limitation of November 2015.

.

TrustisBC*AB**Provided* Implement OCSP by May 2014, then add BR compliance statement to CPS. BR audit will be part of the 2014 audit.
** Stop issuing such certs by September 2013.

.

Trustwave (SecureTrust, Xramp)BC*B*B**Provided* End-entity certificates with 1024-bit keys will be revoked/replaced by the end of 2013.
**

.

TurkTrustBC*B**A***Provided* BRs 9.2.1, 9.2.4, 9.2.6, 9.3.3, 9.5, and Appendix C. May 2013.
** End-user certificates with 1024-bit keys, will be allowed to expire. SSL certs with sequential serial numbers will be revoked/replaced by October 2013. (Relevant intermediate certs already distrusted in NSS.)
*** This type of cert is no longer being issued; existing certs will be allowed to expire.

.

Unizeto CertumAC*AAProvided* OCSP requirements for end user certificates will be fulfilled by October 2013.

.

Verizon Business (Balitmore, Cybertrust, GTE)C*C**B***A (Verizon), B****ProvidedAs we manage a number of subordinate CAs at major enterprises and their planning completes, we have been receiving estimates of OCSP response capability at our external subordinate CAs taking effect after the May 15, 2014 target. We are working with our customers to understand delays and bring as many subordinates into OCSP compliance as practical. In all other regards, including audit or technical constraint, we are making progress on target to our previous commitment.
* Will not be able to assert full BR compliance in next audit (April 2013) because OCSP service will be completed later. The April 2014 audit is expected to confirm full compliance with the BRs. SubCAs also need to implement OCSP services, plan is to fully comply with Mozilla policy v2.1 by May 15, 2014.
** OCSP, absence of country in DN of some subordinate CAs, use of the id-any-policy in some subordinate CAs, customer ability to shut off mandatory CN copy to SAN in cases of interoperability failure, CP and CPS content, exam process for approvers, customer ability to set a fixed list of authorized requestors, and video taping of subordinate CA creation. We require additional planning and software engineering estimates before we can provide a compliance date for the BR, primarily driven by OCSP.
*** Our managed services operations and the operations of our subordinated customers include 1024-bit end entity keys valid after 12/31/2013 which will be replaced before the end of 2013. The subordinated operations of a small fraction of our customers include sequential serial numbers which are partially mitigated by validity datetime randomness, and completely mitigated by applying patches to randomize serials. No other issues were reported or discovered in scans.
**** Our customers intend to align to the prescribed timelines that all RFC 1918 reserved IP address certificates expire by October 2016 and that none are issued after November 2015. In almost all regards ... reserved IP addresses have nearly been cleared from our issued base and will be eliminated ahead of the targets.

.

VisaAA*A*** We will scan our database, take the requested action, and reply to question 3 by March 31st 2013.
** Test websites will be available by March 31st 2013.

.

Web.com (Network Solutions)AAAB*Provided* Will stop issuing such certs by November 2015. We will be transiting our customers away from this practice well before then in as many cases as possible.

.

Wells Fargo Bank N.A.AAAB*Provided* November 2014

.

WISeKeyAAAB*Provided* October 2016

.