Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

[Clint Wilson]

Ballot SC-081v3

Overview

• Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)
  • Eventual reduction of non-SAN validation data reuse from 825 to 398 days
  • Eventual reduction of SAN validation data reuse from 398 days to 10 days
• Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years
  • Eventual reduction of maximum validity period from 398 days to 47 days
• These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1. 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 [6].
2. The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.
3. 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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.
4. 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 [9].
5. 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.
6. 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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1. Scalability:
   • Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.
2. Reliability:
   • The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.
   • Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.
   • Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.
3. User Impact:
   • Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

As with the problems described under Benefits, the problems associated with the use of certificate status services may be addressed with a variety of solutions, each requiring action by multiple parties — not all of which are represented within the CA/Browser Forum nor are those solutions fully within the scope of the Forum’s ability to guarantee adoption. Regardless, however, those problems are adjacent to, rather than encompassed by, the proactive measures sought within this Ballot.

Conclusion

Since its first version, the TLS Baseline Requirements have set timelines to reduce the validity period and restrict the data reuse period for the certificates issued under them. The value of doing so then remains largely the same as the value in doing so now. The value of doing so in Ballot 185 remains largely the same as doing so now. The value of doing so in Ballot SC-022 remains largely the same as doing so now. This Ballot takes a somewhat different approach than any prior reduction, but does so with the aim of providing early and clear communication around both near and far-term changes needed by Web PKI participants while retaining the space to assess and incorporate new information as it becomes available.

[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[3] - 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).
[4] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[5] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[6] - 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.
[7] - https://insecure.design/
[8] - https://zanema.com/papers/imc23_stale_certs.pdf
[9] - 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:

• https://github.com/cabforum/servercert/compare/b7fd69b36171d81930e7758482984ce957a1ce7a...91724f5f705443a73306f875149177aec304e376

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, April 01, 2025 17:00 UTC (2025-04-01T17:00:00Z)
  

Vote for approval (7 days)

• Start time: Friday, April 04, 2025 19:30 UTC (2025-04-04T19:30:00.000Z)
• End time: Friday, April 11, 2025 19:30 UTC (2025-04-11T19:30:00.000Z)

[Chris Clements]

Google votes Yes on Ballot SC-081v3.

--
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/5A9757CF-581F-4671-B71E-15F31708E62A%40apple.com.

[Nick France]

Sectigo votes Yes on Ballot SC-081v3.

[Clint Wilson]

Apple votes Yes on Ballot SC-081v3.

[Corey Bonnell]

DigiCert votes YES on ballot SC-81v3.

 

Thanks,

Corey

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, April 4, 2025 3:30 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·        Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o   Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o   Eventual reduction of SAN validation data reuse from 398 days to 10 days

·        Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o   Eventual reduction of maximum validity period from 398 days to 47 days

·        These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.      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 [6].

2.      The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.      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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.      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 [9].

5.      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.

6.      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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.      Scalability:

o   Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.      Reliability:

o   The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o   Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o   Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.      User Impact:

o   Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[Ben Wilson]

Mozilla votes "Yes" on Ballot SC-081v3.

--

[Dimitris Zacharopoulos (HARICA)]

HARICA votes "yes" to ballot SC-081v3.

We feel optimistic that the timeline will be sufficient for all ecosystem stakeholders to adapt, and that the CABF Members will be open to adjustments to the timeline, based on concrete evidence presented to the WG.


Thank you,

Dimitris.

[Rebecca Kelley]

SSL.com votes Yes on Ballot SC-081v3.

 

 

From: "'Clint Wilson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org>
Reply-To: <server...@groups.cabforum.org>
Date: Friday, April 4, 2025 at 2:30 PM
To: <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[Rollin.Yu]

TrustAsia votes YES on Ballot SC-081v3.

Best regards,
Rollin Yu

[Hogeun Yoo]

NAVER Cloud Trust Services votes "Yes" on Ballot SC-081v3.

Hogeun Yoo

NAVER Cloud Trust Services

-----Original Message-----
From: "'Clint Wilson' via Server Certificate WG (CA/B Forum)"<server...@groups.cabforum.org>
To: <server...@groups.cabforum.org>;
Cc:
Sent: 2025. 4. 5. (토) 04:30 (GMT+09:00)
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: 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/5A9757CF-581F-4671-B71E-15F31708E62A%40apple.com.

[Backman, Antti]

Telia votes ’Yes’ on Ballot SC-081v3.

 

//Antti

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 4. April 2025 at 22.30
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[CHASSERY Francois]

Certinomis votes YES on ballot SC-081v3

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MM0P280MB0007087FBE27021BCEA3FA9A86B52%40MM0P280MB0007.SWEP280.PROD.OUTLOOK.COM.

[Kateryna Aleksieieva]

Certum votes YES on ballot SC-081v3

 

Kind regards,

Kateryna Aleksieieva

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, April 4, 2025 9:30 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[sde...@godaddy.com]

GoDaddy votes YES on Ballot SC-081v3.

 

Cheers,

Steven Deitte

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, April 4, 2025 at 3:31 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[Pedro FUENTES]

OISTE Votes YES to SC-081v3

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MRZP264MB15902F4490E61758F912CF85F8B52%40MRZP264MB1590.FRAP264.PROD.OUTLOOK.COM.

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

[Dimitris Zacharopoulos (HARICA)]

Dear Rebecca,

You are not listed as a voting representative of SSL.com and therefore this vote cannot be counted. Can you please ask someone already registered as a voting representative to vote for this ballot?

Please also ask an existing voting representative to make any necessary updates using the information in https://wiki.cabforum.org/books/forum/page/cabrowser-forum-members.


Thank you,
Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/D067B431-3A0D-4CD3-B57C-FEA8134EF4AE%40ssl.com.

[Tom Zermeno]

SSL.com votes “Yes” on SC-081 v3.

 

Thanks!

 

-TZ

 

From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Tuesday, April 8, 2025 9:01 AM
To: server...@groups.cabforum.org
Subject: Re: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Dear Rebecca,

You are not listed as a voting representative of SSL.com and therefore this vote cannot be counted. Can you please ask someone already registered as a voting representative to vote for this ballot?

Please also ask an existing voting representative to make any necessary updates using the information in https://wiki.cabforum.org/books/forum/page/cabrowser-forum-members.


Thank you,
Dimitris.

On 7/4/2025 7:43 μ.μ., 'Rebecca Kelley' via Server Certificate WG (CA/B Forum) wrote:

SSL.com votes Yes on Ballot SC-081v3.

 

 

From: "'Clint Wilson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org>
Reply-To: <server...@groups.cabforum.org>
Date: Friday, April 4, 2025 at 2:30 PM
To: <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

1.      Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

1.      Eventual reduction of non-SAN validation data reuse from 825 to 398 days

2.      Eventual reduction of SAN validation data reuse from 398 days to 10 days

2.      Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

1.      Eventual reduction of maximum validity period from 398 days to 47 days

3.      These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.      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 [6].

2.      The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.      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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.      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 [9].

5.      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.

6.      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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.      Scalability:

1.      Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.      Reliability:

1.      The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

2.      Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

3.      Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.      User Impact:

1.      Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/5efbacbe-e7f5-4a9f-99eb-e68b4826d03d%40harica.gr.

[Scott Rea]

eMudhra votes YES to SC-081v3

 

Regards,

_Scott

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 4 April 2025 at 3:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.

[Josselin ALLEMANDOU]

Certigna votes YES on Ballot SC-081v3.

[Ponds-White, Trev]

Amazon Trust Services votes yes

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, April 4, 2025 12:30
To: server...@groups.cabforum.org
Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.     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 [6].

2.     The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.     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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.     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 [9].

5.     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.

6.     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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.     Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.     Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.     User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[qi_ji...@itrus.com.cn]

iTrusChina votes YES on Ballot SC-081v3.

---

qi_ji...@itrus.com.cn

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum)

--

[Wayne Thayer]

Fastly votes Yes on ballot SC-081v3.

- Wayne

--

[Doug Beattie]

GlobalSign votes yes on Ballot SC-081.

Doug

---

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum)
Sent: Friday, April 4, 2025 3:30 PM
To: server...@groups.cabforum.org

Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

[大野 文彰]

SECOM Trust Systems ABSTAINS from voting on Ballot SC-081v3.

 

We agree with the value of shortening certificate validity periods, and we support this direction in the long term.

In addition, we believe this ballot signals to subscribers that automation is inevitable, and that this is a great step forward for the WebPKI ecosystem.

On the other hand, we are also aware that some subscribers may experience costs to adapt.

In our business practice, we think it is important to be able to explain not only the value but also the cost and explain that our approach is net-positive for the web, unless there is a reasonable alternative.

Assuming a tradeoff between the period to prepare and the cost, we do not have an answer to shortening it to 47 days instead of 90 days.

Therefore, we abstain.

 

Best regards,

 

ONO Fumiaki / 大野 文彰

SECOM Trust Systems Co., Ltd.

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Saturday, April 5, 2025 4:30 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.    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 [6].

2.    The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.    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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.    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 [9].

5.    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.

6.    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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.    Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.    Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.    User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[Alvin Wang]

SHECA voted in favor of SC-081v3.

Best regards,
Alvin Wang

[蔡家宏(chtsai)]

TWCA "ABSTAINS" from voting on ballot SC-081v3.

 

 

1. We agree that shortening the certificate validity period can reduce cybersecurity risks, and we also acknowledge the advantages of automated certificate management.

 

2. We believe that reducing the validity period from 100 days to 47 days is too drastic. Compared to the harm caused by phishing websites, there is currently no way to demonstrate to users how high the cybersecurity risk would be if the certificate validity period were 100 days.

 

3. For some websites that already use certificates, if they ultimately fail to deploy automated certificate management, they might abandon HTTPS in favor of HTTP (given that in today’s browser UIs, HTTP only displays a red warning in the upper left corner, whereas improper management leading to certificate expiration results in warnings across the entire page).

 

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: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Saturday, April 5, 2025 3:30 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·         Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o    Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o    Eventual reduction of SAN validation data reuse from 398 days to 10 days

·         Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o    Eventual reduction of maximum validity period from 398 days to 47 days

·         These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.      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 [6].

2.      The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.      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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.      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 [9].

5.      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.

6.      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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.      Scalability:

o    Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.      Reliability:

o    The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o    Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o    Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.      User Impact:

o    Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

--

[Michael Guenther]

[Entschew, Enrico]

D-Trust votes „Yes“ on Ballot SC-081v3.

 

Thanks,

Enrico

 

Von: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Samstag, 5. April 2025 22:14
An: server...@groups.cabforum.org
Betreff: Re: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Apple votes Yes on Ballot SC-081v3.

On Apr 4, 2025, at 12:30 PM, 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

 

Ballot SC-081v3

Overview

·       Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o   Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o   Eventual reduction of SAN validation data reuse from 398 days to 10 days

·       Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o   Eventual reduction of maximum validity period from 398 days to 47 days

·       These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.    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 [6].

2.    The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.    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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.    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 [9].

5.    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.

6.    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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.    Scalability:

o   Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.    Reliability:

o   The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o   Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o   Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.    User Impact:

o   Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/25440E1A-031A-4060-8EBA-387EB7A673B6%40apple.com.

[Karina Sirota Goodley]

Microsoft votes Yes on ballot SC-081v3.

 

Best,

Karina

 

Karina Sirota Goodley, MBA, MS

Security Program Manager 2

Trusted Root Program, AEP Trust and Governance

 

My working hours may not look like yours and after-hours responses neither required nor expected.

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, April 4, 2025 2:30 PM
To: server...@groups.cabforum.org

[Jeun, Inkyung (Lynn)]

Visa votes YES on ballot SC-81v3.

 

Thanks,

Lynn.

[Janet Hines]

VikingCloud votes YES on Ballot SC-081v3

Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited is registered in Ireland under company registration number 147176 and its registered office is at 1st Floor, Block 71a, The Plaza, Park West Business Park, Dublin 12, Ireland.

Email Disclaimer
The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Sysxnet Limited is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt..

[Mads Egil Henriksveen]

Buypass votes YES on Ballot SC-081v3.

Regards

Mads

[Peter Miškovič]

Disig votes „YES“ on Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.

 

Regards

Peter Miskovic

[Fernandez Ruperez, David Alvaro]

IZENPE votes YES on Ballot SC-081v3.

Regards,

[Matsuo Yoshihiko]

JPRS abstains from voting on Ballot SC-081.

We agree with the value of reducing certificate validity periods.
We also believe that this ballot indicates to subscribers the inevitability of automation and represents a significant step forward for the WebPKI ecosystem.

However, we will abstain from this ballot.
While we will do our best to support our subscribers and hope that subscribers and other stakeholders in the WebPKI ecosystem will be able to follow the proposed timeline, it is currently uncertain whether it can realistically be achieved.

In addition, we hope that discussions will take place even after this ballot when necessary, taking into account the actual state of migration in the WebPKI ecosystem.

Best regards,

Yoshihiko Matsuo
Japan Registry Services（JPRS）

On Fri, 04 Apr 2025 12:30:09 -0700
"'Clint Wilson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:

> Ballot SC-081v3
>
> Overview
>
> Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

> Eventual reduction of non-SAN validation data reuse from 825 to 398 days

> Eventual reduction of SAN validation data reuse from 398 days to 10 days
> Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

> Eventual reduction of maximum validity period from 398 days to 47 days
> These reductions are proposed to occur starting in March 2026 and concluding in March 2029
>
> Background
>

> The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion ? in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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
>
> Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].
>
>
> 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 [4] [5]. 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 [6].

> The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

> 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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

> 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 [9].

> 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.

> These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.
>
>
> Adjacent Solutions
>
> There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.
>
>
> Revocation
>
> Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.
>

> Scalability:

> Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

> Reliability:

> The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

> Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

> Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

> User Impact:

> Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

> As with the problems described under Benefits, the problems associated with the use of certificate status services may be addressed with a variety of solutions, each requiring action by multiple parties ? not all of which are represented within the CA/Browser Forum nor are those solutions fully within the scope of the Forum’s ability to guarantee adoption. Regardless, however, those problems are adjacent to, rather than encompassed by, the proactive measures sought within this Ballot.

>
>
> Conclusion
>
> Since its first version, the TLS Baseline Requirements have set timelines to reduce the validity period and restrict the data reuse period for the certificates issued under them. The value of doing so then remains largely the same as the value in doing so now. The value of doing so in Ballot 185 remains largely the same as doing so now. The value of doing so in Ballot SC-022 remains largely the same as doing so now. This Ballot takes a somewhat different approach than any prior reduction, but does so with the aim of providing early and clear communication around both near and far-term changes needed by Web PKI participants while retaining the space to assess and incorporate new information as it becomes available.
>
> [1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
> [2] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
> [3] - 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).
> [4] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
> [5] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
> [6] - 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.
> [7] - https://insecure.design/
> [8] - https://zanema.com/papers/imc23_stale_certs.pdf
> [9] - 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 <https://github.com/cabforum/servercert/pull/553/files>.

[Bruce Morton]

Entrust abstains from voting on Ballot SC-081.

 

 

Bruce.

 

From: 'Clint Wilson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, April 4, 2025 3:30 PM
To: server...@groups.cabforum.org

Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

 

Ballot SC-081v3

Overview

·        Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

o   Eventual reduction of non-SAN validation data reuse from 825 to 398 days

o   Eventual reduction of SAN validation data reuse from 398 days to 10 days

·        Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

o   Eventual reduction of maximum validity period from 398 days to 47 days

·        These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1.      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 [6].

2.      The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

3.      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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

4.      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 [9].

5.      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.

6.      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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1.      Scalability:

o   Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2.      Reliability:

o   The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

o   Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

o   Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

3.      User Impact:

o   Certificate status services impose a cost on relying parties and website users. When connecting to a webpage loading content from multiple domains, each connection queries for the status of its associated TLS certificate. Sometimes those queries can hit local caches, but often require waiting for several (and, in some cases, dozens) of queries to either return a response, or to timeout. The rate of timeouts and/or retries increases under a variety of conditions, resulting in either significantly increased page load times or in abandoning the attempts to query certificate status services.

As with the problems described under Benefits, the problems associated with the use of certificate status services may be addressed with a variety of solutions, each requiring action by multiple parties — not all of which are represented within the CA/Browser Forum nor are those solutions fully within the scope of the Forum’s ability to guarantee adoption. Regardless, however, those problems are adjacent to, rather than encompassed by, the proactive measures sought within this Ballot.

Conclusion

Since its first version, the TLS Baseline Requirements have set timelines to reduce the validity period and restrict the data reuse period for the certificates issued under them. The value of doing so then remains largely the same as the value in doing so now. The value of doing so in Ballot 185 remains largely the same as doing so now. The value of doing so in Ballot SC-022 remains largely the same as doing so now. This Ballot takes a somewhat different approach than any prior reduction, but does so with the aim of providing early and clear communication around both near and far-term changes needed by Web PKI participants while retaining the space to assess and incorporate new information as it becomes available.

[1] - https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview
[2] - https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20211028135554557-0735:9781009039604:51076fig13_1b.png?pub-status=live
[3] - 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).
[4] - https://cabforum.org/2017/02/24/ballot-185-limiting-the-lifetime-of-certificates/
[5] - https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/#ballot-sc22-reduce-certificate-lifetimes-v2
[6] - 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.
[7] - https://insecure.design/
[8] - https://zanema.com/papers/imc23_stale_certs.pdf
[9] - 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:

• https://github.com/cabforum/servercert/compare/b7fd69b36171d81930e7758482984ce957a1ce7a...91724f5f705443a73306f875149177aec304e376

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, April 01, 2025 17:00 UTC (2025-04-01T17:00:00Z)

Vote for approval (7 days)

• Start time: Friday, April 04, 2025 19:30 UTC (2025-04-04T19:30:00.000Z)
• End time: Friday, April 11, 2025 19:30 UTC (2025-04-11T19:30:00.000Z)

--
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/5A9757CF-581F-4671-B71E-15F31708E62A%40apple.com.

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

[Marco Schambach]

IdenTrust abstains from voting on Ballots SC-081v3.

While we agree with all proposals related to TLS DV validation and support full automation, we remain unconvinced of the security benefits of further reducing the validity period for OV and EV TLS certificates.   

 

Marco S.

TrustID Program Manager

[성지은 Jieun Seong]

MOIS abstains from voting on Ballots SC-081v3.

Among the three core elements of information security, while the enhancement of security—particularly the improvement of confidentiality—is acknowledged,

it is anticipated that this may lead to a decrease in availability and integrity due to increased workload and reduced continuity of service.

---

Date: 2025/04/05 04:30:35

From: "'Clint Wilson' via Server Certificate WG (CA/B Forum)"

To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins: SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

Ballot SC-081v3

Overview

• Expand Section 4.2.1 to detail the allowed data reuse periods for validation data (both for domains/IPs and for everything else in Section 3.2)

• • Eventual reduction of non-SAN validation data reuse from 825 to 398 days

• • Eventual reduction of SAN validation data reuse from 398 days to 10 days

• Expand Section 6.3.2 to detail a schedule for reducing Public TLS certificate maximum validity periods in coming years

• • Eventual reduction of maximum validity period from 398 days to 47 days

• These reductions are proposed to occur starting in March 2026 and concluding in March 2029

Background

The Web PKI is a complex, integral, and actively maintained 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 topic of certificate validity and data reuse periods has been a near constant point of discussion — in large part because of the cascading impact changes to these aspects of the TBRs have 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 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, 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

Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns [2], 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 [3].

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 [4] [5]. In particular, the following are perceived benefits to the Web PKI:

1. 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 [6].

1. The existence of certificates with formerly-correct contents poses real risk to websites, domain owners, and relying parties. Both past [7] 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” [8]. A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate and decreases the period of time in which such inaccurate information would remain in a valid certificate, independent of any additional action by any involved stakeholder.

1. 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 reduces the risk of improper validation, the scope of improper validation perpetuation, and the opportunities for misissued certificates to negatively impact the ecosystem and its relying parties.

1. 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 [9].

1. 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.

1. 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.

These are all existing problems in the Web PKI space for which this Ballot provides a mitigating solution. While the problems will remain, their size, scope of impact, and rate of prevention are all improved through this Ballot.

Adjacent Solutions

There are often multiple possibilities when exploring the solutions which might address a given problem. Taken individually, each of the above problems may be mitigated by some other mechanism. Collectively, however, no single solution is able to address the corpus of issues in a like manner or with a similar level of efficacy.

Revocation

Certificate status services, or revocation of certificates, provides a complementary reactive risk mitigation, while this Ballot focuses on improving proactive mitigation of these identified risks. As noted above, relying solely on revocation is untenable for a number of reasons.

1. Scalability:

1. • Certificate revocation services need to handle a large volume of requests, especially as the number of certificates in use continues to grow. This growth can and does overwhelm existing infrastructure, leading to delays and failures in checking the validity of certificates. By reducing the validity period, the percentage of certificates revoked during their lifetime decreases and the gap between when a certificate is revoked and when it expires decreases.

2. Reliability:

1. • The reliability of certificate status services is often inconsistent, as a global population accessing websites hosted semi-locally are required to make additional connections to third-party systems unassociated with the website itself. Generally, this problem has increased with the adoption of distributed certificate status services, but does still remain an issue with many website connections.

1. • Certificate status services are unreliable also due to the need for action to be taken by multiple parties in order for those statuses to be effective. Not every potentially problematic certificate is revoked, let alone revoked in a timely manner. Even when populations of certificates which must be revoked within a very specific timeframe are clearly identified, revocation does not consistently occur as expected.

1. • Both real-time access to certificate status services and the correctness/completeness of the information provided by those certificate status services are unreliable to some degree. Certificate validity periods, and their enforcement by relying parties, are incredibly reliable.

2. User Impact:

[Dimitris Zacharopoulos]

This vote came after the end of the voting period so it wasn't included in the results.

Thank you,

DZ.

Apr 12, 2025 02:57:05 성지은 Jieun Seong <sji...@klid.or.kr>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/20250411235644.24089.29288%40mail.klid.or.kr.