April 2017 CA Communication

ACTION 14: CERTIFICATE VALIDITY PERIODS IN TLS/SSL CERTS Your attention is drawn to the CA/Browser Forum ballot 193, which recently passed. This reduces the maximum permissible lifetime of certificates from 39 to 27 months, as of 1st March 2018. In addition, it reduces the amount of time validation information can be reused, from 39 to 27 months, as of 31st March 2017. Please be aware of these deadlines so you can adjust your practices accordingly. Mozilla is interested in, and the CA/Browser Forum continues to discuss, the possibility of further reductions in certificate lifetime. We see a benefit here in reducing the overall turnover time it takes for an improvement in practices or algorithms to make its way through the entire Web PKI. Shorter times, carefully managed, also encourage the ecosystem towards automation, which is beneficial when quick changes need to be made in response to security incidents. Specifically, Mozilla is currently considering a reduction to 13 months, effective as of 1st March 2019 (2 years from now). Alternatively, several CAs have said that the need for contract renegotiation is a significant issue when reducing lifetimes, so in order that CAs will only have to do this once rather than twice, another option would be to require the reduction from 1st March 2018 (1 year from now), the current reduction date. If you are unable to support a comprehensive reduction in issuance lifetime, please explain the impact you see of Mozilla (and potentially other browsers) removing trust from certificates of lifetime > 13 months in the same sort of timeframe. This would mean browser-facing certificates would need to have shorter lifetimes, but those certificates not issued for trust by browsers could have longer lifetimes.

CA Owner Response
AC Camerfirma, S.A. AC Camerfirma could reduce issuance lifetime in TSL certificates.
Actalis We have several contracts in place, with major customers (esperially in the public administration sector), that require us to issue SSL Server certificates with a validity period of 3 (three) years. The new limit of 27 months already is a problem, in that respect, for our legal department. It would be an even bigger problem should the limit be set to 13 months.
Amazon Trust Services We have no concerns with a reduction to 13 months as a maximum validity period. More than 99.9% of certificates in our hierarchy already have a validity period less than or equal to 13 months.
Asseco Data Systems S.A. (previously Unizeto Certum) The further reduction to 13 months might not be good for us and our subscribers. Therefore we are not convinced that we should support it.
Autoridad de Certificacion Firmaprofesional We are able to support a comprehensive reduction in issuance lifetime
Buypass We are able to support a comprehensive reduction in issuance lifetime. However, we prefer a step by step approach as described above. I.e. a reducution of certificate lifetime to 27 months as of 1st March 2018 and a further reduction to 13 months at a later point in time. This is due to customer expectations and communication.
Certicámara Websites trust bit is not enable, however our CA only offers certificates up to 2 years.
Certinomis / Docapost Certinomis has to technical problem to reduce the life time of tls certificates. But it will generate some discontent for our customer used to 2/3 years certificates. Certinomis is not is favour of automation in certificate issuance process, all certificate applications are validated by a registration officer as recommanded in CEN/TS 419261:2015
China Financial Certification Authority (CFCA) 1,We still believe this will need more discussion (That reduce from 27 month to 13 month) . 2,We believe that both our company and customer needs more time to prepare for 1 year lifetime, so if we need to reduce Certificate lifetime to 13 month, (For example in a ballot of CAB) the effective date should not be early than 1st March 2019. 3,We also believe that 1year/13month is the bottom line for certificate life time, reduce it further to 3~6 month is not reasonable. We strongly oppose to this kind of reduction.
Chunghwa Telecom We suggest to reduce the lifetime of DV SSL certificates to 13 months only. As for EV or OV SSL certificates, we suggest to keep the maximum permissible lifetime of certificates and the amount of time validation information can be reused as Ballot 193. Applicant have long processes to prepare documemnts to apply for OV and EV SSL certificates. Also it need more RAO man powers to validation those documents. Becaause some automation process are hard for OV and EV SSL Certificates.
ComSign Not Applicable
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) We are able to support a comprehensive reduction in issuance lifetime
Cybertrust Japan / JCSI As mentioned above, CTJ currently doesn't issue any SSL/TLS certificates under JCSI-root. But CTJ will support a comprehensive reduction in issuance lifetime when CTJ start issuing SSL/TLS certs under JCSI-root.
D-TRUST We commit to the reduce the lifetime for TLS Certs to 27 month as scheduled. A reduction to 13 may cause problems with the existing customer base.
Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) Not Applicable
Dhimyotis / Certigna No problem to apply this requirement by march 2018.
DigiCert Automation is the key. Most customers don't have it. Most won't by March 31, 2017. We aren't opposed to moving to 13 month certs, but I think you'll find server operators generally unhappy. Reducing the validity period to 13 months from 825 doesn't give you much improvement on quickly changing the ecosystem as the hardware is the slow part. Look at the number of required exceptions from Symantec because of hardware/software support issues. All moving to 13 months does is increase the exception requests.
Disig, a.s. We are issuing SSL certificate with the validity of 12 month only.
DocuSign (OpenTrust/Keynectis) If the Websites trust bit is not set for your root certificates, write "Not Applicable" We see no negative impact.
E-Tugra We agree the plan.
EDICOM For ACEDICOM, actual limit is small enough. Reducing this lifetime will increase a lot administrative task of re-issuance of expiring certificates, and does not provide additional security since revocation mechanism are good and fast enough
Entrust We have a large enterprise customer base where many use hundreds to thousands of certificates. Reducing the certificate lifetime would require either increased labor or automation. In both cases the cost would be high and may take many years to implement effectively. We think that 825-days is sufficient for customer efficiency and changing over certificates from old requirements to new requirements. We would prefer for the industry to adjust to 825-days and allow automation to increase in efficiency. With the push to encrypt-all, we think that this will help push subscribers to become more efficient in their certificate management processes.
Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) Not Applicable.
GlobalSign GlobalSign can be prepared to comply with shorter validity periods, but we are concerned anbout the impact to the user community. While Google, Mozilla, Let's Encrypt and some other entities are highly automated, this is not the case for many users, and this will place an undue burden on them. More time is needed before a reduction from 825 days down to 13 months can be performed. Perhaps a more staggered timeline with intermediate validity periods of 20 and 16 months should be considered?
GoDaddy Because browser-facing certificates are our primary use case, removing trust from certificates with lifetimes > 13 months is no different to GoDaddy than mandating a 13 month maximum validity period, assuming that the policy is published far enough in advance that we can cease issuance of longer-lived certs in time to allow existing certificates to naturally expire before their trust is removed.
Google Trust Services LLC (GTS) Google Trust Services supports shortening certificate validity periods as proposed.
Government of Hong Kong (SAR), Hongkong Post, Certizen We are aware of these deadlines and have plan to adjust our practices according to CA/Browser Forum ballot 193. However, further reduction of certificate lifetime will create doubled workload to subscriber's management and control of SSL key pairs and certificates. So, the suggestion is not preferred.
Government of Japan, Ministry of Internal Affairs and Communications If the Websites trust bit is not set for your root certificates, write "Not Applicable" We think that it is too short if the life cycle of the customer's certificate will been setting the validity period to 13 months.
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) We have no problem with that plan although We think that 13 months is too short lifetime.
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) We have no problem to support it. Nevertheless, we think 13 months is a too short lifetime. Anyway, we also think that ~1 year should be limit for certificate life time reduction. By experience, suscribers have long processes to apply for certificates and reducing the lifetime of certificate in such terms will bring an important workload to applicants. Maybe, reducing lifetime plan could apply only to DV certificates (easy to apply automatic verifying processes).
Government of Taiwan, Government Root Certification Authority (GRCA) We issue certificate to government agencies and government agencies have long processes to apply for certificates. Reducing the lifetime of certificate will bring extra efforts for our government's insufficient server administrators. Nevertheless, we suggest mozilla provide a standard automation process for all kinds of web servers before enforcing the new rules.
Government of The Netherlands, PKIoverheid (Logius) We’re currently discussing the reduction in maximum validity of certificates from 39 months to 825 days (as per ballot 193) with our customers, but our CA and customers need more time to prepare for 1 year (13 months) certificate lifetime. Therefore, we do not support a reduction of maximum certificate lifetime to 13 months as of 1st March 2018. Such reduction is, in our opinion, possible as of 1st March 2019.
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) SSL certificates may be for 1 (one), 2 (two) or 3 (three) years. Usage period of key pairs of Kamu SM may not exceed 30 (thirty) months
HARICA HARICA has expressed its concerns on moving the SSL/TLS publicly trusted Certificate lifetime to 13 months publicly on the CA/B Forum public mailing list. We believe that 2-year certificates bring a balance to Subscriber expectations, system administrators and security expectations. We do not expect to see great automation tools developed in the next year to manage certificates and private keys on SSL/TLS devices. In case of serious security issues (for example algorithm collision or other compromise), then the 13 months or 24 or 27 months validity will not make a big difference because the community will need to resolve the problem in a much faster and decisive way.
IdenTrust Services, LLC IdenTrust understands the security value of reducing the lifespan of TLS certificates but we believe the 2 year lifespan is the right balance between security and the overhead that comes with shorter certificate lifespans. Though automation resolves the overhead, such automation comes to a cost for the entire customer base with a larger part paid by the smaller customers. For this reason IdenTrust is not currently supportive of reducing the lifespan to one year.
Internet Security Research Group (ISRG) All of our certificates are only valid for 90 days. We are strongly supportive of limiting certificate lifetimes to <= 13 months.
Izenpe S.A. We agree with that roadmap
Krajowa Izba Rozliczeniowa S.A. (KIR) KIR has always issued certificates with a maximum lifetime of 24 months. In our opinion 13 months will be too short for our clients.
LuxTrust Lifetime <= 13 months is restrictive due to the controls we have in place. These requirements need some adaptation of our current enrolment procedures and contracts. To perform these adaptation, we kindly request you to start enforcing this requirement starting from 1st March 2019
Microsec Ltd. Presently Microsec issues all type of certificates with 24 months lifetime so we already fulfil the 27 months new requirement. Technically it is possible to issue the new certificates with shorter lifetime (even 13 months), we are able to change our system within a reasonable time. Our problem is that it increases our costs so this case we would need to increase our certificate fees. The customers not only have to pay more for the certificates but the more frequent certificate replacement requires more staff or investment for automatic certificate replacement also. In spite of the higher operational cost we can not see the real benefit of the shorter (< 27 months) certificate lifetime. The Subject data indicated in the certificate is typically doesn't change during the 27 months. In case of any security incident or crypto problem we can revoke the certificates within 1 day (or less), the 13 months lifetime would not solve this problem.
NetLock Ltd. We can support the certificate life time changes.
QuoVadis Automation is essential when decreasing validity lifetimes for TLS/SSL, and most customers do not have automation in place (and in fact automation tools are limited to a small number of vendors at this time). Decreasing validity periods by March 1, 2019 will cause significant disruption and increased costs to customers. QuoVadis would support a move to shorter cert lifetimes with more lead time, and with more dialogue with the greater community. In short, CAs are not the dominant obstacle here - it's the ecosystem that actually uses the certs!
SECOM Trust Systems CO., LTD. We oppose the reduction to 13months. Government offices and public administration sectors require long life time certs. Even for other customers, it is required to have heavy time consuming discussion and negotiation for contract. Compromised plan if necessary is each year verification for two year certs, but this is not we want.
SK ID Solutions AS We strongly oppose the idea of shortening the validity period of the certicates for all the reasons already expressed in Cabforum discussions.
Sectigo We've already updated our systems to enforce a maximum 825-day validity period for server authentication certificates issued from 1st March 2018 onwards. Regarding proposals to reduce the maximum validity period to 13 months, our position is: "We are committed to security. Usable security. We represent many certificate holders who do not yet have sufficient technical expertise, manpower and/or automation to be able to cope with this proposed reduction in the maximum validity period." [https://cabforum.org/pipermail/public/2017-February/009679.html]
SecureTrust We do not currently oppose Mozilla’s proposed action. However, some public discussions have introduced future reductions to less than 13 months, where certificate lifetimes less than 13 months would not be supported.
Start Commercial (StartCom) Ltd. Startcom certificates are for free, we can change the validity time with no major issues but still don´t understand the reasoning. Regarding validation, we validate all the information every year, so again, that won´t be a problem.
SwissSign AG SwissSign is in the process of adoption for shortening the validity period of our records regrading the vetting procedures.
Swisscom (Switzerland) Ltd "Not Applicable": Swisscom stopps issuing SSL certificates. The websites trust bit will be removed - see https://bugzilla.mozilla.org/show_bug.cgi?id=1359515
Symantec As we have stated in our recent public statements, many enterprises are not at the level of automation maturity necessary to practically and cost-effectively adopt shorter validity certificates. For these organizations, standardizing on shorter validity certificates would present substantial increases in their operating costs and increase operational risk, until the right investment in and adoption of automation can support it.
T-Systems International GmbH (Deutsche Telekom) We do not have problems with truncated validity periods.
Taiwan-CA Inc. (TWCA) We understand the short key lifetime will be more secure, but the customer might will have complain about the replacing their TLS certificate too often, because we only issue OV and EV certificate, the verify process will spend times for our customer. 13 months limitation might more suitable for DV certificate because DV almost use the automatic verify process. Our suggestion: Set 13 months limitation for DV, 27 months limitation for OV and EV.
Telia Company (formerly TeliaSonera) In our opinion the further reduction of lifetime of OV and EV is not reasonable for server owners. Only for semi-automatic DV process the planned <13 months is OK. Our suggestion: Set 13 months limitation for DV, 27 months limitation for OV and EV.
Trustis Trustis is aware of the deadlines and proposed changes and will actively support discussions in this area.
TurkTrust TURKTRUST believes that the 27-month validity period is ideal in terms of both internet security and operational efficiency. Decreasing this period further would surely add benefit to security issues but will increase the burden on CAs regarding operational complexity.
Visa Not Applicable
WISeKey We adapt and continue adapting our policies to the latest industry regulation
Web.com We are aware of the deadlines and have already coded the restriction. Currently, we sell certs for maximum term of 3 years. We have to remove the 3 year term as an option to meet 27 month maximum lifetime. To reduce the maximum lifetime to 13 months represents a drastic change from current practice. I agree that this will add significant burden to our customers.
WoSign CA Limited WoSign is able to get prepared for the reduction of the lifetime change of certificate to 13 month per request.
certSIGN We are issuing certificates with a maximum lifetime of 12 months.