Discussion Period Begins | SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods
Clint Wilson
Purpose of Ballot
Background
The Web PKI is a complex, integral, and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1].
Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases (such as Private PKIs) are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version [2], the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns [3], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over times, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [4].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [5] [6]. In particular, the following are perceived benefits to the Web PKI:
- Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [7].
- The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [8] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [9].
- As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.
- Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
- Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.
- While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [10].
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://cabforum.org/uploads/Baseline_Requirements_V1.pdf#page=23
[3] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[4] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[5] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[6] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[7] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[8] - https://insecure.design/
[9] - https://zanema.com/papers/imc23_stale_certs.pdf
[10] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.html
Motion
The following motion has been proposed by Clint Wilson (Apple) and endorsed by Nick France (Sectigo), Ryan Dickson (Google Chrome), and Ben Wilson (Mozilla)
You can view and comment on the Github pull request representing this ballot here.
Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version XXX as specified in the following redline:
Motion Ends
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
- Start time: Tuesday, January 28, 2025 17:00 UTC (2025-01-28T17:00:00Z)
- End time: on or after Tuesday, February 11, 2025 17:00 UTC (2025-02-11T17:00:00Z)
Vote for approval (7 days)
- Start time: TBD
- End time: TBD
Clint Wilson
Dimitris Zacharopoulos (HARICA)
HARICA participated in the earlier discussions of this ballot. We would like to share our thoughts, comments, propose some changes to this ballot, and welcome any discussion on these ideas.
Purpose of Ballot
SC-081: Introduce Schedule of Reducing Validity and Data Reuse PeriodsBackground
The Web PKI is a complex, integral, and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1].
Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases (such as Private PKIs) are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version [2], the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns [3], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over time, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [4].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [5] [6]. In particular, the following are perceived benefits to the Web PKI:
- Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [7].
This applies to every identity attribute/value in real life. People's names, company names, domain name owners, they can all change. The validity period of certain attributes, and the need to re-check, is a risk-based exercise with the main input being the frequency of changes of these attributes, along with the volume of those attributes. For example, if we take passports or ID cards for a large part of the global population, people do change their full names but the frequency is such that passports and ID cards are valid anywhere from 5 to 10 years (in some countries, even longer). Requiring every citizen to replace passports or IDs more frequently (e.g. every 1 year) would cause unnecessary global financial/administrative burden for negligible security gain.
Out of all globally registered Base Domain Names, do we have any data or estimate of how many change owners on an annual basis? If this percentage is very very small, HARICA's position is that the financial/administrative overhead introduced by reducing the validity of certificates and the re-use period of Domain Name/IP Address validation evidence, is unreasonably high compared to the overall security benefit. Instead of focusing on ALL Internet Domain Name owners, the CABF should focus on the small number of Domain Names changing owners.
Phasing-in some sort of WHOIS/RDAP polling for Base Domain Name changes of ownership against Domain Name Registrars could leverage this in a more balanced way.
- The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [8] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [9].
In real-life examples, when a Domain Name changes ownership, the new owner controls the DNS of that Domain Name and points it to new web servers. The old owner (and any third-party with access to the old key/certificate) can abuse that material, only in environments where they can manipulate DNS and intercept network traffic. The best way for the new owner to protect against such a (low probability?) risk, is to contact the CA that issued the old certificate and request revocation using 4.9.1.1 (5) by proving control of the Domain Name.
- As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.
- Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
Indeed, revocation at Internet scale doesn't work efficiently, at least with the current IETF protocols allowed in the BRs. In the recent years, we've seen efforts by Browser vendors to develop proprietary solutions, based on CRLs, to protect relying parties from revoked certificates hours after that revocation takes place. If there are certain problems with the CRL size, the BRs could be updated with certain requirements and limitations.
For example, consider a requirement where an Issuing CA has a limit where if all its non-expired certificates were to be revoked, the produced CRL size must be lower than X amount of bytes. That would force the CA to create another ICA or to use partitioned CRLs. In any case, an ICA would need to stop issuing new certificates if it cannot meet that CRL size requirement. I know it sounds difficult and challenging to describe in a normative way, but does it make sense to people?
- Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.
- While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [10].
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://cabforum.org/uploads/Baseline_Requirements_V1.pdf#page=23
[3] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[4] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[5] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[6] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[7] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[8] - https://insecure.design/
[9] - https://zanema.com/papers/imc23_stale_certs.pdf
[10] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.htmlMotion
The following motion has been proposed by Clint Wilson (Apple) and endorsed by Nick France (Sectigo), Ryan Dickson (Google Chrome), and Ben Wilson (Mozilla)
You can view and comment on the Github pull request representing this ballot here.
Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version XXX as specified in the following redline:
- HARICA supports gradual reduction of certificate validity up to 100 days. 90-day certificates have been working well for the majority of the WebPKI Subscribers for years. HARICA does not support certificate validity of 47 days for the following reasons:
- The number of Domain Names increase annually so the total number of certificates that need to be issued, retained in logs/databases and other historical records
- Certificate issuance will grow exponentially (2x in year 1,
4x in year 2, 8x in year 3), leading to a significant increase
of maintenance and operational cost. Part of this cost
increase, in some cases, will be shifted to Subscribers. It is
not simple for CAs to predict today what changes need to
happen in order to issue 8x their current certificate volume.
Projections for up to 4x seem to be more feasible to design.
- Although Let's Encrypt demonstrated that 90-day certificates
are feasible, it didn't come without mass-revocation risks [11]
[12]
to the ecosystem. It is too risky to move to 47-days without
enough operational experience and data. This is not something
that HARICA, and possibly other CAs, are ready to promise
delivering for 2028, and make that promise today. There are
too many unknowns.
- As discussed in [13] CT logs will have a significant impact due to the dramatic increase of issued certificates required to be logged. Infrastructure challenges for global voluntary tools like https://crt.sh will already struggle to handle the existing load and will be challenging to tackle the other proposed milestones for 200, 100-day certificates. HARICA's engineers consider that the 47-day certificates will be very difficult to manage for CT log servers and monitors, unless there is a completely different technology in 2028.
- HARICA supports gradual reduction of Domain Name and IP Address re-use period up to 100 days. HARICA does not support re-use period set to 10 days for the following reasons:
- Historically the re-use period is aligned with the validity of certificates and we do not see any benefit for changing that practice.
- Subscribers should be "ready to replace" their certificates in case of a revocation event and having Domain and Identity Validation fulfilled (pre-validated) speeds things up. Re-validating every 10 days creates significant operational increase for Subscribers with no significant security improvement.
As a general comment, when considering the reduction of
certificate validity periods, please consider the amount of time
it took the WWW to move from HTTP to HTTPS because, similarly to
replacing certificates, it was website operators (Certificate
Subscribers) doing most of the transition work. According to W3Techs,
in January 2018 only 26.9% of "top sites" had https enabled by
default. It took 5 years to get that number increased to 77.4% (January
2022). It is currently at 87.6% (January 2025). I'm sure
other research papers will confirm similar numbers. A significant
uptake took place when Browsers decided to add "negative UI
indicators" on plain http websites. CAs like Let's Encrypt and the
larger Internet Engineering community assisted with
standardization of automated methods like ACME.
HARICA believes that the certificate validity decrease goal could
follow a similar path and is a burden that should not be taken by
the CAs alone. Browsers could also assist in the adoption of
shorter certificate validity periods by following a similar
strategy, with negative UI indicators if, for example, a
certificate is longer than 200 days, and later, if a certificate
is longer than 100 days. CAs and Browsers could jointly share this
burden of moving website owners to more automation and shorter
validity periods. Website owners would be more willing to accept a
path like that than being "forced" by MUST/SHALL CA rules,
especially since there is no immediate severe security threat for
the WebPKI ecosystem.
With these thoughts in mind, we propose the timeline for
decreasing validity of 100 days to extend in a 5-year period, and
each validity period should begin with a SHOULD and change to a
SHALL when the next period is phased-in:
Reference for maximum Validity Periods of Subscriber Certificates
|
Certificate issued on or after |
Certificate issued before |
Maximum Validity Period |
|
|
March 15, 2026 |
398 days |
|
March 15, 2026 |
March 15, 2028 |
SHOULD be 200 days, SHALL be 398 days |
|
March 15, 2028 |
March 15, 2030 |
SHOULD be 100 days, SHALL be 200 days |
| March 15, 2030 | SHALL be 100 days |
Thank you for your attention.
Best regards,
Dimitris Zacharopoulos.
Motion Ends
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
- Start time: Tuesday, January 28, 2025 17:00 UTC (2025-01-28T17:00:00Z)
- End time: on or after Tuesday, February 11, 2025 17:00 UTC (2025-02-11T17:00:00Z)
Vote for approval (7 days)
- Start time: TBD
- End time: TBD
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/C4130A9A-BC51-43E9-873F-57069EFC3D6E%40apple.com.
Aaron Gable
Historically the re-use period is aligned with the validity of certificates and we do not see any benefit for changing that practice.
Subscribers should be "ready to replace" their certificates in case of a revocation event and having Domain and Identity Validation fulfilled (pre-validated) speeds things up. Re-validating every 10 days creates significant operational increase for Subscribers with no significant security improvement.
As a general comment, when considering the reduction of certificate validity periods, please consider the amount of time it took the WWW to move from HTTP to HTTPS because, similarly to replacing certificates, it was website operators (Certificate Subscribers) doing most of the transition work. According to W3Techs, in January 2018 only 26.9% of "top sites" had https enabled by default. It took 5 years to get that number increased to 77.4% (January 2022). It is currently at 87.6% (January 2025).
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/5cd1bf68-ac46-4b58-a0c8-1991d139c12e%40harica.gr.
Dimitris Zacharopoulos (HARICA)
Hi Dimitris,
Thank you for your thorough discussion of the ballot. In general, I think you hold an eminently reasonable opinion with regards to the ballot and potential changes to it. I personally do not have a strong opinion on whether the end-state here should be 47 days, 100 days, or some other value. However, I think that the arguments you use to support your position are flawed.
On Tue, Feb 4, 2025 at 10:16 AM 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
This is a mischaracterization. The "mass-revocation risk" posed by Let's Encrypt is unrelated to the fact that Let's Encrypt certificates are valid for 90 days. The risk of a mass revocation being necessary clearly has nothing to do with certificate lifetimes: that same incident could have occurred whether Let's Encrypt lifetimes were 30 days or 365 days. The issue was with how the LE CP/CPS was written, not the validity period itself. The risk of a mass revocation not being carried out was (in that case) related to the sheer number of certificates affected, which in turn is due to Let's Encrypt's adoption of automation and open access, not 90-day certificate lifetimes.
Historically the re-use period is aligned with the validity of certificates and we do not see any benefit for changing that practice.
Validation document reuse and certificate validity period should, in my opinion, be purposefully and explicitly decoupled. When these two validity periods align, it is easy for people to fall into the trap of believing that a temporary compromise of their systems gives an attacker the ability to impersonate them for that validity period. This is not the case: it gives the attacker the ability to impersonate them for twice that validity period, because they can request issuance of a new certificate on the basis of that reused validation data on the last day that the data can be reused. I think it is critical that the validation document reuse period be reduced to a value significantly less than the certificate validity period, so that laypeople's beliefs about the consequences of compromise are closer to correct.
Some Supervisory Bodies in Europe have decided to use different validation reuse periods per identity validation method. For example, the automated method of eID authentication can be reused for a short period compared to the reuse of validations based on physical presence. I know it's not the same for Domain Validation, and may over-complicate things for the TLS BRs, but it's a concept used in other public trust frameworks.
Subscribers should be "ready to replace" their certificates in case of a revocation event and having Domain and Identity Validation fulfilled (pre-validated) speeds things up. Re-validating every 10 days creates significant operational increase for Subscribers with no significant security improvement.
Adoption of automation makes this a non-issue. In the event of a mass revocation, ACME clients largely do not care whether they need to re-validate a domain or not. Issuance of the replacement certificate takes on the order of seconds either way. And as discussed above, reducing the amount of time that a temporary attacker can reuse a cached validation from 398 days to 10 days is clearly a security improvement.
As a general comment, when considering the reduction of certificate validity periods, please consider the amount of time it took the WWW to move from HTTP to HTTPS because, similarly to replacing certificates, it was website operators (Certificate Subscribers) doing most of the transition work. According to W3Techs, in January 2018 only 26.9% of "top sites" had https enabled by default. It took 5 years to get that number increased to 77.4% (January 2022). It is currently at 87.6% (January 2025).
This is not an apples-to-apples comparison. Adoption of HTTPS required the addition of something that had not been there previously: processes to acquire certificates. Adoption of shorter lifetimes takes significantly less effort: just modifying existing processes to take place on a more frequent schedule. In the case of many automated clients which check to see if they need to do work multiple times per day, it requires no changes at all. I think that expecting adoption of a change like this to take the same period of time as initial adoption of HTTPS is unrealistically pessimistic.
Thanks,
Dimitris.
Mike Shaver
The argument assumes that there is still a large number of Subscribers not using automation for Domain Validation and require human intervention.
adding some incentive from the Browsers would "convince" the entire ecosystem that this is the direction the WebPKI is heading
Aaron Gable
Our first response relied heavily on the fact that there is still a significant percentage of subscribers that have not adopted full automation in certificate lifecycle management, and are having challenges doing so. Some would have no alternative but to hire additional people just to satisfy domain validation and to perform certificate replacement tasks because they are using legacy systems that may take a long time to update or deprecate. It's not an apples-to-apples direct comparison but adding some incentive from the Browsers would "convince" the entire ecosystem that this is the direction the WebPKI is heading, and all sides (CAs and Browsers) are completely aligned to meet that target.
Dimitris Zacharopoulos (HARICA)
On Wed, Feb 5, 2025 at 1:54 AM 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
The argument assumes that there is still a large number of Subscribers not using automation for Domain Validation and require human intervention.
*And* that these Subscribers will be unable to implement automation for DV in the timelines proposed by the ballot, once such automation becomes in their economic interest or even an operational necessity, rather than the topic of education from their CAs. Is there evidence that HARICA's proposed change in timeline will materially affect that?
adding some incentive from the Browsers would "convince" the entire ecosystem that this is the direction the WebPKI is heading
I propose, only half joking, that the incentive be "your certificates are still honoured after these dates".
Dimitris.
Mike
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Wendy Brown - QT3LB-C
Wendy
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Clint Wilson
On Feb 4, 2025, at 10:16 AM, 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:Dear Members,
HARICA participated in the earlier discussions of this ballot. We would like to share our thoughts, comments, propose some changes to this ballot, and welcome any discussion on these ideas.
On 28/1/2025 7:02 μ.μ., 'Clint Wilson' via Server Certificate WG (CA/B Forum) wrote:
Purpose of Ballot
SC-081: Introduce Schedule of Reducing Validity and Data Reuse PeriodsBackground
The Web PKI is a complex, integral, and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1].
Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases (such as Private PKIs) are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version [2], the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns [3], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over time, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [4].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [5] [6]. In particular, the following are perceived benefits to the Web PKI:
- Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [7].
This applies to every identity attribute/value in real life. People's names, company names, domain name owners, they can all change. The validity period of certain attributes, and the need to re-check, is a risk-based exercise with the main input being the frequency of changes of these attributes, along with the volume of those attributes. For example, if we take passports or ID cards for a large part of the global population, people do change their full names but the frequency is such that passports and ID cards are valid anywhere from 5 to 10 years (in some countries, even longer). Requiring every citizen to replace passports or IDs more frequently (e.g. every 1 year) would cause unnecessary global financial/administrative burden for negligible security gain.
Out of all globally registered Base Domain Names, do we have any data or estimate of how many change owners on an annual basis? If this percentage is very very small, HARICA's position is that the financial/administrative overhead introduced by reducing the validity of certificates and the re-use period of Domain Name/IP Address validation evidence, is unreasonably high compared to the overall security benefit. Instead of focusing on ALL Internet Domain Name owners, the CABF should focus on the small number of Domain Names changing owners.
Phasing-in some sort of WHOIS/RDAP polling for Base Domain Name changes of ownership against Domain Name Registrars could leverage this in a more balanced way.
- The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [8] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [9].
HARICA disagrees with the initial parameters/assumptions described in [9] which seem to lead to incorrect security assumptions. This paper was discussed in https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/3q07n2tISkI/m/QvEQXcbLAgAJ. This discussion does not seem to have addressed all concerns and observations. The last comment submitted by Henry Birge-Lee is that some observed attacks took place "within even the proposed 47 day lifespan". The attacks described in the paper require an initially-assumed trustworthy third-party (a CDN/hosting/reverse proxy provider or reseller), with access to a Certificate Private Key, to become malicious and abuse the possession of a key/certificate. Even with the adoption of this ballot, as written, a sophisticated attacker with proper positioning in network paths, would be able to exploit that position, even if certificates were valid for 5 days.
In real-life examples, when a Domain Name changes ownership, the new owner controls the DNS of that Domain Name and points it to new web servers. The old owner (and any third-party with access to the old key/certificate) can abuse that material, only in environments where they can manipulate DNS and intercept network traffic. The best way for the new owner to protect against such a (low probability?) risk, is to contact the CA that issued the old certificate and request revocation using 4.9.1.1 (5) by proving control of the Domain Name.
- As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.
When there is improper validation within the CA, performing such an improper validation every X number of days does not seem to solve the issue. When an improper validation is identified, the current practice is that the CA is forced to revoke all mis-issued certificates according to 4.9.1.1 and does not wait for the certificates to naturally expire. That seems to solve the improper validation issue more effectively.
CRLs and OCSP are different technologies. To the best of my understanding, the privacy concerns are mainly focused on OCSP and not CRLs. If these concerns apply also on CRLs, please elaborate.
- Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
Indeed, revocation at Internet scale doesn't work efficiently, at least with the current IETF protocols allowed in the BRs. In the recent years, we've seen efforts by Browser vendors to develop proprietary solutions, based on CRLs, to protect relying parties from revoked certificates hours after that revocation takes place. If there are certain problems with the CRL size, the BRs could be updated with certain requirements and limitations.
For example, consider a requirement where an Issuing CA has a limit where if all its non-expired certificates were to be revoked, the produced CRL size must be lower than X amount of bytes. That would force the CA to create another ICA or to use partitioned CRLs. In any case, an ICA would need to stop issuing new certificates if it cannot meet that CRL size requirement. I know it sounds difficult and challenging to describe in a normative way, but does it make sense to people?
- Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.
Agreed in principle, but changing an algorithm in the WebPKI is not just about changing a certificate and support the new algorithm in a Browser. The entire ecosystem (libraries, 3p software/services) need to adopt the new algorithms before the WebPKI is secure. Such warnings are usually provided months, in some cases years, in advance. Reducing certificate validity does its part, but as mentioned in previous conversations, in such an emergency situation, the BRs could be updated to require the revocation of certificates with insecure algorithms in an expedited timeframe, without waiting for certificates to naturally expire.
- While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [10].
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://cabforum.org/uploads/Baseline_Requirements_V1.pdf#page=23
[3] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[4] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[5] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[6] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[7] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[8] - https://insecure.design/
[9] - https://zanema.com/papers/imc23_stale_certs.pdf
[10] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.htmlMotion
The following motion has been proposed by Clint Wilson (Apple) and endorsed by Nick France (Sectigo), Ryan Dickson (Google Chrome), and Ben Wilson (Mozilla)
You can view and comment on the Github pull request representing this ballot here.
Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version XXX as specified in the following redline:
On the actual ballot, please kindly consider the following comments/suggestions:
- HARICA supports gradual reduction of certificate validity up to 100 days. 90-day certificates have been working well for the majority of the WebPKI Subscribers for years. HARICA does not support certificate validity of 47 days for the following reasons:
- The number of Domain Names increase annually so the total number of certificates that need to be issued, retained in logs/databases and other historical records
- Certificate issuance will grow exponentially (2x in year 1, 4x in year 2, 8x in year 3), leading to a significant increase of maintenance and operational cost. Part of this cost increase, in some cases, will be shifted to Subscribers. It is not simple for CAs to predict today what changes need to happen in order to issue 8x their current certificate volume. Projections for up to 4x seem to be more feasible to design.
- Although Let's Encrypt demonstrated that 90-day certificates are feasible, it didn't come without mass-revocation risks [11] [12] to the ecosystem. It is too risky to move to 47-days without enough operational experience and data. This is not something that HARICA, and possibly other CAs, are ready to promise delivering for 2028, and make that promise today. There are too many unknowns.
- As discussed in [13] CT logs will have a significant impact due to the dramatic increase of issued certificates required to be logged. Infrastructure challenges for global voluntary tools like https://crt.sh will already struggle to handle the existing load and will be challenging to tackle the other proposed milestones for 200, 100-day certificates. HARICA's engineers consider that the 47-day certificates will be very difficult to manage for CT log servers and monitors, unless there is a completely different technology in 2028.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/5cd1bf68-ac46-4b58-a0c8-1991d139c12e%40harica.gr.
Aaron Gable
a consideration from the subscriber point of view is that many of them have routine "freeze times" where they try not to have to make any changes to their own infrastructure. 90 to 100 day certs are more likely to provide the window that they can schedule certificate renewal around those times
Wendy Brown - QT3LB-C
Wendy
Wendy Brown
Supporting GSA
FPKIMA Technical Liaison
Protiviti Government Services
703-965-2990 (cell)--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Salz, Rich
Can you please answer the question of what additional security is gained by using a 45 day certificate rather than a 90 day certificate for a website that remains under the same ownership during that period?
Security people usually frame this differently: *IF* something goes wrong, what is the exposure? As there is no practical revocation possible on the WebPKI, if something goes wrong (hosting provider has an incident, vandals attack the treasury, whatever), then cutting the exposure time in half could be a very useful thing.
We could take your question and run it the other way and ask what’s wrong with 450 day certificates?
Henry Birge-Lee
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/73119C81-6F08-402A-BD3A-78AD1C157215%40akamai.com.
Zane Ma
> This applies to every identity attribute/value in real life. People's names, company names, domain name owners, they can all change. The validity period of certain attributes, and the need to re-check, is a risk-based exercise with the main input being the frequency of changes of these attributes, along with the volume of those attributes. For example, if we take passports or ID cards for a large part of the global population, people do change their full names but the frequency is such that passports and ID cards are valid anywhere from 5 to 10 years (in some countries, even longer). Requiring every citizen to replace passports or IDs more frequently (e.g. every 1 year) would cause unnecessary global financial/administrative burden for negligible security gain.
> Out of all globally registered Base Domain Names, do we have any data or estimate of **how many** change owners on an annual basis? If this percentage is very very small, HARICA's position is that the financial/administrative overhead introduced by reducing the validity of certificates and the re-use period of Domain Name/IP Address validation evidence, is unreasonably high compared to the overall security benefit. Instead of focusing on ALL Internet Domain Name owners, the CABF should focus on the small number of Domain Names changing owners.
The paper [9] provides a lower bound estimate on the number of DNS names that have changed owners. Table 4 shows 3.6M effective second-level domains have changed ownership between 2013/04/16 – 2021/07/09, which averages to about 445K per year. Figure 5a is a proxy for the growth of domain ownership change, since it shows the monthly stale certificates rather than the FQDNs/e2LDs, and it indicates that the current domain ownership turnover rates are almost certainly much higher than 445K per year. This is a lower bound estimate since we can only detect ownership change that results in a new WHOIS registryCreationDate, which does not capture things like domain transfers that would be used for domain squatters/resellers. We did not account for these scenarios since they are difficult to measure.
I would argue that we care about absolute number of domains, not the percentage, because this is equivalent to a “post hoc” misissuance. Imagine if a CA was found to be issuing valid TLS certificates to the prior owner of a domain based on DCV reuse - this would be considered misissuance (but please correct me if I am wrong), and this is the same outcome that we observe with stale TLS certificates. Historically, the CA/Browser forum has treated even a single misissuance as problematic, and has never considered the percentage of domains that are misissued.
> In real-life examples, when a Domain Name changes ownership, the new owner controls the DNS of that Domain Name and points it to new web servers. The old owner (and any third-party with access to the old key/certificate) can abuse that material, only in environments where they can manipulate DNS and intercept network traffic. The best way for the new owner to protect against such a (low probability?) risk, is to contact the CA that issued the old certificate and request revocation using 4.9.1.1 (5) by proving control of the Domain Name.
Finally, one benefit of reducing certificate lifetimes that has not been mentioned in this thread yet is the scenario of certificates that are victim to key compromise. In the 18 months from 2021/10/01 – 2023/05/05, we found 202K e2LDs that experienced key compromise, and long certificate validity periods led to long exposure periods for these domains. Figure 9a shows that reducing all of the certificate lifetimes to 90 days would have reduced total exposure by 75.2%. To partially address Wendy's comment, further simulated reduction to 45-days would have reduced total exposure by 89.6%, which is also a 58% reduction relative to 90 days.
The paper [9] presents the risk side of certificate lifetime, and how shortening lifetimes to 45 days would reduce "post hoc" misissuance risk by 89.6%-97.3%, depending on the scenario. These quantified risks must certainly be considered against the operational costs / considerations brought up in this discussion, and I would be very interested to see if it is possible to compare these costs/considerations quantifiably.
[A] https://www.help.cbp.gov/s/article/Article-1284?language=en_US
Dimitris Zacharopoulos (HARICA)
Dimitris.
Aaron
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Roman Fischer
Dear Zane,
Please excuse if these questions have been asked before and feel free to direct me to discussion where they were answered if applicable.
In the paper "Stale TLS Certificates", which is the basis for the proposed ballot, section 5.1 looks at key compromise by ways of analyzing CRLs. The revocation reason is given by the certificate holder or the CA when revoking a certificate. At least before SC61 was introduced, the usage of revocation reason codes was less clearly described and the drop in Figure 4 in the document would allow the assumption that previously "key compromise" may have been used also for revocations where no effective key compromise happened.
Do you have any more recent data on revocations with reason code key compromise?
Similarly, Figure 5 A ends at 2021/2022 with a drastic drop. Since the spike in domain registrant change was explained by Let's Encrypt gaining popularity, it would be important to see what effect the change in certificate lifetime to 1 year (after 1. Sept. 2020) had. Do you have any data that would share a light on this?
Regarding Table 5: Do you have any indications that the malicious domains were indeed hijacked/stolen and not just moved from one registrar to another by the malicious actor themselves (e.g. from a normal provider to a "bullet proof" hoster)?
I understand that we are late in the discussion. For me it's just important to understand the data / research that is basically the basis for this big change.
Thank you & kind regards
Roman
Mike Shaver
Imagine if a CA was found to be issuing valid TLS certificates to the prior owner of a domain based on DCV reuse - this would be considered misissuance (but please correct me if I am wrong)
Mike Shaver
For example, we've read about certain highly regulated sectors that require approvals for changes by National Authorities, etc.
Similarly, allowing automated access to DNS servers from certain servers, requires policy changes and careful access control design and execution.
Mike Shaver
For me it's just important to understand the data / research that is basically the basis for this big change.
Henry Birge-Lee
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Amir Omidi
Dimitris Zacharopoulos (HARICA)
On Fri, Feb 7, 2025 at 12:52 AM 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
For example, we've read about certain highly regulated sectors that require approvals for changes by National Authorities, etc.
We have read about those, and it's unclear to me how legal or regulatory prohibitions on prompt reissuance are in fact compatible with the BRs' requirement that the Subscriber make a legal commitment that they are able to tolerate prompt revocation as required. My take is that they should not be on the public web PKI, and if that's a problem for the jurisdiction then they should fix their regulations to permit the correct operation of the web PKI by their constituents.
Can you help me understand why it's permissible under the BRs to issue (or reissue) to an entity that is legally enjoined from meeting the requirements of the BRs?
I think you're taking a sentence and moving it out of its original context. It is not permissible to violate the BRs, this is very clear. As we've seen in various public incidents, in practice, there are jurisdictions and industry sectors that have strict change management obligations. The current BRs allow enough time for website operators to satisfy the existing policies because certificates can be replaced manually within 398 days. My point was focusing on certificate issuance automation, and the fact that these jurisdictions and industry sectors must have the necessary time to make the proper adjustments/changes to allow automation. I don't think these changes can happen in the timeframe of SC-81 which is why a 5y plan was proposed.
Regarding prompt revocations, I don't want to expand on it, we've all seen more than enough discussions and arguments in various public incidents and public forums that I don't think we can add anything new to this topic here :-)
If "local law or regulation" trumps all aspects of the BRs *and* still permits issuance of certificates without those aspects of the BRs applying, then what's to keep a town/school/state from saying "it is against our regulations to perform DCV to verify any claim made by our residents/etc" and getting a bing.com certificate issued? In my opinion, if the entity is legally enjoined from meeting the requirements of the BRs, then that entity should not be permitted to participate in the web PKI. Without that, the entire premise of the BRs—relying parties can be sure that the properties of the BRs hold if they are presented with a TLS certificate from a trusted CA—seems to be pointless.
Similarly, allowing automated access to DNS servers from certain servers, requires policy changes and careful access control design and execution.
And indeed, Subscribers have some material amount of time during which to resolve those concerns, due to the generous timeline proposed in ballot 081. As far as I can tell, there hasn't been any information provided to help the WG distinguish between "Subscribers would rather not do this work if they don't have to" and "Subscribers cannot make this change under the schedule proposed by SC-081" or, even more specifically, "Subscribers cannot make this change under SC-081's schedule but *would* be able to under the counter-proposed extended schedule of five years".
I'm sure I'm not the only one who thought of the creation of a large-scale survey asking website operators if they would be able to meet the goals in the deadlines proposed in this ballot or to the 5y schedule, and also state challenges and other reasons justifying why they might not be able to meet the ballot-proposed 3y deadlines. Preparing such questions in order to produce acceptable results for the Browsers, will probably take some time. Would it make sense to agree in this WG with a set of questions that each CA can ask to their Subscribers, and present the results in 3 months? This would produce the necessary feedback and give the WG the proper insight for further planning, based on concrete evidence.
Without this large-scale survey, the only insight CAs can bring to the discussion is limited feedback from selected Subscribers that have expressed concerns.
We also can't blame the website operators for not reacting to the certificate validity reduction goal over the last 5-10 years because the security benefits of doing so were not very clear, and the signals from Browsers (e.g. the Chrome Root Program at the last F2F [1]), indicated that the shorter validity period for leaf certificates would be tackled after some other milestones (see slide 6 of [1]). Even today, website operators are questioning the security benefits of reduced certificate validity compared to the cost. A concrete 5y plan would definitely be "generous" but easier to get accepted by the industry, leaving room for the development and preparation of automated solutions, including reverse-proxy for legacy servers that are difficult to replace/update. The message should be "this is finally happening, the timeline is generous, let's work as a community to overcome challenges and share experiences".
With that said, I see a change of stance by Mozilla [2], [3], [4], [5], taking a stronger position against regulatory policies that may conflict with the replacement timelines mandated in section 4.9.1 of the BRs and causing extra delays. Also, [6] provides an excellent analysis how a CA can be compliant with both the BRs and regulatory frameworks that appear as conflicting, when in reality they are not. I think these are good and helpful signals for CAs to use in situations where they receive push back from governments and other regulatory frameworks under critical/essential infrastructure cybersecurity acts.
If one can't change the cert on a system that has to face the public web, one could for example put a proxy in front of it that does modern certificate management, and have it chain back with whatever certificate rules are most helpful. Set the internal certs to have 25-year validity, if they want, and redeploy some certificate touchers!
Are all the existing websites perfectly secured, patched and monitored? Of course not, but most of them have a TLS server certificate encrypting traffic and protecting Relying Parties on the web layer. Without automation, part of the web will be serving expired certificates and my concern is that Relying Parties will be instructed to click-through the warnings.
(Again, scoped to things that are part of the public web; internal systems that use the web PKI merely out of convenience versus the operators running their own PKI should not be driving policy decisions for the public web.)
In "closed" environments, for example in the EU Banking sector (and Open Banking), things are moving to non-WebPKI frameworks, using QWACs as described in standards like ETSI TS 119 495. I assume X9 will have a similar approach. However, public-facing websites of Banks will still need to use publicly-trusted certificates.
Dimitris.
[1]: https://cabforum.org/2024/10/08/minutes-of-the-f2f-63-meeting-in-seattle-wa-usa-october-8-10-2024/6-chrome-root-program-update.pdf
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1886665#c30
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1887888#c34
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1888882#c35
[5]: https://bugzilla.mozilla.org/show_bug.cgi?id=1889062#c36
[6]: https://bugzilla.mozilla.org/show_bug.cgi?id=1896053#c75
Dimitris Zacharopoulos (HARICA)
(Apologies for breaking the thread sequence, I accidentally deleted Clint's response and had to manually copy from the archive in order to respond).
Hi Clint,
Thank you for the responses/comments. Some additional comments/answers in-line.
Hi Dimitris,
Thank you for this feedback and review of the ballot. I’ve responded further in-line below and have updated the PR with this commit: https://github.com/cabforum/servercert/pull/553/commits/51548be90ef7c88c3642a78da617f5c18e4557d8
I plan on restarting the Discussion Period with v2 of this Ballot soon.
On Feb 4, 2025, at 10:16 AM, 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
Dear Members,
HARICA participated in the earlier discussions of this ballot. We would like to share our thoughts, comments, propose some changes to this ballot, and welcome any discussion on these ideas.
On 28/1/2025 7:02 μ.μ., 'Clint Wilson' via Server Certificate WG (CA/B Forum) wrote:
Purpose of Ballot
SC-081: Introduce Schedule of Reducing Validity and Data Reuse PeriodsBackground
The Web PKI is a complex, integral, and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1].
Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases (such as Private PKIs) are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version [2], the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns [3], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over time, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [4].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [5] [6]. In particular, the following are perceived benefits to the Web PKI:
- Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [7].
This applies to every identity attribute/value in real life. People's names, company names, domain name owners, they can all change. The validity period of certain attributes, and the need to re-check, is a risk-based exercise with the main input being the frequency of changes of these attributes, along with the volume of those attributes. For example, if we take passports or ID cards for a large part of the global population, people do change their full names but the frequency is such that passports and ID cards are valid anywhere from 5 to 10 years (in some countries, even longer). Requiring every citizen to replace passports or IDs more frequently (e.g. every 1 year) would cause unnecessary global financial/administrative burden for negligible security gain.
Out of all globally registered Base Domain Names, do we have any data or estimate of how many change owners on an annual basis? If this percentage is very very small, HARICA's position is that the financial/administrative overhead introduced by reducing the validity of certificates and the re-use period of Domain Name/IP Address validation evidence, is unreasonably high compared to the overall security benefit. Instead of focusing on ALL Internet Domain Name owners, the CABF should focus on the small number of Domain Names changing owners.
I’m not sure this approach makes as much sense to me. Within the scope of the CA/B Forum, we can make changes to data reuse periods. We can’t control how IANA requirements for domain owners evolve, how individual Registries and Registrars implement domain purchase and renewal processes, or how domain ownership changes annually. While I’m similarly curious as to the numbers here, I’m not sure it’s as relevant given the factors outside the scope of the Forum. Domain ownership is primarily relevant at the instance of certificate issuance and this ballot seeks to address the latent issue which is the gap between certificate issuance and demonstration of domain control by the certificate applicant — changes in domain ownership highlight the risks this gap poses, but even if domains never changed ownership, this gap is something we should be seeking to reduce else Certification Authorities can only be relied upon to certify the past and not the (near) present.
If there is concrete evidence that the vast majority of registered Base Domain Names do not change owners, requiring all owners to demonstrate control of their owned Base Domain Names every 10 days doesn't sound reasonable to me, from a security/cost benefit point of view.
The WebPKI cannot completely disregard/disconnect the Domain Name registration process because it directly affects the publicly-trusted TLS server ecosystem. If IANA and/or individual National Registries/Registrars were to completely relax rules for controlling Base Domain Name ownership, it would be pointless to add super-strict rules for Domain Control Validation because attackers would focus on the weakest link -the Domain Name Registration-, change Authoritative NS records and it's game over.
I believe Professor Ma's response provided helpful additional information about the number of "e2LDs" (effective second level domains) that changed DNS registrant. This information is in section 5.2 of the paper and it mentions that 3.6M e2LDs changed their registrant (please note that only "com" and "net" TLD domain registration info were examined). I couldn't find the total number of e2LDs collected by the research team (apologies if I missed it) so I would appreciate it if someone could identify that in the paper or in some other source. It would be interesting to see what percentage of Base Domain Names change owners.
Phasing-in some sort of WHOIS/RDAP polling for Base Domain Name changes of ownership against Domain Name Registrars could leverage this in a more balanced way.
The reduction in domain name reuse period occurs over several years. I’m not opposed to an alternative approach, which equivelantly addresses the same issues, being introduced during that time, however I don’t believe SC-081 needs to change in order to accommodate a potential alternative. I’ll also observe that it sounds like your recommendation would introduce an increased level of complexity for CAs in meeting the compliance requirements.
Yes, there are tasks that require increased complexity, but there are usually good reasons behind requiring such complexity. MPIC is a recent example of that.
I envision allowing CAs an option:
- Perform Domain Control Validation more frequently than 398 days; or
- Start with 398 days re-use period but check WHOIS/RDAP
registrant information of Base Domain Names every 100 (?) days.
- In 100 days, check if the registrant information remains the same as during the initial DCV. If no changes, reuse DCV. If the registrant information changes, stop reusing DCV and notify Subscriber to perform new DCV.
- Repeat the same check in 200 and 300 days
- In 398 days, stop reusing DCV.
Option 2 would effectively provide the same level of assurance but would require less work from Subscribers.
If you and others think that this is a good alternative and would be willing to accept as an option, I can work on some language in a future ballot.
- The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [8] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [9].
HARICA disagrees with the initial parameters/assumptions described in [9] which seem to lead to incorrect security assumptions. This paper was discussed in https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/3q07n2tISkI/m/QvEQXcbLAgAJ. This discussion does not seem to have addressed all concerns and observations. The last comment submitted by Henry Birge-Lee is that some observed attacks took place "within even the proposed 47 day lifespan". The attacks described in the paper require an initially-assumed trustworthy third-party (a CDN/hosting/reverse proxy provider or reseller), with access to a Certificate Private Key, to become malicious and abuse the possession of a key/certificate. Even with the adoption of this ballot, as written, a sophisticated attacker with proper positioning in network paths, would be able to exploit that position, even if certificates were valid for 5 days.
In real-life examples, when a Domain Name changes ownership, the new owner controls the DNS of that Domain Name and points it to new web servers. The old owner (and any third-party with access to the old key/certificate) can abuse that material, only in environments where they can manipulate DNS and intercept network traffic. The best way for the new owner to protect against such a (low probability?) risk, is to contact the CA that issued the old certificate and request revocation using 4.9.1.1 (5) by proving control of the Domain Name.
In your first paragraph, you seem to acknowledge that SC-081 does not fully address these risks even at more extreme maximum certificate validity periods. However, your recommended fix is then to utilize a service which is well acknowledged (especially by relying parties) as inadequate for conveying security critical information in a timely manner. This should not be interpreted to mean certificate status services have no value (or even insufficient value to warrant their operation), but that their value is constrained and should not be relied upon as a primary and/or sole mechanism for ensuring certificate reliability on the web.It seems to me that the best way for a new owner to be protected against such a risk is for the risk to never occur in the first place. Reducing domain validation data reuse periods coupled with reducing certificate validity periods goes a very long way towards preventing the risk. Beyond that, certificate status services remain available to further address the risk should it be encountered by domain owners.
But the risk doesn't go away. An attacker will try to take advantage of any period available, and usually it will be the period just after the Base Domain Name is transferred. Reducing the validity of certificates doesn't seem to prevent that threat.
- As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.
When there is improper validation within the CA, performing such an improper validation every X number of days does not seem to solve the issue. When an improper validation is identified, the current practice is that the CA is forced to revoke all mis-issued certificates according to 4.9.1.1 and does not wait for the certificates to naturally expire. That seems to solve the improper validation issue more effectively.
Agreed, performing improper validation repeatedly does not solve the issue. However, setting a firm, baked-in upper limit on the amount of time such improper validation could be relied upon by relying parties does greatly help to reduce the risks associated with this issue. As noted above and below, revocation and the requirements in 4.9.1.1 have proven time and time again to be insufficient, but they remain part of the equation — the “suspenders” to the “belt” of validity and data reuse periods.
It does, but at a significantly high cost and the security benefit seems negligible, especially if the vast majority of Base Domain Name owners remain the same over a 1y period.
CRLs and OCSP are different technologies. To the best of my understanding, the privacy concerns are mainly focused on OCSP and not CRLs. If these concerns apply also on CRLs, please elaborate.
- Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
Indeed, revocation at Internet scale doesn't work efficiently, at least with the current IETF protocols allowed in the BRs. In the recent years, we've seen efforts by Browser vendors to develop proprietary solutions, based on CRLs, to protect relying parties from revoked certificates hours after that revocation takes place. If there are certain problems with the CRL size, the BRs could be updated with certain requirements and limitations.
For example, consider a requirement where an Issuing CA has a limit where if all its non-expired certificates were to be revoked, the produced CRL size must be lower than X amount of bytes. That would force the CA to create another ICA or to use partitioned CRLs. In any case, an ICA would need to stop issuing new certificates if it cannot meet that CRL size requirement. I know it sounds difficult and challenging to describe in a normative way, but does it make sense to people?
Investments are and will continue to be made in making certificate status services relevant and valuable to relying parties, but as best as can be determined, the upper limit of those services is below the acceptable limit for the reliability of certificates on the web. Thus, beyond concurrent improvements to certificate status service utilization, we believe there to be substantial and intrinsically unique value in continuing the 10+ years of efforts in reducing certificate validity and data reuse periods.
Understood.
- Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.
Agreed in principle, but changing an algorithm in the WebPKI is not just about changing a certificate and support the new algorithm in a Browser. The entire ecosystem (libraries, 3p software/services) need to adopt the new algorithms before the WebPKI is secure. Such warnings are usually provided months, in some cases years, in advance. Reducing certificate validity does its part, but as mentioned in previous conversations, in such an emergency situation, the BRs could be updated to require the revocation of certificates with insecure algorithms in an expedited timeframe, without waiting for certificates to naturally expire.
Within the scope of the Forum, we should be ensuring the ecosystem we’re responsible for is prepared the known, necessary changes that will need to be made in coming years. This is not the sole factor or reason (as none of the prior points have been either) for proposing the changes in this ballot. We are providing the warning of these changes years in advance of when they will need to be made, such that preparations can be made and resources can be allocated. The end result being a Web PKI that can, if or when necessary, maintain its security properties even when relatively rapid change is required. This is a property the Web PKI MUST have, but which it does not currently consistently have. As noted above, revocation alone is insufficient (especially when talking about the potential deprecation of cryptographic primitives upon which revocation itself relies).
Your position is clear and I agree that the webPKI does not currently have rapid change capabilities consistently across all website operators. Based on current (small) input, I disagree that 3 years is "years in advance" for a task of this scale and magnitude. I hope other CAs can share their insights from their Subscribers, even without a concrete survey in place.
- While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [10].
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://cabforum.org/uploads/Baseline_Requirements_V1.pdf#page=23
[3] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[4] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[5] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[6] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[7] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[8] - https://insecure.design/
[9] - https://zanema.com/papers/imc23_stale_certs.pdf
[10] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.htmlMotion
The following motion has been proposed by Clint Wilson (Apple) and endorsed by Nick France (Sectigo), Ryan Dickson (Google Chrome), and Ben Wilson (Mozilla)
You can view and comment on the Github pull request representing this ballot here.
Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version XXX as specified in the following redline:
On the actual ballot, please kindly consider the following comments/suggestions:
- HARICA supports gradual reduction of certificate validity up to 100 days. 90-day certificates have been working well for the majority of the WebPKI Subscribers for years. HARICA does not support certificate validity of 47 days for the following reasons:
- The number of Domain Names increase annually so the total number of certificates that need to be issued, retained in logs/databases and other historical records
- Certificate issuance will grow exponentially (2x in year 1, 4x in year 2, 8x in year 3), leading to a significant increase of maintenance and operational cost. Part of this cost increase, in some cases, will be shifted to Subscribers. It is not simple for CAs to predict today what changes need to happen in order to issue 8x their current certificate volume. Projections for up to 4x seem to be more feasible to design.
- Although Let's Encrypt demonstrated that 90-day certificates are feasible, it didn't come without mass-revocation risks [11] [12] to the ecosystem. It is too risky to move to 47-days without enough operational experience and data. This is not something that HARICA, and possibly other CAs, are ready to promise delivering for 2028, and make that promise today. There are too many unknowns.
- As discussed in [13] CT logs will have a significant impact due to the dramatic increase of issued certificates required to be logged. Infrastructure challenges for global voluntary tools like https://crt.sh will already struggle to handle the existing load and will be challenging to tackle the other proposed milestones for 200, 100-day certificates. HARICA's engineers consider that the 47-day certificates will be very difficult to manage for CT log servers and monitors, unless there is a completely different technology in 2028.
The unknowns described here will not become knowns until or unless we move towards substantial decreases in certificate validity and data reuse periods. Intentionally, if problems are identified which put the availability and operation of the Web PKI at risk, SC-081 provides sufficient time between reductions for future ballots to update the timelines defined here in response. As a concrete example, if the perceived benefits of static-ct-api logs are not realized, it is possible (though not assured) that would warrant some further changes to Section 6.3.2 in the next 3 years.
Without more concrete evidence (like the survey proposal), I'm afraid we'll all be guessing what would constitute a sufficient time-frame for reducing certificate validity periods for all Internet website operators to adapt to. I appreciate the comment about making amendments to the BRs as new information comes in over the next months/years, but as you said, it's not assured. For the same reasons, I think delivering 47-day certificates is a future promise that CAs may not be able to make today. It could be added later in a future ballot if the WG sees that everything is going well with the reduction to 200 and 100 days.
Regarding the last part of my email about possible assistance by Browsers in their UI, could you please share some thoughts or comment on Apple's view?
Thank you for all the discussion. It's very important to try to explain the different perspectives, challenges and consequences produced by this ballot, and I understand that both sides (CAs and Browsers) lack concrete data from website operators regarding what would constitute a "reasonable" adoption timeline, during a "time of peace" (i.e. no imminent, severe security threats in sight) :-)
Bottom line, I know that feedback from website operators will insist on maintaining the "status quo", or try to get the maximum available time at their disposal which is important to ask the right questions in a consistent manner, framing the problem as "this is going to happen, what specific challenges do you foresee to implement these changes and what is the rough/estimated cost".
Best regards,
Dimitris.
Kind regards,-Clint
Dimitris Zacharopoulos (HARICA)
Hi, I am the author of [9], and I am writing to clarify a few points.
> This applies to every identity attribute/value in real life. People's names, company names, domain name owners, they can all change. The validity period of certain attributes, and the need to re-check, is a risk-based exercise with the main input being the frequency of changes of these attributes, along with the volume of those attributes. For example, if we take passports or ID cards for a large part of the global population, people do change their full names but the frequency is such that passports and ID cards are valid anywhere from 5 to 10 years (in some countries, even longer). Requiring every citizen to replace passports or IDs more frequently (e.g. every 1 year) would cause unnecessary global financial/administrative burden for negligible security gain.
While I agree that identity verification is a risk-based exercise, the passport analogy is not pertinent because physical passports differ greatly from digital credentials. First, issuance of digital credentials can be (and often is!) automated, and it can scale much more easily than physical credentials. This also means that the abuse of digital credentials is much easier to scale, so tighter regulations are needed. The analogy with passports does not really apply to US passports, because if you change your name without renewing your passport, you are expected to carry an additional proof of name change when entering the country. [A]
> Out of all globally registered Base Domain Names, do we have any data or estimate of **how many** change owners on an annual basis? If this percentage is very very small, HARICA's position is that the financial/administrative overhead introduced by reducing the validity of certificates and the re-use period of Domain Name/IP Address validation evidence, is unreasonably high compared to the overall security benefit. Instead of focusing on ALL Internet Domain Name owners, the CABF should focus on the small number of Domain Names changing owners.
The paper [9] provides a lower bound estimate on the number of DNS names that have changed owners. Table 4 shows 3.6M effective second-level domains have changed ownership between 2013/04/16 – 2021/07/09, which averages to about 445K per year. Figure 5a is a proxy for the growth of domain ownership change, since it shows the monthly stale certificates rather than the FQDNs/e2LDs, and it indicates that the current domain ownership turnover rates are almost certainly much higher than 445K per year. This is a lower bound estimate since we can only detect ownership change that results in a new WHOIS registryCreationDate, which does not capture things like domain transfers that would be used for domain squatters/resellers. We did not account for these scenarios since they are difficult to measure.
I would argue that we care about absolute number of domains, not the percentage, because this is equivalent to a “post hoc” misissuance. Imagine if a CA was found to be issuing valid TLS certificates to the prior owner of a domain based on DCV reuse - this would be considered misissuance (but please correct me if I am wrong), and this is the same outcome that we observe with stale TLS certificates. Historically, the CA/Browser forum has treated even a single misissuance as problematic, and has never considered the percentage of domains that are misissued.
> In real-life examples, when a Domain Name changes ownership, the new owner controls the DNS of that Domain Name and points it to new web servers. The old owner (and any third-party with access to the old key/certificate) can abuse that material, only in environments where they can manipulate DNS and intercept network traffic. The best way for the new owner to protect against such a (low probability?) risk, is to contact the CA that issued the old certificate and request revocation using 4.9.1.1 (5) by proving control of the Domain Name.
I would agree that in the standard case, the security threat would require an adversary that can intercept network traffic (manipulating DNS is not necessary). However, this is true of nearly all certificate misissuance scenarios - the potential harms require an active on-path adversary who can serve a misissued certificate. Additionally, the likelihood of an intercepting adversary is context-dependent; for example, it is very likely for folks in countries with adversarial/censoring ISPs. I would argue that the CA/B community should strive to account for these scenarios.
Finally, one benefit of reducing certificate lifetimes that has not been mentioned in this thread yet is the scenario of certificates that are victim to key compromise. In the 18 months from 2021/10/01 – 2023/05/05, we found 202K e2LDs that experienced key compromise, and long certificate validity periods led to long exposure periods for these domains. Figure 9a shows that reducing all of the certificate lifetimes to 90 days would have reduced total exposure by 75.2%. To partially address Wendy's comment, further simulated reduction to 45-days would have reduced total exposure by 89.6%, which is also a 58% reduction relative to 90 days.
Is that a reasonable thing for a Subscriber to do? Obviously it's not. But we've seen website operators using unpatched systems and compromised servers preferring convenience over security, even supporting protocols like TLS 1.0. There is so much that CAs and Browsers can do to protect Relying Parties.
The paper [9] presents the risk side of certificate lifetime, and how shortening lifetimes to 45 days would reduce "post hoc" misissuance risk by 89.6%-97.3%, depending on the scenario. These quantified risks must certainly be considered against the operational costs / considerations brought up in this discussion, and I would be very interested to see if it is possible to compare these costs/considerations quantifiably.
Sincerely,
Dimitris.
[A] https://www.help.cbp.gov/s/article/Article-1284?language=en_US
--On Wednesday, February 5, 2025 at 10:10:56 PM UTC-5 Henry Birge-Lee wrote:
Hi all,
I would like to address one specific point brought up by Dimitris regarding a previous message I made on the server cert working group list.
Dimitris stated that:The last comment submitted by Henry Birge-Lee is that some observed attacks took place "within even the proposed 47 day lifespan". The attacks described in the paper require an initially-assumed trustworthy third-party (a CDN/hosting/reverse proxy provider or reseller), with access to a Certificate Private Key, to become malicious and abuse the possession of a key/certificate. Even with the adoption of this ballot, as written, a sophisticated attacker with proper positioning in network paths, would be able to exploit that position, even if certificates were valid for 5 days.
To clarify, as I stated in an earlier response, the attack I was referring to has no relation to the IMC 2023 Stale TLS Certificates paper by Zane Ma (citation [9] in the proposed ballot preamble). I do find the methodology presented in that paper convincing and feel stale certificates are a valid risk, but my comment was in relation to a specific attack I was aware of that did not use the particular attack vector analized by Zane Ma's 2023 IMC paper. Thus, I would consider evidence I have presented independently from the arguments in Zane's paper. The attacker I was referring to was not in the position of an assumed trustworthy third-party that became malicious. It was a BGP attack on domain control validation.
My comments regarding certificate reuse for revictimization was to point out that this (certificate reuse for revictimization) is an established adversary behavior. If an adversary loses access to the infrastructure they originally used to obtain the malicious certificate (which I also discussed in my original posting), the window during which an adversary can conduct this revictimization is dependent on the validity of the certificate. Obviously, even very short certificate validity windows cannot prevent misissuance and revictimization with an existing cert can happen. However, the window during which a website is vulnerable to this attack can be reduced with shorter validity certificates.
While I was giving a reference to a more recent attack that I cannot fully discuss publicly, the point I was trying to make I feel is well presented in the 2011 DigiNotar attack. This attack lead to several high-profile misisuances including a malicious certificate for torproject.org and a malicious *.google.com wildcard cert that was used to man-in-the-middle Iranian Gmail users ( https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html ). Even in this extreme case where the attack was detected and DigiNotar was removed from trust roots, corner cases with the revocation rollout lead to clients that still trusted the malicious certificates even in September 2011 ( https://arstechnica.com/gadgets/2011/09/safari-users-still-susceptible-to-attacks-using-fake-diginotar-certs/ ). Shorter cert lifespans (including the 47 days proposed in the ballot) could have lead to sooner protections for those clients.
I happen to know Roger Dingledine of Tor Project and he mentioned the threat of the DigiNotar certificate (and misissued certificates in general) many times. For a security-critical project like Tor Project that relies upon the PKI to distribute their software package, the threat caused by the existence of a trusted certificate in the hands of an adversary is immense and reducing this window is critical. Had certificate validity been shorter, the window in which websites like torproject.org and gmail would have been vulnerable to these interception attacks on unpatched clients would have been smaller. Furthermore, I personally feel this is a rare case of a well documented misissuance. I am familiar with many cases that never lead to revocation. In these scenarios, updates to protect clients are never sent out and the attack window is determined solely by the validity time of the misissued certificate. Finally, I think this is a good example of a case where an adversary loses access to its ability to misissue certs after attack detection thus preventing the adversary from renewing its malicious certificates.
Overall, I feel there is justification for shorter certificate lifespans that comes from attack forensics and presents evidence independent of Zane's paper.
Best,Henry
On Wed, Feb 5, 2025 at 5:30 PM 'Salz, Rich' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
Can you please answer the question of what additional security is gained by using a 45 day certificate rather than a 90 day certificate for a website that remains under the same ownership during that period?
Security people usually frame this differently: *IF* something goes wrong, what is the exposure? As there is no practical revocation possible on the WebPKI, if something goes wrong (hosting provider has an incident, vandals attack the treasury, whatever), then cutting the exposure time in half could be a very useful thing.
We could take your question and run it the other way and ask what’s wrong with 450 day certificates?
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/73119C81-6F08-402A-BD3A-78AD1C157215%40akamai.com.
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Mark Gamache
Sent: Tuesday, February 11, 2025 12:01 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins | SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods
Ryan Dickson
Hi all,
In response to both Clint and Mike, Dimitris suggested the perceived value of surveying website operators to better understand the impact of the timelines described in Ballot SC-081. While the intent of this recommendation is certainly in the right place, it makes a few assumptions that, from the Chrome Root Program’s perspective, ultimately undermine the usefulness of such an approach.
If respondents cannot reliably differentiate public and private PKI use cases, or are otherwise confused about the ballot’s impact, the proposed survey’s conclusions will be fundamentally flawed. Despite what we feel was a clear ballot preamble recorded by Clint, numerous instances of confusion about the scope of TLS BRs persist (e.g., 1, 2, 3, etc.) – which is understandable, because it is not the job of website operators to understand the TLS BRs. This confusion would most likely invalidate survey results, as responses would not accurately reflect the public Web PKI's intended focus. Furthermore, relying solely on subscriber feedback is problematic, as perceptions often diverge from reality. Over the past year, this was illustrated in public incident reports by contradictory understandings of “exceptional circumstances” and the impact of adhering to the revocation timelines stipulated by the BRs.
Further, the majority of certificates issued by the Web PKI and the majority of certificates relied upon by Chrome when establishing TLS connections (1) already rely on automation and (2) already have a validity of <= 90 days. If you are a website operator that’s already adopted automation, what would compel you to complete the proposed survey? A survey, as described, will inherently bias responses to the motivations of website operators who favor longer-lived certificates, and does not consider those responsible for acting on behalf of potentially millions or billions of users (i.e., Root Store Operators). Even if these issues were resolved, there's no clear method for scoring or utilizing the survey results to meaningfully guide next steps.
Survey aside and referenced across several SC-081-related emails, it appears that some seek evidence of actual harm having already occurred to be a prerequisite for enhancing security and realizing all of the benefits identified in this ballot's preamble. We previously responded to this line of thinking, and feel it’s worth repeating that it's flawed.
As Clint stated, if substantiated risk is identified related to the proposed timelines, and if it is justified in doing so, the SCWG could move to address said impact by updating the requirements proposed in this ballot (e.g., prolonging the duration where the maximum validity period is 100 days). The current proposed timeline allows for this type of activity to occur - and the phased implementation schedule will help force unknown issues to light. At the same time, it may also promote information sharing and lessons-learned that otherwise will continue to be siloed.
Ultimately, we feel that the most reliable method of determining real impact is by setting future dates for the implementation of security-enhancing shorter-lived certificates. This opinion is further supported, given over the past two years, we’ve made very direct public statements (e.g., 1 and 2) related to our goals of promoting reduced certificate lifetime. However, those statements, even when referenced directly by CA Owners participating in this community, may have been unsuccessful in motivating (1) some product owners to improve automation support and (2) website operators from adopting available automation solutions (again, as observed in public incident reports). It is our opinion that in the absence of clear requirements for reducing certificate validity, as accomplished in SC-081 or possibly through a root program policy, the ecosystem will never be “ready.”
Unlike previous validity reductions, the ecosystem should now be better prepared, thanks to the widespread adoption of automated certificate issuance and lifecycle management solutions like ACME. These tools, which have seen substantial improvements in efficiency, reliability, and native integration in the last 5-10 years, make shorter certificate lifetimes and reduced domain control validation reuse periods significantly less burdensome - and come with other intrinsic benefits. We’d expect, as observed in the past, any proposed validity reduction will further contribute to the maturity of automation solutions, further easing the transition for website operators.
It was also stated: “We also can't blame the website operators for not reacting to the certificate validity reduction goal over the last 5-10 years because the security benefits of doing so were not very clear, and the signals from Browsers (e.g. the Chrome Root Program at the last F2F [1]), indicated that the shorter validity period for leaf certificates would be tackled after some other milestones (see slide 6 of [1]).” We disagree with this example and would be remiss if we didn’t highlight that many of those “other milestones” we conveyed were considered fundamental to the success of an eventual certificate validity reduction (e.g., first requiring CA Owners to provide support for automated certificate issuance and management enables a more seamless reduction of validity).
Rather than suggesting the earlier “Moving Forward, Together” initiatives were considered more important than certificate validity reduction, it should be viewed as a recognition that substantial changes like those described in this ballot require time for planning and collaboration. And for over two years, since first announcing our validity reduction goal, we've been actively engaged in that process - as we know others have (e.g., 1, 2, 3, 4, etc.).
-Ryan (on behalf of the Chrome Root Program)
Dimitris Zacharopoulos (HARICA)
Hi all,
In response to both Clint and Mike, Dimitris suggested the perceived value of surveying website operators to better understand the impact of the timelines described in Ballot SC-081. While the intent of this recommendation is certainly in the right place, it makes a few assumptions that, from the Chrome Root Program’s perspective, ultimately undermine the usefulness of such an approach.
If respondents cannot reliably differentiate public and private PKI use cases, or are otherwise confused about the ballot’s impact, the proposed survey’s conclusions will be fundamentally flawed. Despite what we feel was a clear ballot preamble recorded by Clint, numerous instances of confusion about the scope of TLS BRs persist (e.g., 1, 2, 3, etc.) – which is understandable, because it is not the job of website operators to understand the TLS BRs. This confusion would most likely invalidate survey results, as responses would not accurately reflect the public Web PKI's intended focus. Furthermore, relying solely on subscriber feedback is problematic, as perceptions often diverge from reality. Over the past year, this was illustrated in public incident reports by contradictory understandings of “exceptional circumstances” and the impact of adhering to the revocation timelines stipulated by the BRs.
...the creation of a large-scale survey asking website operators if they would be able to meet the goals in the deadlines proposed in this ballot or to the 5y schedule, and also state challenges and other reasons justifying why they might not be able to meet the ballot-proposed 3y deadlines.
which is why it's important to ask "the right questions", that I believe could be achieved in this WG. For example, we wouldn't ask "what benefit do you see from reducing the certificate validity", we would take it for granted that "this validity reduction is happening", and focus on possible implementation challenges -if any- that website owners foresee in meeting the ballot's timelines.
To be fair, even within the CABF SCWG, it not entirely clear what the scope of the TLS BRs is, and there have been a lot of discussions about what are the intended consumers of such certificates. Section 1.1 of the TLS BRs says (emphasis mine):
"This document describes an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are necessary (but not sufficient) for the issuance and management of Publicly-Trusted TLS Server Certificates; Certificates that are trusted by virtue of the fact that their corresponding Root Certificate is distributed in widely-available application software. The requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying-party Application Software Suppliers."
"These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet"
The only part that IS very clear, is that the TLS BRs:
"...do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier"
The survey wouldn't need to address this issue at all, and could avoid questions related to the scope of Publicly-Trusted TLS Certificates, public/private PKIs.
However, please take into consideration that the WebPKI is not currently being used solely by Browsers. There are a large number of "Application Software Suppliers" consuming WebPKI Certificates, and the reason the group is maintaining such a long long history of supported interoperability and backwards compatibility is because an unknown number of libraries and TLS implementations are used for TLS server authentication. If it was clear that the TLS BRs are applicable/scoped to the issuance and management of certificates consumed in modern browsers, we would be taking a completely different approach in changes such as SC081 and definitely change gears towards the adoption of more modern protocols and RFCs. For example, the group has discussed about sticking to RFC 5280 when it has been updated/superseded by a number of other RFCs in IETF.
If Chrome and other browsers have a strong position about the scope and consider that the intended consumers are modern browsers only, it would be very beneficial to discuss and see if we can reach consensus in updating section 1.1 of the BRs. It would actually solve a lot of misunderstandings in the publicly-trusted TLS server certificate ecosystem.
Further, the majority of certificates issued by the Web PKI and the majority of certificates relied upon by Chrome when establishing TLS connections (1) already rely on automation and (2) already have a validity of <= 90 days. If you are a website operator that’s already adopted automation, what would compel you to complete the proposed survey? A survey, as described, will inherently bias responses to the motivations of website operators who favor longer-lived certificates, and does not consider those responsible for acting on behalf of potentially millions or billions of users (i.e., Root Store Operators). Even if these issues were resolved, there's no clear method for scoring or utilizing the survey results to meaningfully guide next steps.
- Question 1: Have you already implemented automation in the certificate lifecycle management?
- Question 2: If you already use automation in the certificate
lifecycle management, do you foresee any technical or other
challenges in reducing the certificate validity period to 45
days in 2028? If yes, please elaborate.
Survey aside and referenced across several SC-081-related emails, it appears that some seek evidence of actual harm having already occurred to be a prerequisite for enhancing security and realizing all of the benefits identified in this ballot's preamble. We previously responded to this line of thinking, and feel it’s worth repeating that it's flawed.
As Clint stated, if substantiated risk is identified related to the proposed timelines, and if it is justified in doing so, the SCWG could move to address said impact by updating the requirements proposed in this ballot (e.g., prolonging the duration where the maximum validity period is 100 days).
The current proposed timeline allows for this type of activity to occur - and the phased implementation schedule will help force unknown issues to light. At the same time, it may also promote information sharing and lessons-learned that otherwise will continue to be siloed.
Ultimately, we feel that the most reliable method of determining real impact is by setting future dates for the implementation of security-enhancing shorter-lived certificates. This opinion is further supported, given over the past two years, we’ve made very direct public statements (e.g., 1 and 2) related to our goals of promoting reduced certificate lifetime. However, those statements, even when referenced directly by CA Owners participating in this community, may have been unsuccessful in motivating (1) some product owners to improve automation support and (2) website operators from adopting available automation solutions (again, as observed in public incident reports). It is our opinion that in the absence of clear requirements for reducing certificate validity, as accomplished in SC-081 or possibly through a root program policy, the ecosystem will never be “ready.”
Unlike previous validity reductions, the ecosystem should now be better prepared, thanks to the widespread adoption of automated certificate issuance and lifecycle management solutions like ACME. These tools, which have seen substantial improvements in efficiency, reliability, and native integration in the last 5-10 years, make shorter certificate lifetimes and reduced domain control validation reuse periods significantly less burdensome - and come with other intrinsic benefits. We’d expect, as observed in the past, any proposed validity reduction will further contribute to the maturity of automation solutions, further easing the transition for website operators.
It was also stated: “We also can't blame the website operators for not reacting to the certificate validity reduction goal over the last 5-10 years because the security benefits of doing so were not very clear, and the signals from Browsers (e.g. the Chrome Root Program at the last F2F [1]), indicated that the shorter validity period for leaf certificates would be tackled after some other milestones (see slide 6 of [1]).” We disagree with this example and would be remiss if we didn’t highlight that many of those “other milestones” we conveyed were considered fundamental to the success of an eventual certificate validity reduction (e.g., first requiring CA Owners to provide support for automated certificate issuance and management enables a more seamless reduction of validity).
Rather than suggesting the earlier “Moving Forward, Together” initiatives were considered more important than certificate validity reduction, it should be viewed as a recognition that substantial changes like those described in this ballot require time for planning and collaboration. And for over two years, since first announcing our validity reduction goal, we've been actively engaged in that process - as we know others have (e.g., 1, 2, 3, 4, etc.).
Thank you for the productive conversation.
Dimitris.
Dimitris Zacharopoulos (HARICA)
On a general note, I would like to highlight that the SCWG currently lists 51 CAs, 10 Browsers, 5 Associate Members and 39 Interested Parties, a total of 105 Members. I am a bit disappointed for the lack of active participation in this important discussion, especially from CA Members that have more visibility and engagement with Subscribers from Governmental Agencies and industry sectors with strict rules and regulations about change management, as stated in various delayed revocation public incidents in Bugzilla.
Have all those problems been resolved? Are these challenges no longer an issue?
Similarly, there are Subscribers that use WebPKI Certificates for a wide variety of use cases (server TLS certificates used in widely deployed call centers, payment services, etc.) that should move to alternate solutions. Is the proposed timeline sufficient for these changes?
Without that insight, the messages from HARICA's subscribers become less of an issue and we would be happy to support the ballot as-is.
Thank you,
Dimitris.
Purpose of Ballot
SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods
Background
The Web PKI is a complex, integral, and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS Baseline Requirements (TBRs) were first adopted in the CA/Browser Forum and subsequently incorporated into various Root Programs as an interoperable, basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the Web PKI.
The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the Internet” [1].
Certificates which match or are compatible with the profiles described in the TBRs can be (and are) used for a variety of purposes not addressed by the TBRs, but these use-cases (such as Private PKIs) are not directly in scope of the TBRs nor the changes proposed in this ballot.
The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version [2], the reality of certificate management practices — whether policy, practice, or technology — has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs.
Approach
Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns [3], it’s important to provide mechanisms for 1) substantiating previously unassessed risks and 2) altering course when necessary. Similarly, in order to shift more unknown unknowns towards known unknowns and known knowns over times, it is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary [4].
Benefits
The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes [5] [6]. In particular, the following are perceived benefits to the Web PKI:
- Certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates [7].
- The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [8] and recent research reinforces this risk, whether with domain expiration, key access/control by third parties, or other “security-relevant events that enable a third-party to impersonate a domain outside their control” [9].
- As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements, or specifications which govern such issuance. Requiring more frequent validation of information used in the issuance of certificates and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.
- Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies. A reduction to certificate lifetimes provides firm protection to users, independent of certificate status services, further reducing the associated costs to internet users.
- Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security-critical properties of certificate use. When factoring in the ever-present risk that a weakness may be identified with an algorithm, library, or similar component of the ecosystem at any time, with or without forewarning, it is vital that the Web PKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provides substantial support for smoothly — and, when necessary, swiftly — transitioning between deployed and supported cryptography.
- While not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability, and availability of certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates. Increased deployment of robust, bi-directional automation is not a panacea for challenges in the Web PKI, but it certainly helps [10].
[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://cabforum.org/uploads/Baseline_Requirements_V1.pdf#page=23
[3] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[4] - This follows a pattern present since Version 1 of the TBRs (which established an initial maximum validity period of 60 months along with a future reduction to 39 months) and most recently in Ballot SC-063 (which introduced an initial Short-Lived Subscriber Certificate validity period of 10 days with a future reduction to 7 days).
[5] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[6] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[7] - Fundamentally, the above property of certificates is not something which can be addressed through revocation of certificates without much more substantial changes to the ecosystem.
[8] - https://insecure.design/
[9] - https://zanema.com/papers/imc23_stale_certs.pdf
[10] - https://www.hezmatt.org/~mpalmer/blog/2024/01/30/why-certificate-automation-matters.htmlMotion
The following motion has been proposed by Clint Wilson (Apple) and endorsed by Nick France (Sectigo), Ryan Dickson (Google Chrome), and Ben Wilson (Mozilla)
You can view and comment on the Github pull request representing this ballot here.
Motion Begins
MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version XXX as specified in the following redline:
Motion Ends
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
- Start time: Tuesday, January 28, 2025 17:00 UTC (2025-01-28T17:00:00Z)
- End time: on or after Tuesday, February 11, 2025 17:00 UTC (2025-02-11T17:00:00Z)
Vote for approval (7 days)
- Start time: TBD
- End time: TBD
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/C4130A9A-BC51-43E9-873F-57069EFC3D6E%40apple.com.
Martijn Katerbarg
Hi Dimitris,
> On a general note, I would like to highlight that the SCWG currently lists 51 CAs, 10 Browsers, 5 Associate Members and 39 Interested Parties, a total of 105 Members. I am a bit disappointed for the lack of active participation in this important discussion, especially from CA Members that have more visibility and engagement with Subscribers from Governmental Agencies and industry sectors with strict rules and regulations about change management, as stated in various delayed revocation public incidents in Bugzilla.
> Have all those problems been resolved? Are these challenges no longer an issue?
I can obviously only speak for Sectigo and what we see from our perspective.
To be very short on both these questions, from our perspective the answer is no. These problems have not all been resolved. And not all of these challenges are no longer an issue.
That said, we as an industry I firmly believe have come a long way in the past few years. Are we there yet? No. Are we closer than we were a year ago? Yes!
Ever since reducing the current 398 day limit has been expressed as a desire, we’ve seen an increase in automation. We firmly believe that now is the time to not lose momentum.
There are Subscribers that have used automation for many years. There are also Subscribers that have picked up the pace based on Chrome’s “Moving Forward, Together” initiative. Then there’s the segment of Subscribers that won’t pick up at all until hard deadlines are set. Again, I’ll reiterate, we firmly believe the time has come to set those deadlines.
Setting hard deadlines now will allow those Subscribers that are falling behind due to unwillingness or inability from a resource perspective to request a change internally based on the changes in this ballot.
This proposal in our opinion brings a very reasonable and predefined year over year change and would give the power to those who need it to initiate change at government and/or organizational levels where it’s needed.
That is why we continue to support and endorse this ballot, as-is.
Regards,
Martijn
Roman Fischer
Dear Dimitris,
The problems are not resolved, the challenges remain. We agree with your assessment that a reduction to 90 days suffice and also don't see the benefit of going to 47 or even 10 days.
Thanks for all your efforts!
Kind regards
Roman
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/03b7430d-f310-49a9-9e6d-14bce47e7820%40harica.gr.
Chris Clements
Hi Dimitris,
In short and regarding the proposed survey, we still believe there are too many inherent challenges that prevent it from being actionable. Specific to your example questions:
How would one conclude and confirm the survey asks the “right” questions? (This is subjective.)
What’s a “challenge”? Who objectively determines its criticality and if that challenge is real or just perceived? (This is subjective.)
Is the SCWG prepared to objectively study, debate, and possibly seek clarifying details on potentially thousands or millions of responses? On what timeline? At what cost?
How would one ensure a truly random and representative sample to minimize or prevent sampling bias?
Again, why would we expect a website operator that’s already adopted automation to complete the proposed survey?
As we previously stated, if respondents cannot reliably differentiate PKI use cases, or are otherwise confused about the ballot’s impact, the proposed survey’s conclusions will be fundamentally flawed. Ultimately, if the survey data is unreliable, it will not be useful in guiding next steps, wasting time and resources for everyone involved. To that end, we see no value in the survey, or any further discussion related to it.
We still believe the most reliable method of determining real impact is by setting future dates for the implementation of security-enhancing short-lived certificates. We provided commentary on this line of thinking in our previous response.
Agreed. Perhaps I framed it poorly but I never meant to dismiss the Chrome Root Program's goal to reduce the validity of certificates. I just noted that website operators didn't have a clear path (even a tentative one) from Chrome or other browsers about an expected timeline to reduce certificate validity, giving them something concrete to take up to their management boards, allocate resources/budgets, and so on.
We wanted to focus on this statement, since it references the Chrome Root Program and the opportunity this ballot provides. While we could argue that Chrome offered a clear intent to explore the goals described in this ballot and a “tentative” path to members of the Forum via multiple F2F presentations (e.g., 1, 2, 3), and that motivated action from some CAs and some subscribers, we believe the point you were trying to make is more related to the value of having a clear timeline, which is exactly what this ballot intends to provide.
We understand that there is concern related to the validity reduction from 100 days to 47. It is our general view that if automation is sufficiently in place, the subscriber impact of any validity and DCV reuse reduction is trivial. Real-world examples demonstrating the value of automation, many of which are described in the ballot’s preamble, are readily available. These examples span a wide range of organizations from across the globe, including small and large, and those in highly regulated industries (including government and financial services). The phased timeline encourages adoption of automation, while doing so in a way that allows both challenges and their solutions to come to light.
We continue to support and endorse this ballot, as-is.
Thank you
-Chris
Wojciech Jakubowski
There's a saying in Poland that comes from an epic movie, which translates something like: "Make sure the pros don’t overshadow the cons." It's a satirical statement, but I believe it holds true in this situation. Security benefits are certainly there, no one denies that, but their significance is debatable. Once a certificate is issued, it usually sits in one place, typically protected by server/app restrictions or even HSM or Key Vault. You can’t really brute-force RSA/ECC, so from this perspective it doesn’t really matter whether it’s valid for 45 days or 450 days. The point that was discussed regarding certificates lingering after the previous domain owner is already debunked, as they can and should be revoked by the new owner.
So, what are we left with as a benefit? I can think of a few: a false sense of security that a cert is valid for a shorter period of time (yes, I marked it as a benefit on purpose!, as this will definitely expand certificate visibility to higher levels in organizations); faster rotation, which indeed makes brute force type attacks, maybe not on the cert itself, but on the app/server less effective; and finally, broader adoption of CLMs and raw automation solutions.
But are those benefits worth it? I would argue they are not. I believe there are bigger problems that reducing cert lifetimes doesn’t address, like poor private key handling and poor certificate deployments. These issues will likely become more frequent when certificate rotation happens 8 times a year.
Now, what are the issues with decreased lifetime? From the perspective of a certificate user/admin, I see two big ones: a lack of CLMs that cover 100% of scenarios, as well as internal company procedures that practically disallow automated changes and/or enforce long change schedules from bottom environments to top one, even for the smallest changes. And yes, that’s can be called bad design that should probably be changed, but ultimately, security is meant to protect business, not restrain it. And then there's also increased cost for both CAs and clients.
Certificates will be front and center for many organizations and apps, but is that the marketing we want? Do we want certificates to become a burden? This reminds me of the changes made to password policies a while ago. Passwords were set to never expire, then they were shortened to 90 days, and eventually to 30 days, with a history of the last 30 passwords, all character types, etc. This led to more password disclosures because people used simpler passwords, iterated and saved passwords more often on "paper", and reused the same passwords across different apps. So, in the end, it was decided to go back to passwords that never expire, with higher complexity requirements, which was in the end recognized as more secure approach.
If certificate lifetime is reduced to 45 days, I’m pretty sure we’ll see similar behavior - worse certificate handling, more revocation requests, more poorly implemented certificates, and more missed expirations. There are apps for which change can be done just few times a year; how will those cope? The assumption is they will automate, use CLMs, etc., but will they really? I can see some starting to use private certificates again. If the solution is not Internet facing, then probably majority of those will move to private CAs. I can also foresee new browsers being developed that won’t honor the 45-day validity period as the maximum. In general, there may be movement focused on how to workaround this shortened validity, which is not something anyone would want.
To summarize, I believe the current 398-day lifetime is a good compromise and should remain as is for a while longer. It would probably make sense to revisit this discussion in a few years, when more robust CLM solutions are available and PQC signing standards are adopted on a noticeable scale. An alternative approach would be to slow down the transition. As an example - start in late 2025 and reduce validity by 20 days per year. This would give organizations enough time to automate. An inevitable but gradual decrease would be something everyone could digest and even appreciate. The current proposal is simply too aggressive.
I think I added some controversy there, but as this is my first contribution, please go easy on me :)
蔡家宏(chtsai)
Dear Dimitris,
In fact, the challenges still remain and will not disappear overnight. Ultimately, these challenges will be faced by CAs when dealing with their customers.
We have carefully reviewed many past discussions on this matter and have taken each point into account, and we certainly appreciate the firm stance taken by the proponents.
However, by comparison, at this stage TWCA is more inclined to support the schedule proposed by Dimitris on February 5th, and we are provisionally favoring a final certificate validity period of 100 days.
At this time, we have no further feedback, and regardless, we will accept the final voting result.
We also thank Dimitris for his dedicated efforts.
Best Regards
蔡家宏 Chya-Hung Tsai
Director
Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw
From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B
Forum) <server...@groups.cabforum.org>
Sent: Thursday, February 13, 2025 3:51 PM
To: server...@groups.cabforum.org
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/03b7430d-f310-49a9-9e6d-14bce47e7820%40harica.gr.
Mads Egil Henriksveen
Hi Dimitris
Speaking on behalf of Buypass; we don’t think all problems are solved.
Our main concern is subscribers that have not yet automated their certificate management and, probably, will not be able to accomplish this (or move to alternative solutions) within the proposed timelines. This includes subscribers using legacy systems, e.g. within the health sector.
The discussion in yesterday’s SCWG meeting was very interesting and gave insight into many different proponents’ views. We do understand the importance of defining clear and predictable rules for decreasing the validity period with a final goal of driving the ecosystem towards automation. We acknowledge and support this.
However, we think the current time proposal is too aggressive. We support Dimitris’ proposal, i.e. a 5 year-period and a (for now) final validity period of 100 (or 90) days.
We don’t think it is feasible to reverse what should be clear and predictable rules for the WebPKI ecosystem (this is not comparable to the change of effective dates for NCSSR v2.0 which mainly affects CAs). It could be better to introduce the 47 days validity period at a later time, once we have gained some knowledge from the first steps.
Regards
Mads
From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B
Forum) <server...@groups.cabforum.org>
Sent: torsdag 13. februar 2025 08:51
To: server...@groups.cabforum.org
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/03b7430d-f310-49a9-9e6d-14bce47e7820%40harica.gr.
Zane Ma
> Further, the other use case called out by Ma and company, malicious attacks after change of ownership (Table 5), lacks clarity on methodology. If a malware actor acquired the abandoned domain, isn't it much more likely they just satisfied DCV and acquired new certificates? The paper seemed to avoid clarity on the actual certificates used for that traffic.
> Additionally, the observed 'revoked for key compromise' data makes big assumptions. It suggests that an attacker had access to the private key. Having done PKI for 20 years, I have found this exceedingly rare. What is common is to use key compromised as the reason code when someone may have exposed the key, even internally, such as in a scren share session or a support case.
> The old domain owner is almost certainly not malicious. They chose to part with the domain. Probably no one needs to be protected from them. Even of the old owner is malicious, the new owner can solve this all on their own after taking over the domain. Simply look at CT logs and per CABF rules get the CAs to revoke the certificates. Granted revocation is poorly enforced. The new owner, could choose to use names, other than the base domain, that have not stale vaid certificates.
> This proposal seems to be the CABF making things more painful in order to solve a problem that has better solutions or a problem that doesn't even exist.
In any case, assuming that we roughly agree on the operational burdens to CAs + subscribers (although concrete numbers would be very helpful here), where I think we disagree is whether the community should take a proactive or reactive stance to security. Please correct me if I am wrong, but your underlying argument seems to be that unless irrefutable evidence of malice exists, there is no reason for urgency. To me, 398-day certificates that are victim to key compromise (e.g., GoDaddy) is irrefutable evidence that a problem exists, even if abuse hasn't been directly measured. More generally, and this is now entering more ethical/philosophical territory, I would argue that even with less definitive evidence, it is the duty of the CA/Browser community to proactively spur subscribers to improve their security posture, similar to how governments require people to wear seatbelts in vehicles, despite reluctance from many.
As for how quickly to spur subscribers to improve their certificate security - that is beyond my expertise. My only thought here is that the reduction to 825-days in 2017 and then to 398-days in 2020 was met with resistance, but ultimately I am unaware of any notable negative fallout. Hopefully that experience provided CAs / subscribers a blueprint for how to pursue future reductions, 5 years later in 2025. Additionally, this prior experience suggests that although adopting stronger/shorter validity periods may be stressful, there is historical precedent that this is doable with limited negative impact on subscribers.
Zane Ma
Mark Gamache
Sent: Friday, February 14, 2025 9:59 AM
To: Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Cc: Zane Ma <ma...@oregonstate.edu>; Mark Gamache <ma...@markgamache.com>
Clint Wilson
Purpose of Ballot
Motion Ends
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
- Start time: Tuesday, January 28, 2025 17:00 UTC (2025-01-28T17:00:00Z)
- End time: on or after Tuesday, February 25, 2025 17:00 UTC (2025-02-11T17:00:00Z)
Vote for approval (7 days)
- Start time: TBD
- End time: TBD
On Jan 28, 2025, at 9:02 AM, 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:Purpose of Ballot
SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/C4130A9A-BC51-43E9-873F-57069EFC3D6E%40apple.com.
Andrew Chen
Chad Dandar (cdandar)
Dear Colleagues,
I appreciate the thoughtful discussions surrounding SC-081, making it clear that we share goals of meaningful improvement.
One commonality in this discussion has been that agility and efficiency gained by certificate lifecycle automation is not just ideal, but paramount. That efficiency is a requirement to achieve the goals of this proposal. I’m writing this email to focus on that element.
If each member listed the benefits of certificate automation, we would have quite an amazing list of lasting positives. Some big, many small.
Likewise, if we asked 10,000 subscribers to describe the level of effort to automate their environments, we would likely hear 10,000 different perspectives. This proposal and the great conversations around it motivated me to seek some perspectives. Over the last few weeks, I have spent more time that I’d care to think about speaking to friends, ex-colleagues, and others I trust in leadership or PKI roles at midsized companies to large corporations. Not a survey to decide for me. Simply asking to hear the mindset of those involved in this space from an operational level. Of course, I also have considered Cisco’s global span of products, services, and partners to help me feel more meaningfully equipped to discuss this.
Perspectives and concerns were analogous. Whether it’s a known lack of maturity, budget constraints, or unknown yet-to-be-discovered surprises (e.g. What if a developer hardcoded “renew every 270days” into critical legacy systems? Hopefully that is only a silly example.). Summarizing what I’m hearing is simple and not at all surprising...
Organizations—ranging from large enterprises with mature security programs to smaller businesses still managing certificates manually—will need time to fully grasp what this proposal means for them.
Combining that information along with the recurring CA/B sentiment “Maybe, but with what timeline and why that timeline?” motivated me to create a general phased path to automation to help visualize a practical timeline. My goal is not to propose a timeline that works for us. My goal is an attempt to define a baseline/timeline that’s reasonable for most.
Feedback, suggestions, and questions related to the following would be great!
---
Real-World Implementation Timeline of Certificate Automation
Transitioning to certificate automation is not as simple as adjusting issuance policies. It requires organizations to make modifications to their certificate management processes, redevelopment of net_new/existing/legacy services, enhanced tooling, and governance and compliance considerations.
The construct of the following timeline includes phases for discovery, solution building, implementation, and finalization. For midsized and large enterprises, these steps may be necessary, with each step requiring time for planning, execution, and troubleshooting. It is important to consider each phase has numerous steps that would all need to be accomplished in parallel. Each step includes an example for contemplation.
Phase 1: Impact Assessment and Planning (~12 months, 2025-2026)
- Discovery of Existing Certificate Landscape (6-12 months)
- Organizations must inventory all certificates in use, often spanning thousands of systems and multiple business units.
- Many enterprises still use spreadsheets or fragmented tracking systems, requiring investment in discovery tools.
A manufacturing firm discovers over 100,000 active certificates across its infrastructure, many of which are manually tracked in outdated spreadsheets.
- Risk and Compliance Assessment (6-12 months)
- Regulatory and compliance teams will need to determine how automation aligns with internal policies, industry regulations, and change control requirements.
- Security teams must evaluate potential risks of more frequent certificate renewals (e.g., failed renewals leading to outages).
A healthcare company assessing whether automated renewals aligned with HIPAA and internal security controls, defining potential risks related to unattended certificate replacements on legacy medical devices.
- Budget Planning for Automation (6-12 months)
- Many enterprises will need to secure budget for automation tools, personnel training, and process redesign, which often aligns with annual budget cycles.
An e-commerce company finds that purchasing a certificate lifecycle management (CLM) tool required budget approval a year in advance, delaying their automation efforts until the next fiscal cycle.
- Assessment of Non-Compatible Systems (6-12 months)
- Identify legacy or proprietary systems that lack ACME support and document manual certificate renewal dependencies.
- Work with software vendors and internal development teams to determine whether updates, API modifications, or alternative automation methods are feasible.
A telecom company discovers a large pool of devices in the field using certificates that are manually updated via quarterly firmware pushes. Requiring consideration of either private PKI or development work.
- Planning for Development Rework (6-12 months)
- Evaluate the level of effort required for refactoring applications to support automated certificate management.
- Prioritize mission-critical applications and assess whether temporary manual renewal processes will be required until development work is completed.
A financial services firm finds that its in-house payment processing application could not integrate with ACME-based automation. The development team estimated a 9-month rework effort to support API-driven certificate injection.
Phase 2: Tooling Selection and Proof of Concept (~12 months, 2026-2027)
- Engagement with Software Vendors and Open-Source Communities (6-12 months)
- For third-party software, initiate discussions with vendors about upcoming certificate lifecycle changes and their plans for automation support.
- If relying on open-source solutions, determine whether community-driven updates are in progress or if internal development contributions are needed.
A healthcare provider using mTLS with a third-party electronic medical record(EMR) system learns that a vendor needed time to support ACME integration in a future release, but until then, the IT team has to implement a workaround be creating a certificate distribution script.
- Evaluation of Certificate Lifecycle Management (CLM) Solutions (6-12 months)
- Organizations must evaluate commercial and open-source automation solutions, considering integration with existing IT infrastructure.
A financial services firm tests three CLM vendors but faced integration issues with its existing PKI infrastructure, requiring additional API development before final selection.
- Pilot Deployments and Controlled Testing (6-12 months)
- Initial deployment in non-production environments to validate automation workflows and detect unforeseen issues.
- Engaging key teams (networking, DevOps, security, compliance) to ensure new processes align with business needs.
A telecom provider rolls out ACME-based automation for internal test servers, revealing that some firewall rules blocked automated certificate renewals, requiring network team adjustments.
- Policy Development and Governance Updates (6-12 months)
- Updating internal security policies, procurement guidelines, and operational procedures to reflect new validity periods and automation standards.
A multinational tech company to update its internal security policies to mandate automation for TLS certificates, but pushback from compliance teams delays enforcement by many months.
Phase 3: Full-Scale Implementation and Stabilization (~18-24 months, 2027-2029)
- Enterprise-Wide Rollout of Automation (18-24 months)
- Gradual transition of existing certificates to automated issuance and renewal.
- Organizations must ensure legacy applications and third-party integrations support automated certificate management.
A global logistics company automates 75% of its certificates but discovers that some third-party vendors managing legacy APIs do not support ACME, requiring manual renewals for certain integrations until development work can be completed.
- Change Management and Training (12-18 months)
- IT and security teams need comprehensive training on new automation tools and workflows.
- Stakeholders must be educated on new renewal policies, escalation paths for failures, and compliance requirements.
An airline’s IT team has to retrain engineers and DevOps teams on automated certificate renewal processes, leading to unexpected delays during the initial rollout.
- Incident Response and Failover Planning (12-18 months)
- Enterprises need to develop contingency plans for failed automated renewals to prevent outages of critical services.
- Testing automated failover mechanisms for certificate renewals (e.g., backup CAs, redundancy strategies).
A telecom implements automated certificate renewals but faces critical issues when a scheduled firewall update blocked ACME requests, leading to new monitoring requirements and failover planning.
Phase 4: Optimization and Adaptation for Autonomy (~12 months, 2029-2030)
- Addressing remaining Legacy System Constraints (6-12 months)
- Some older applications and industrial control systems may lack native support for automated certificate renewals.
- Enterprises may be required to maintain manual certificate deployment.
A large energy company may struggle with outdated legacy industrial control systems that cannot support automated renewals, requiring a hybrid approach of semi-automated issuance with manual intervention for some critical infrastructure.
- Finalizing Compliance and Audit Adjustments (6-12 months)
- More frequent certificate rotations require updates to internal compliance policies and audit procedures.
- Security teams must ensure automated renewal processes generate proper logs and meet regulatory retention requirements.
A financial services firm has to update its internal audit processes to account for more frequent certificate changes, ensuring that automated renewals are properly logged and met regulatory retention requirements.
- Operationalizing Continuous Certificate Monitoring (6-12 months)
- Organizations need real-time monitoring and alerting mechanisms to detect and respond to failed renewals before they cause outages.
- Integrating certificate lifecycle data into SIEM platforms or similar for visibility, proactive support, and incident response.
---
Combining the phases above adds up to 5 years’ time.
I have not yet mentioned the primary purpose of SC-081, reducing certificate validity time. We know that a global change won’t come without such motivation. I think that change is adoption of automation, and reduced validity is a method to motivate it. And that is ok!
If we applied the math to the current start dates of this proposal it would take us to:
- March 15, 2030: Maximum certificate validity reduced to 47 days
An assumption that would need to accompany that date would be that all entities begin working on this effort immediately. Considering the context within the phases above, stepping down certificate validity prior to this date may leave many entities in a precarious state of unreadiness. I could see such a situation lead to backlash or the seeking of exemptions, which would erode the value of the underlying proposal.
If there is a strong desire for stepping down to motivate adoption, we should consider a practical number that leaves room for manual administration in the event they are still working towards automation.
The overall goal of this email is to initiate a baseline so in the event someone wants to propose a sooner or later timeline they can make revisions to a practical timeline to show evidence of their proposal.
I certainly see the value of how this proposal will help motivate positive changes for all. If we visualize the path together, do the math, agree on the timelines together, I think we’ll find that the world will be more agreeable with it.
Thank you for considering this perspective. I look forward to continuing the discussion and working toward a solution that balances security and practicality.
Best regards,
Chad Dandar
Cisco Systems
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/2ED85C0E-E508-4992-A162-AF0A11E66275%40apple.com.
Karina Sirota Goodley
Hi all,
Looking at Clint’s update and Chad’s in-depth analysis, I’m wondering if we should make this a topic of discussion for the face-to-face in SCWG section? There are a lot of considerations since this is effectively a plan for the forum and industry for the next half-decade (have we had ballots before that are so far reaching?)
I’m not sure what the most effective structure for discussion would be- presentations, unguided discussion?
Best,
Karina
Karina Sirota Goodley, MBA, MS
Security Program Manager 2
Trusted Root Program
Mike Shaver
Dimitris Zacharopoulos (HARICA)
Dear Mike,
Hi Karina,
I’m concerned, both selfishly and on behalf of other Interested Parties, that moving the discussion to the F2F would exclude some voices that have been making (IMO) productive contributions to the dialogue around lifetimes and validity. With Interested Parties being unwelcome at the F2Fs, and the inherent limitations of live note-taking, I fear that some engaged participants would be forced to the sidelines by lack of both context and representation.
(And even if IPs weren’t barred from the F2Fs, scheduling that time could be quite challenging for people whose jobs, for better or worse, do not include the CA/BF or PKI governance as “work”!)
I appreciate the desire for higher-bandwidth conversation, and I know it can be easier in some ways to devote a dedicated day than similar energy directed to fulsome email conversations, but I feel compelled to register my concern about how such a shift in venue might distort the conversation.
Thanks for your consideration,
FWIW, as a former CA/B and current SCWG Chair I have extended invitations to Interested Parties that want to participate in certain Teleconferences or F2F Meetings, especially when they want to contribute to the conversations/discussions on specific topics of interest. All of the Forum's F2F meetings are conducted in "hybrid" mode so I'm sure anyone interested can receive an invitation and join remotely.
Karina, Chad,
I will add this topic to the SCWG agenda for the next F2F. However, Chad has shared a lot of input that needs good preparation (perhaps a short presentation of the analysis) before the group can discuss. I will start another thread in the SCWG public list for F2F agenda topics and we will see how much time we can allocate to each topic.
Thank you,
Dimitris.
-- Dimitris Zacharopoulos CA/B Forum SCWG Chair
Mike Shaver
I appreciate your comments about IPs having inherent limitations due to the current structure and Bylaws of the CA/B Forum but I must object to your comment ("Interested Parties being unwelcome at the F2Fs").
Dimitris Zacharopoulos (HARICA)
On Sun, Feb 23, 2025 at 5:23 AM Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr> wrote:I appreciate your comments about IPs having inherent limitations due to the current structure and Bylaws of the CA/B Forum but I must object to your comment ("Interested Parties being unwelcome at the F2Fs").
I am glad to be corrected; I was led to believe that my remote joining of a previous F2F was deemed unwelcome, though I think I made constructive contributions when I was on the call.
Contributions are welcome but procedures must be followed. I didn't make these rules :-)
If IPs can attend remotely, then hopefully some of us who are indeed Interested in the topic of validity duration can manage to join the conversation proposed for the next SCWG F2F.
Best regards,
Dimitris Zacharopoulos (HARICA)
Thank you very much for the update and for moving the 47 days limit to 2029. It will certainly improve planning for website operators.
Since the main arguments for this update were challenges related to certificate lifecycle management automation, would you also please consider moving the 10 days data reuse periods to 2029, or even better, remove this last step? HARICA's preference would be to completely remove this 10-days step as less than 0.5% of Base Domain Names (in .com and .net TLDs) change owners within a 1-year period, as presented. In our opinion it would be too onerous for the 99.95% of Domain Owners to have to re-validate their Base Domain Names every 10 days.
Thank you,
Dimitris.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/2ED85C0E-E508-4992-A162-AF0A11E66275%40apple.com.
Rob B
Sent: Monday, February 24, 2025 6:57:34 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins | SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods
Dimitris Zacharopoulos (HARICA)
See in-line.
Hi Dimitris,
> On a general note, I would like to highlight that the SCWG currently lists 51 CAs, 10 Browsers, 5 Associate Members and 39 Interested Parties, a total of 105 Members. I am a bit disappointed for the lack of active participation in this important discussion, especially from CA Members that have more visibility and engagement with Subscribers from Governmental Agencies and industry sectors with strict rules and regulations about change management, as stated in various delayed revocation public incidents in Bugzilla.
> Have all those problems been resolved? Are these challenges no longer an issue?
I can obviously only speak for Sectigo and what we see from our perspective.
To be very short on both these questions, from our perspective the answer is no. These problems have not all been resolved. And not all of these challenges are no longer an issue.
That said, we as an industry I firmly believe have come a long way in the past few years. Are we there yet? No. Are we closer than we were a year ago? Yes!
Ever since reducing the current 398 day limit has been expressed as a desire, we’ve seen an increase in automation. We firmly believe that now is the time to not lose momentum.
There are Subscribers that have used automation for many years. There are also Subscribers that have picked up the pace based on Chrome’s “Moving Forward, Together” initiative. Then there’s the segment of Subscribers that won’t pick up at all until hard deadlines are set. Again, I’ll reiterate, we firmly believe the time has come to set those deadlines.
Setting hard deadlines now will allow those Subscribers that are falling behind due to unwillingness or inability from a resource perspective to request a change internally based on the changes in this ballot.
So, assuming that we don't have any imminent security threat at hand, this ballot is the first attempt to set those hard deadlines. We must proceed with caution when setting these deadlines as if the world hears it for the first time, because this is true for billions of Domain Owners that are not engaged in this industry nor reading Chrome's announcements. Moving the 47-days validity adoption window from 3 to 4 years, based on Apple's recent update, is a good sign. I remain positive that the Browsers will be open to updating this timeframe even further if supporting evidence is presented by the community.
Thanks,
Dimitris.
Dimitris Zacharopoulos (HARICA)
Hi Dimitris,
Hi Chris,
In short and regarding the proposed survey, we still believe there are too many inherent challenges that prevent it from being actionable. Specific to your example questions:
How would one conclude and confirm the survey asks the “right” questions? (This is subjective.)
What’s a “challenge”? Who objectively determines its criticality and if that challenge is real or just perceived? (This is subjective.)
For instance, when a significant number of Subscribers say that they have limited or zero budget to enable automation, the community will hear the concerns and present responses like:
- 47-day certificates will be introduced in 2029, giving enough time for Subscribers to prepare and get the appropriate budgets
- Here is a list of automation tools that are free and open-source that have been used successfully by millions of Domain Owners.
- ...
Is the SCWG prepared to objectively study, debate, and possibly seek clarifying details on potentially thousands or millions of responses? On what timeline? At what cost?
How would one ensure a truly random and representative sample to minimize or prevent sampling bias?
Again, why would we expect a website operator that’s already adopted automation to complete the proposed survey?
As we previously stated, if respondents cannot reliably differentiate PKI use cases, or are otherwise confused about the ballot’s impact, the proposed survey’s conclusions will be fundamentally flawed. Ultimately, if the survey data is unreliable, it will not be useful in guiding next steps, wasting time and resources for everyone involved. To that end, we see no value in the survey, or any further discussion related to it.
Perhaps you have different expectations from the proposed survey? I had no specific or pre-determined "expected conclusions" in mind. We know there will be a great deal of Subscribers who will push back and give excuses for the adoption of shorter-lived certificates. The idea is to get a better understanding of the "WebPKI" uses, in practice, flesh out information like the percentages of Subscribers that use Publicly-Trusted TLS Certificates for "non-Browser" use cases, or for websites that are not accessible on the Internet. Is that a negligible, small or large percentage? Similarly we should hear about specific automation adoption challenges and see if they are focused on specific industry sectors (banking, education, health, aviation, governments), and prepare appropriate responses.
CAs will follow whatever adoption rate the Browsers decide on, but such decisions, without proper data to evaluate, may have an unpredictable negative impact to the WebPKI ecosystem.
We still believe the most reliable method of determining real impact is by setting future dates for the implementation of security-enhancing short-lived certificates. We provided commentary on this line of thinking in our previous response.
Agreed. Perhaps I framed it poorly but I never meant to dismiss the Chrome Root Program's goal to reduce the validity of certificates. I just noted that website operators didn't have a clear path (even a tentative one) from Chrome or other browsers about an expected timeline to reduce certificate validity, giving them something concrete to take up to their management boards, allocate resources/budgets, and so on.
We wanted to focus on this statement, since it references the Chrome Root Program and the opportunity this ballot provides. While we could argue that Chrome offered a clear intent to explore the goals described in this ballot and a “tentative” path to members of the Forum via multiple F2F presentations (e.g., 1, 2, 3), and that motivated action from some CAs and some subscribers, we believe the point you were trying to make is more related to the value of having a clear timeline, which is exactly what this ballot intends to provide.
We understand that there is concern related to the validity reduction from 100 days to 47. It is our general view that if automation is sufficiently in place, the subscriber impact of any validity and DCV reuse reduction is trivial. Real-world examples demonstrating the value of automation, many of which are described in the ballot’s preamble, are readily available. These examples span a wide range of organizations from across the globe, including small and large, and those in highly regulated industries (including government and financial services). The phased timeline encourages adoption of automation, while doing so in a way that allows both challenges and their solutions to come to light.
Thank you,
Dimitris.
Aaron Gable
In our opinion it would be too onerous for the 99.95% of Domain Owners to have to re-validate their Base Domain Names every 10 days.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/c4069e8f-d923-4bc7-881e-146410e8fbaf%40harica.gr.
Ryan Dickson
> So, assuming that we don't have any imminent security threat at hand, this ballot is the first attempt to set those hard deadlines.
Threats related to “long-lived” (i.e., 398-day) certificates have been presented and discussed on this thread by two security researchers participating in the SCWG as Interested Parties. Both independently concluded reduced validity corresponds to reduced risk for website operators and relying parties, and they considered different perspectives as the basis of those conclusions. One went so far as to mention knowledge of a recent attack that is not yet publicly disclosed.
Some members of the community might conclude that because a reduction of validity, alone, is imperfect at addressing all of the threats described by the researchers, the action proposed in SC-81 is unjustified. Holding this view ignores the fact that the maximum temporal scope of potential future abuse is reduced when compared to the current state, and the many other benefits described in the ballot preamble.
Some members of the community have questioned the cost of such a transition. While it seems unlikely for us to accurately estimate this element of the proposed transition, there are many publicly documented success stories that frame an investment in automation (which should be considered essential for 47-day certificates) not as a cost, but as an opportunity for significant savings (e.g., as subscribers no longer incur (1) direct costs related to the manual management of existing TLS certificates, (2) the indirect costs related to outages whether it be a penalty or loss of staff productivity, or the (3) opportunity costs of not being able to focus on more strategic, value-adding activities due to (1) and (2)).
> because this is true for billions of Domain Owners that are not engaged in this industry nor reading Chrome's announcements
It’s true, most Domain Owners probably aren’t reading “Moving Forward, Together” (MFT). It’s also our general opinion that Domain Owners shouldn’t need to be experts in TLS or closely follow MFT or the Forum’s ongoings because securing content to/from their websites should ideally be effortless, reliable, and without excitement. We feel the increased use of automation, which is a beneficial byproduct of this ballot, brings those characteristics closer to reality.
Regardless of the average Domain Owner’s familiarity with MFT, they should be familiar with their CA Owner. Over the last two years, many CA Owners have amplified our MFT messaging with their own customers, just as they have with this ballot (e.g., 1, 2, 3, 4, 5, etc.). (As an aside, if considered alongside existing fully automated CAs, the cited group alone covers over 90% of all time-valid certificates issued by the Web PKI. The important part being that subscribers may be more familiar with and better prepared for the proposed validity reduction than we think, even if they aren’t familiar with MFT.)
In response to past industry discussions regarding reduced certificate validity, Chrome has directly engaged in numerous conversations with Domain Owners, including those in regulated industries. These interactions consistently revealed a shared misunderstanding with regard to the applicability of the Web PKI to internal and non-public use cases (e.g., the datacenter UPS, which is not accessed from the Internet, *should not* be relying on the Web PKI). Notably, these dialogues often resulted in a mutual understanding of automation's benefits, and a shift in discussion focus from certificate validity to instead the importance of private PKIs and the need for broader third-party software support for automated certificate management.
From our view, the timelines proposed in this ballot are fair and reasonable for accomplishing this goal. As already expressed in the thread, if it is justified in doing so, the SCWG could move to address said substantiated impact by updating the requirements proposed in this ballot (e.g., prolonging the duration where the maximum validity period is 100 days). While it’s natural to question delaying the timeline even more than addressed in Version 2 of this ballot, extending the timeline risks a classic case of Parkinson’s Law (where work expands so as to fill the time available for its completion). Simply put, extending the timeline at this point doesn’t guarantee better results, but it does guarantee the ecosystem benefits of reduced validity are delayed.
It’s been 137 days since Ballot SC-81 was introduced at F2F 63. Even if a SCWG vote concluded today, and if members were in favor of the current language, the critical timeline necessary to motivate those needing to take action would not be found in the TLS BRs until 45 days from now (landing approximately half a year since the ballot's introduction). Obviously, we’re still in the discussion phase, and now also seemingly planning for further conversation at F2F 64 at the end of March. It’s not clear at what point discussion will be considered sufficient to achieve consensus, but we continue to support SC-81 Version 2, as written.
-Ryan
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/a37dcf8f-181b-4e49-9c11-6490e7ff0adb%40harica.gr.
Dimitris Zacharopoulos (HARICA)
On Mon, Feb 24, 2025 at 3:57 AM 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
In our opinion it would be too onerous for the 99.95% of Domain Owners to have to re-validate their Base Domain Names every 10 days.
Most Domain Owners will not have to re-validate their domain control every 10 days. In the immediate future, as certificate lifetimes remain long, they'll have to revalidate it every year when they renew. Over the next five years, that period will be reduced to every 35ish days, as the certificate lifetime changes reach their endpoint.
Those that will have to re-validate frequently are those that issue many different certificates frequently -- e.g. if they have many ephemeral frontend servers all serving the same domain, and each server gets its own certificate. These subscribers have already implemented automation, and revalidating every 10 days is not a burden for them.
In my opinion it is critical that the validation data reuse period never be greater than the certificate validity period. Simply removing the last step -- leaving validation data reuse at 100 days while certificate lifetimes are reduced to 47 days -- creates a wildly counterintuitive scenario where subscribers do not understand the actual longevity of a threat. If a certificate is only valid for 47 days, how would you possibly expect anyone to understand that a malicious actor actually has the ability to have valid certificates for their domain for the next five months?
I would be willing to support validation reuse periods that are longer than certificate validity periods if and only if they are accompanied by a BRs requirement that validation data be made ineligible for reuse if any certificate issued using that validation data is revoked.
Dimitris.
Roman Fischer
Dear Group,
There was a number of very insightful talks at the past PKI Consortium PQC Conference (https://pkic.org/events/2025/pqc-conference-austin-us/) that highlighted that migration to Quantum Safe certificates will probably also have be tackled in the next 1-5 years.
This means that many participants in the WebPKI ecosystem will have to address two significant changes in parallel. That is of course not a problem, just wanted to mention it.
Kind regards
Roman
From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Samstag, 15. Februar 2025 01:14
To: server...@groups.cabforum.org
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/2ED85C0E-E508-4992-A162-AF0A11E66275%40apple.com.
Ryan Dickson
Hi Roman,
We agree with you, this should not be considered a problem, as we do not feel deferring action on the basis that the timelines described in SC-081 V2 might intersect with the PQC transition would be in the best security interest of the ecosystem.
Considering the potential intersection of timelines as a problem would rest on two highly speculative assumptions:
the precise timeline of the PQC transition (which, as the public draft of NIST IR 8547 suggests, may extend beyond the cited 1-5 years given permitted use of some classical algorithms until 2035), and
the readiness of individual organizations.
We'd argue that the adoption of automation (again, which should be a natural byproduct of this ballot) eases the transition given the effort required to replace *every* classical PKI certificate an organization is responsible for. To be clear, this does not ignore the fact that systems and applications will still need to be updated to make use of PQC, but at the very least, one ongoing, error prone, and resource intensive aspect of the transition (i.e., the manual management of certificates) can be expedited or removed entirely.
From our view, the PQC transition strengthens the case for accelerating this ballot's goals, not delaying them.
-Ryan