Ballot SC-081 Input Requested
Clint Wilson
On Nov 13, 2024, at 5:20 PM, 'Clint Wilson' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org> wrote:Hello all,I’ve updated the PR (https://github.com/cabforum/servercert/pull/553/files) associated with SC-081 and have identified a few areas where I’d like some additional feedback on the approach:Validity period stepsIn section Section 6.3.2, I’ve currently set the “steps” in reducing the maximum validity period at 200, 100, and 47. The change from 45 to 47 was to better allow for CAs (and software integrations) to issue certificates with a validity period of 45 days while not skirting the maximum validity period, which allows for the semi-common practice of renewing certificates at 2/3rds of the cert’s lifetime to occur at 30 days. 47 days also better matches my intent in mirroring the past (evolving) pattern of maximum validity periods:39 months = 3 years + 3 months825 days = 2 years + 94/95 days398 days = 1 leap year (366) + 1 31-day month + 1 day SHOULD vs MUST200 days = Maximal 6 month period (184 days) + 1/2 30 day month (15 days) + 1 day SHOULD vs MUST100 days = Maximal 3 month (92 days) + ~1/4 30 day month (7 days) + 1 day SHOULD vs MUST47 days = Maximal 1 month (31 days) + 1/2 30 day month (15 days + 1 day SHOULD vs MUSTQuestion: Do these validity periods make sense as the correct steps? For example, for the 100 day step, I rounded 7.5 down to 7 instead of up to 8 and wanted to understand if folks would prefer 101 there instead or if the “neater” numbers are preferableSHOULD datesIn Section both Section 4.2.1 and 6.3.2, I’ve only set dates for MUST requirements. Would folks like to also have a set of dates for SHOULD requirements, e.g. 6 months prior to the MUST dates, add the same thing but with a SHOULD?I’m personally inclined towards adding these, but I wasn’t sure if that was a commonly held view.Table headingsI intended the table headings to be descriptive, but not normative. I’m not sure I’ve hit the mark there and would like suggestions on how to label the tables so it’s clear that the contents are normative requirements, but the scope of applicability for that content is found in the preceding paragraph(s) rather than the table heading.Similarly, if the paragraphs themselves are not clear as to the tables’ scopes, that would be helpful to have feedback on.The table headings are currently:Table: Reference for maximum allowed Subject Validation Data Reuse PeriodTable: Reference for maximum allowed Domain Name and IP Address Validation Data Reuse PeriodTable: Reference for maximum Validity Periods of Subscriber CertificatesValidation Data Reuse PeriodI capitalized “Validation Data Reuse Period” initially because I thought it might be helpful to define this term, similar to “Validity Period”, but I find myself questioning the relevance and value of doing so. Would folks prefer this to be a defined term (or some portion of it, such as “Validation Data” only)?Thanks all,-Clint--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/A886C0FC-C5B8-44CD-8412-D62C066A2023%40apple.com.
Mike Shaver
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/09937D31-5AAB-4430-AE86-5A0876923384%40apple.com.
Mohamed Nabil
Hello Dear,
Sorry for what this group ?
IM IN Egypt why my email there?
Regards
MOHAMED NABIL
Dimitris Zacharopoulos (HARICA)
Apologies for the length of this message. I meant to engage sooner in this ballot's discussion but other priorities came and forced me to delay. I tried to keep up with all the discussion taking place on GitHub but I'm sure I missed some comments. In any case, here are my thoughts and suggestions for this ballot.
Academic work used as input to this ballot
I believe ballot SC-081 heavily relies on
https://cabforum.org/2024/10/08/minutes-of-the-f2f-63-meeting-in-seattle-wa-usa-october-8-10-2024/4-2024-10-08-Zane-CAB_Forum.pdf
which is a presentation based on a paper published
in 2023.As discussed in previous meetings, academic work is very much welcomed and should be taken into consideration when reviewing existing standards related to Internet Security. Having worked in the academic sector for the biggest part of my life, I've encountered papers and research work of various levels. My conclusion is that research work must always be carefully reviewed in order for the results to be verified, but, most importantly, the review must ensure that the problem description and hypotheticals -on which the entire research relies upon- are solid and valid.
IMHO, the threats of "stale certificates" described in this paper are flawed in the sense that they are "accepted risks by design". When Domain Owners decide to use a third-party operating a CDN or a web-hosting platform, they accept the risk of that third-party doing something wrong, just as the Domain Owner accepts the risk of a system administrator operating his/her own web server may misuse a private key associated with a public TLS server certificate. They choose to trust a third-party because they usually enter into a specific agreement, terms and conditions that mitigate those risks to acceptable levels. Domain Owners always have the right to cancel their subscription and the third-party has obligations to delete, destroy or NOT USE the private keys and certificates associated with the cancelled subscription.
Based on that threat, the paper expands on three critical scenarios where stale certificates allow a third-party to impersonate a domain they do not control. However, these third-parties are by design allowed to offer services for a domain they do not control, in the sense that "control" can be demonstrated by sending an email to the Domain Owner, or asking a Domain Owner add some entries to the DNS server that the third-party does not manage. All the numbers following that ("9 million instances of abusable third-party stale certificates"), are also somewhat unrelated to the issue because the vast majority of those were fully authorized, and had the "blessing" of the Domain Owners. This is like saying it is possible for system administrators working for the Domain Owner to be in a position to steal a private key and do nasty business. This threat would apply to almost all issued certificates.
As a result, reducing the validity period to reduce the number of such "stale certificates" provides negligible security benefit to the ecosystem because if we assume that these third-parties are acting maliciously, they will damage the domain owner as soon as they have this capability, which would only require a few extra days for the certificate to be valid under their control.
Is Certificate revocation effective in the WebPKI or not?
IMO the only effective way to remediate the sort of small risk of
"stale certificate" or any similar scenario that the Domain Owner
decides to spin-up a new Certificate and Private Key and use another
provider, is the Domain Owner revoking the previous certificates.For those claiming that revocation does not work, we continuously see Browsers improving the revocation checking mechanisms in an effective and efficient way at Internet scale, relying on CRLs. It may take hours for these revocations to propagate across the Internet for each browser vendor, but it certainly beats the unpredictable, uncalculated, unmanaged and uncontrolled economic impact that drastic certificate validity reduction will cause to Domain Owners.
Crypto and Policy Agility
On the topic of crypto agility, it is clear that the Forum has
mechanisms in place to deprecate and replace insecure algorithms
with secure ones. When quantum-safe algorithms become supported in
the TLS BRs, even with the existing certificate validity period of
398 days, the deprecation of RSA/ECDSA could be a ballot away. In
the catastrophic scenario that RSA/ECDSA become compromised, again,
the CABF can pass a ballot requiring CAs to revoke all certificates
(not sure if this would make a difference on a broken
algorithm.....) and re-issue with quantum-safe algorithms. This is
not just crypto agility but also policy agility for which
all Members have worked very hard to achieve.We have a very unique ecosystem that makes so many changes to its regulatory standards each year compared to others. An insecure crypto algorithm is not a negligible event and I'm sure all Members would treat such event with the proper attention and take the necessary drastic measures.
Going forward with more automation
Independently of the input paper and crypto/policy agility, this
ecosystem has technically demonstrated -with the amazing work of
Let's Encrypt- that IT IS possible to reduce certificate validity to
90 days for the vast majority of Domain Owners on the Internet. Even
if any additional certificate validity reduction causes pain and
problems to a non-negligible percentage of Subscribers, the
ecosystem should adjust and adapt, enabling more automation. I
strongly believe that CAs are the ambassadors to this cause and
should advocate Subscribers to enable more automation in the
certificate lifecycle management.Proposed ballot
Clint, please allow me some thoughts and suggestions on the proposed
dates:- On the identity validation reuse periods, I propose using the 398 days that CAs and Subscribers are used to, at least as applied in the EV Guidelines and other standards.
- On the Domain Name/IP Address validation reuse periods, I believe the ballot is fair and takes into consideration a significant amount of Domain Owners that have web servers behind firewalls and do not allow API access to their DNS Servers, giving time for adjustments and regulatory updates. However, I believe the reduction to 100 days should be the last step. Re-validating every Domain Name/FQDN on the Internet every 10 days sounds unrealistic and unreasonable, at least based on the current data and justifications.
- Finally, for the certificate validity periods and for similar reasons, the reduction to 100 days should be the last step.
Thank you for your time.
Best regards,
Dimitris.
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/09937D31-5AAB-4430-AE86-5A0876923384%40apple.com.
Roman Fischer
Dear Community,
Can somebody point me to some incidents that would have been avoided with shorter cert life-time?
I think that if an attacker can gain control over the victim's domain validation then it doesn't matter how frequent such a validation is done or how frequent a certificate is renewed / exchanged.
Is the shortening of domain validation and certificate life-times really solving a real and pressing problem?
Thanks
Roman
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/09937D31-5AAB-4430-AE86-5A0876923384%40apple.com.
Ryan Dickson
Hi Dimitris,
Thanks for sharing your perspective!
A few thoughts below:
> IMHO, the threats of "stale certificates" described in this paper are flawed in the sense that they are "accepted risks by design".
I think this unintentionally misrepresents some aspects of what’s being presented in Zane’s research.
Assume the following scenario:
Day 0: Bob registers example.com and configures a CDN to manage its TLS configuration. A 398-day certificate is issued to example.com, managed by the CDN, with the authority to do so delegated by Bob.
Day 1: Bob terminates his relationship with the registrar, releasing example.com.
Day 2: Alice registers example.com, and manages the corresponding TLS implementation independently of the CDN described on Day 0. Alice gets a new certificate.
Day 3 - 795: The CDN is technically capable of maintaining access to the private key that corresponds with the time-valid certificate for example.com issued on Day 0. On Day 397, the CDN could renew that certificate without demonstrating ownership or control over the domain because of the existing DCV reuse periods. The CA would never know the cached authorization could not be relied upon, if a request was made.
I’d argue that Alice (the new owner of “example.com”) (1) would have no expectation that the CDN provider could have a private key corresponding to a publicly-trusted certificate which further corresponds to their domain name and (2) that they never accepted this risk.
If we imagined the same scenario where (a) the validity of the certificate issued in Day 0 was reduced and/or (b) the domain validation reuse period was decreased - the risk aperture is naturally reduced.
Note: I understand this same risk exists with resellers and is not unique to CDNs. I do not interpret reseller related risk to be considered by Zane’s research, but the security of both can equally improve with validity/validation reuse reductions.
> When Domain Owners decide to use a third-party operating a CDN or a web-hosting platform, they accept the risk of that third-party doing something wrong, just as the Domain Owner accepts the risk of a system administrator operating his/her own web server may misuse a private key associated with a public TLS server certificate. They choose to trust a third-party because they usually enter into a specific agreement, terms and conditions that mitigate those risks to acceptable levels.
Again, in the example above, I do not consider that Alice accepted the risk of the CDN controlling a certificate representing their domain, as they have no relationship with the CDN.
Also, I’ve studied the Terms of Service (ToS) associated with a few CDN/managed TLS implementations that I’ve experimented with in the past (some of which are referenced in Zane’s research), and in my experience, these terms often describe very little in what I’d interpret as reducing risk for Domain Owners. While it’s true ToS can protect customers, I see them as primarily a legal tool for service providers to protect their own interests. In many cases, the ToSs I’ve studied either (1) offer very little detail related to the subject being discussed, or (2) impose requirements on customers (e.g., the customer must notify the service provider if the customer ceases to operate or control a domain). It’s unclear whether customers have any obligation to fulfill those requirements upon terminating service agreements with those third-parties. However, given the number of “managed TLS departures” described in Zane’s research, I interpret these controls are not reliable.
If you are able to share examples of what you consider to be effective ToS that adequately present and remedy the risk you describe being accepted – and possibly propose how this community can ensure that all such agreements are equally effective, that’d improve my understanding of existing protections against some of the certificate invalidation events described in Zane’s research.
> Domain Owners always have the right to cancel their subscription and the third-party has obligations to delete, destroy or NOT USE the private keys and certificates associated with the cancelled subscription.
Can you please share where these obligations are universally defined? Who is responsible for ensuring the third-party acts as described?
Re-framing this as “the third-party should have obligations to delete, destroy or NOT USE the private keys and certificates associated with the cancelled subscription.” seems more accurate.
> However, these third-parties are by design allowed to offer services for a domain they do not control, in the sense that "control" can be demonstrated by sending an email to the Domain Owner, or asking a Domain Owner add some entries to the DNS server that the third-party does not manage.
It’s true the third-party was once allowed to offer services for a domain they do not control, but I interpret this statement to ignore the fact that the delegation may have ended (e.g., the customer terminates their relationship with the third-party provider) or was otherwise invalidated (e.g., the domain changes ownership).
> For those claiming that revocation does not work, we continuously see Browsers improving the revocation checking mechanisms in an effective and efficient way at Internet scale, relying on CRLs.
Reliable revocation goes beyond browsers. CAs play a role in this by adhering to the expected behaviors described by the TLS BRs. Subscribers also play an important role in revocation, but this expectation may not always be sufficiently understood by them - or one they choose to follow.
Whereas the reliability of systems and actors in the ecosystem that influence revocation are often observed as imperfect (examples), certificate expiration appears broadly and reliably enforced.
> It may take hours for these revocations to propagate across the Internet for each browser vendor, but it certainly beats the unpredictable, uncalculated, unmanaged and uncontrolled economic impact that drastic certificate validity reduction will cause to Domain Owners.
It’s also true that an investment in automation could offer an improved economic reality. Many CA Owners represented in this community, at various times, have described the benefits of automation to also consider cost to the website owner. This is not intended to disagree with or diminish the point that there is often an investment to adopt automation, but to highlight that outcomes aren’t strictly negative.
In our view, a reduction of validity and automation go hand-in hand. Encouraging automation has been a key narrative for the Chrome Root Program, and something we continue to lean into.
> On the topic of crypto agility, it is clear that the Forum has mechanisms in place to deprecate and replace insecure algorithms with secure ones. When quantum-safe algorithms become supported in the TLS BRs, even with the existing certificate validity period of 398 days, the deprecation of RSA/ECDSA could be a ballot away. In the catastrophic scenario that RSA/ECDSA become compromised, again, the CABF can pass a ballot requiring CAs to revoke all certificates (not sure if this would make a difference on a broken algorithm.....) and re-issue with quantum-safe algorithms. This is not just crypto agility but also policy agility for which all Members have worked very hard to achieve.
FWIW, I think renewing/replacing certificates with existing algorithms should be considered part of the definition of cryptographic agility (e.g., overcoming certificate profile mis-issuance), as should obtaining a new certificate from a different issuing CA (e.g., the steps needed to obtain a certificate if an issuing CA was compromised or catastrophically failed in a way that it could no longer issue certificates or status information).
> Independently of the input paper and crypto/policy agility, this ecosystem has technically demonstrated -with the amazing work of Let's Encrypt- that IT IS possible to reduce certificate validity to 90 days for the vast majority of Domain Owners on the Internet. Even if any additional certificate validity reduction causes pain and problems to a non-negligible percentage of Subscribers, the ecosystem should adjust and adapt, enabling more automation. I strongly believe that CAs are the ambassadors to this cause and should advocate Subscribers to enable more automation in the certificate lifecycle management.
This is a great goal.
Do you have concrete proposals for how the Forum can improve the rate at which automation is adopted? How can the Forum execute on this vision in 2025 and beyond?
Thanks,
Ryan
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/1757f6d1-2d50-48c2-bdf2-7bce3c4d5de6%40harica.gr.
Roman Fischer
Hi Ryan,
Not sure I understand your example:
- Day 0: Bob registers example.com and configures a CDN to manage its TLS configuration. A 398-day certificate is issued to example.com, managed by the CDN, with the authority to do so delegated by Bob.
- Day 1: Bob terminates his relationship with the registrar, releasing example.com.
Do I understand correctly: Bob is the malicious actor because he now no longer controls example.com but can have the CDN get certificates for it? How would he use that certificate since Alice would make the A/AAAA records of example.com point to her servers?
- Day 2: Alice registers example.com, and manages the corresponding TLS implementation independently of the CDN described on Day 0. Alice gets a new certificate.
- Day 3 - 795: The CDN is technically capable of maintaining access to the private key that corresponds with the time-valid certificate for example.com issued on Day 0. On Day 397, the CDN could renew that certificate without demonstrating ownership or control over the domain because of the existing DCV reuse periods. The CA would never know the cached authorization could not be relied upon, if a request was made.
Kind regards
Roman
Ryan Dickson
Hi Roman,
> Do I understand correctly: Bob is the malicious actor because he now no longer controls example.com but can have the CDN get certificates for it? How would he use that certificate since Alice would make the A/AAAA records of example.com point to her servers?
In my experience, when a CDN is delegated authority to control a TLS implementation, only they are in possession of the private key - and that key cannot be exported. It’s likely there are exceptions to this understanding.
This means that while Bob could be the bad actor, it’s most likely the potential abuse would come by way of someone within the CDN, or an adversary that was able to successfully exfiltrate keys from the CDN.
Example abuse vectors for the fraudulent certificate include by way of a BGP attack/hijack or a local network attack (e.g., an adversary can modify a hosts file to point example.com to an IP they own).
I hope this makes the example more clear!
Thanks,
Ryan
--
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.
Dimitris Zacharopoulos (HARICA)
Hi Dimitris,
Thanks for sharing your perspective!
A few thoughts below:
> IMHO, the threats of "stale certificates" described in this paper are flawed in the sense that they are "accepted risks by design".
I think this unintentionally misrepresents some aspects of what’s being presented in Zane’s research.
Assume the following scenario:
Day 0: Bob registers example.com and configures a CDN to manage its TLS configuration. A 398-day certificate is issued to example.com, managed by the CDN, with the authority to do so delegated by Bob.
Day 1: Bob terminates his relationship with the registrar, releasing example.com.
Day 2: Alice registers example.com, and manages the corresponding TLS implementation independently of the CDN described on Day 0. Alice gets a new certificate.
Day 3 - 795: The CDN is technically capable of maintaining access to the private key that corresponds with the time-valid certificate for example.com issued on Day 0. On Day 397, the CDN could renew that certificate without demonstrating ownership or control over the domain because of the existing DCV reuse periods. The CA would never know the cached authorization could not be relied upon, if a request was made.
I’d argue that Alice (the new owner of “example.com”) (1) would have no expectation that the CDN provider could have a private key corresponding to a publicly-trusted certificate which further corresponds to their domain name and (2) that they never accepted this risk.
Reducing the validity of the certificate would still keep her at risk from a truly "rogue" Bob that decides to do harm.
This is exactly the scenario we discussed between Browser representatives and ETSI experts in the 2-QWAC approach, leaving the revocation option the only truly viable method to prevent this from happening.
If we imagined the same scenario where (a) the validity of the certificate issued in Day 0 was reduced and/or (b) the domain validation reuse period was decreased - the risk aperture is naturally reduced.
Note: I understand this same risk exists with resellers and is not unique to CDNs. I do not interpret reseller related risk to be considered by Zane’s research, but the security of both can equally improve with validity/validation reuse reductions.
> When Domain Owners decide to use a third-party operating a CDN or a web-hosting platform, they accept the risk of that third-party doing something wrong, just as the Domain Owner accepts the risk of a system administrator operating his/her own web server may misuse a private key associated with a public TLS server certificate. They choose to trust a third-party because they usually enter into a specific agreement, terms and conditions that mitigate those risks to acceptable levels.
Again, in the example above, I do not consider that Alice accepted the risk of the CDN controlling a certificate representing their domain, as they have no relationship with the CDN.
Also, I’ve studied the Terms of Service (ToS) associated with a few CDN/managed TLS implementations that I’ve experimented with in the past (some of which are referenced in Zane’s research), and in my experience, these terms often describe very little in what I’d interpret as reducing risk for Domain Owners. While it’s true ToS can protect customers, I see them as primarily a legal tool for service providers to protect their own interests. In many cases, the ToSs I’ve studied either (1) offer very little detail related to the subject being discussed, or (2) impose requirements on customers (e.g., the customer must notify the service provider if the customer ceases to operate or control a domain). It’s unclear whether customers have any obligation to fulfill those requirements upon terminating service agreements with those third-parties. However, given the number of “managed TLS departures” described in Zane’s research, I interpret these controls are not reliable.
If you are able to share examples of what you consider to be effective ToS that adequately present and remedy the risk you describe being accepted – and possibly propose how this community can ensure that all such agreements are equally effective, that’d improve my understanding of existing protections against some of the certificate invalidation events described in Zane’s research.
> Domain Owners always have the right to cancel their subscription and the third-party has obligations to delete, destroy or NOT USE the private keys and certificates associated with the cancelled subscription.
Can you please share where these obligations are universally defined? Who is responsible for ensuring the third-party acts as described?
Re-framing this as “the third-party should have obligations to delete, destroy or NOT USE the private keys and certificates associated with the cancelled subscription.” seems more accurate.
> However, these third-parties are by design allowed to offer services for a domain they do not control, in the sense that "control" can be demonstrated by sending an email to the Domain Owner, or asking a Domain Owner add some entries to the DNS server that the third-party does not manage.
It’s true the third-party was once allowed to offer services for a domain they do not control, but I interpret this statement to ignore the fact that the delegation may have ended (e.g., the customer terminates their relationship with the third-party provider) or was otherwise invalidated (e.g., the domain changes ownership).
> For those claiming that revocation does not work, we continuously see Browsers improving the revocation checking mechanisms in an effective and efficient way at Internet scale, relying on CRLs.
Reliable revocation goes beyond browsers. CAs play a role in this by adhering to the expected behaviors described by the TLS BRs. Subscribers also play an important role in revocation, but this expectation may not always be sufficiently understood by them - or one they choose to follow.
Whereas the reliability of systems and actors in the ecosystem that influence revocation are often observed as imperfect (examples), certificate expiration appears broadly and reliably enforced.
> It may take hours for these revocations to propagate across the Internet for each browser vendor, but it certainly beats the unpredictable, uncalculated, unmanaged and uncontrolled economic impact that drastic certificate validity reduction will cause to Domain Owners.
It’s also true that an investment in automation could offer an improved economic reality. Many CA Owners represented in this community, at various times, have described the benefits of automation to also consider cost to the website owner. This is not intended to disagree with or diminish the point that there is often an investment to adopt automation, but to highlight that outcomes aren’t strictly negative.
In our view, a reduction of validity and automation go hand-in hand. Encouraging automation has been a key narrative for the Chrome Root Program, and something we continue to lean into.
From discussions I had with website managers/operators, and also business owners, they seem concerned about the cost increase in their operations but most importantly, they are highly concerned that they can't predict a "cap" in the cost increase. I know it's not really the CA/B Forum's concern but when there is a proposal to reduce the validity of certificates and re-use of validations, we need to acknowledge that this results in increased costs for key management and website operator labor. IMHO this cost increase should be somehow justified base on real, practical risks associated with the current values (398 days certificate validity and re-use period).
> On the topic of crypto agility, it is clear that the Forum has mechanisms in place to deprecate and replace insecure algorithms with secure ones. When quantum-safe algorithms become supported in the TLS BRs, even with the existing certificate validity period of 398 days, the deprecation of RSA/ECDSA could be a ballot away. In the catastrophic scenario that RSA/ECDSA become compromised, again, the CABF can pass a ballot requiring CAs to revoke all certificates (not sure if this would make a difference on a broken algorithm.....) and re-issue with quantum-safe algorithms. This is not just crypto agility but also policy agility for which all Members have worked very hard to achieve.
FWIW, I think renewing/replacing certificates with existing algorithms should be considered part of the definition of cryptographic agility (e.g., overcoming certificate profile mis-issuance), as should obtaining a new certificate from a different issuing CA (e.g., the steps needed to obtain a certificate if an issuing CA was compromised or catastrophically failed in a way that it could no longer issue certificates or status information).
> Independently of the input paper and crypto/policy agility, this ecosystem has technically demonstrated -with the amazing work of Let's Encrypt- that IT IS possible to reduce certificate validity to 90 days for the vast majority of Domain Owners on the Internet. Even if any additional certificate validity reduction causes pain and problems to a non-negligible percentage of Subscribers, the ecosystem should adjust and adapt, enabling more automation. I strongly believe that CAs are the ambassadors to this cause and should advocate Subscribers to enable more automation in the certificate lifecycle management.
This is a great goal.
Do you have concrete proposals for how the Forum can improve the rate at which automation is adopted? How can the Forum execute on this vision in 2025 and beyond?
These are all concerns that need to be captured and slowly addressed. I would also be very open to arrange a certificate automation summit at one of the future F2F meetings, adding an extra day in the F2F schedule or deciding to drop some of the topics we typically discuss in favor of such a topic.
More ideas are welcome :)
Dimitris.
Henry Birge-Lee
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/70fd377a-f88f-44db-9a2e-493e45cb7d8a%40harica.gr.
Roman Fischer
Dear Henry,
Thanks for giving more context to this topic.
>1. I have seen attacks where an adversary obtains a certificate during an initial attack and then retargets the same victim in a second attack with the misissued certificate from the first attack.
And I understand correctly that the second attack would have been prevented (or at least made significantly harder) if the certificate life-time would have been shorter?
>2. Attacker infrastructure is often highly ephemeral with transit links being burnt, accounts getting shut down from non-payment, servers getting raided etc... Keeping the infrastructure required to attack domain control validation up and running is difficult, and I often see adversaries tear down infrastructure and somewhat start from scratch for a new campaign. Thus, it is completely probable that an adversary would have the ability to bypass domain control validation and then later lose it.
I'm not sure how to connect this to the proposed reduction of cert life-time. Attackers typically are already way more agile than the average customer we service. For an attacker, automation, speed, stealth… are their core-business. For regular certificate owners, it's about stability, simplicity, cost and effort. For me it would seem that shortening certificate life-time will be less of a problem for attackers than for customers. 😉
> 3. After an attack, victims often take evasive maneuvers which can include switching hosting providers or DNS providers. This is often done while root cause analysis is still underway (post mortem investigations can take a while and infrastructure needs to be recovered right away). Sometimes these maneuvers do actually prevent retargeting by the adversary (e.g., moves to /24 prefix space for sub-prefix BGP hijacks, providers that use DNSSEC or RPKI etc...). Thus, I would argue that an adversary obtaining an initial malicious certificate actively decreases the likelihood of an adversary being able to obtain a second malicious certificate due hosting changes/security responses by the victim.
So, once an attack is detected, certificate life-time is becoming less of an issue or how am I to understand this statement?
>4. I think a very relevant topic related to cert lifespan is cert revocation. Many of the attacks I have studied never lead to revocation. There are a variety of reasons for this including victims never properly identifying the root cause of an attack (this can actually be quite complicated when you consider a complex web service and attacks on subresources) and victims choosing not to take public action that admits they were attacked (some victims would rather just sweep everything under the rug and not talk about a security breach). In real data, significantly more certificates in attacks I have studied expire instead of being revoked meaning the malicious certs simply sit out there until their lifespan is reached.
And you argue that such "stale" certs still pose a risk where the best available option for mitigation is to reduce life-time?
Overall, I wonder if the targeted life-time of 47 days is short enough to make a significant impact on these threat scenarios. What incidents would have been prevented had we already had cert life-time of 47 days?
Kind regards
Roman
Ryan Dickson
Hi Roman,
> What incidents would have been prevented had we already had cert life-time of 47 days?
One way of (mis)interpreting this question is that it suggests unless measurable harm has already been realized from a characteristic of the Web PKI, and despite the existence of evidence of opportunities for abuse of that characteristic, the threshold for this community to take action to better secure the Internet has not been passed.
That perspective is flawed because:
It assumes the absence of evidence is the evidence of absence. (“My house has never been robbed, so there’s no need to lock my doors at night.”)
It prioritizes reacting over being proactive. It suggests there’s no need to proactively manage risk, and that we should only respond once harm has been realized.
It assumes that all attacks and abuses are immediately known, and that harm can be accurately measured. As Henry pointed out in his response, this is not always the case. It’s also possible to imagine victims avoiding disclosure given it presents reputational harm.
Given your question, how would we expect harm (which I presume is the intent of your interest in incidents) to be monitored, measured, and reported, such that it could be correlated with validity?
Understanding how this could be reliably performed, especially when considering things like BGP attacks or local network attacks (both of which are attack vectors in their own right, but that can also be used to limit the utility of public observation of other attacks) would also be interesting.
Thanks,
Ryan
Roman Fischer
Hi Ryan,
You have a very good point there. Of course, it's important to take pro-active measures and I will not say that I am against shortening certificate life-times (or validation information re-use). I'm simply wondering where the "optimum" is. What risks are reduced at what level at what cost? A proactive measure that reduces a small risk at a high price may divert valuable resources from mitigating other risks (e.g. Quantum resilience, pushing automation, …).
I was hoping that the community here is so large, diverse and well-connected to other security "bubbles" that we could learn from real attacks and use these reports to gauge the relevance compared to other threats…
Kind regards
Roman
Henry Birge-Lee
Dear Henry,
Thanks for giving more context to this topic.
>1. I have seen attacks where an adversary obtains a certificate during an initial attack and then retargets the same victim in a second attack with the misissued certificate from the first attack.
And I understand correctly that the second attack would have been prevented (or at least made significantly harder) if the certificate life-time would have been shorter?
>2. Attacker infrastructure is often highly ephemeral with transit links being burnt, accounts getting shut down from non-payment, servers getting raided etc... Keeping the infrastructure required to attack domain control validation up and running is difficult, and I often see adversaries tear down infrastructure and somewhat start from scratch for a new campaign. Thus, it is completely probable that an adversary would have the ability to bypass domain control validation and then later lose it.
I'm not sure how to connect this to the proposed reduction of cert life-time. Attackers typically are already way more agile than the average customer we service. For an attacker, automation, speed, stealth… are their core-business. For regular certificate owners, it's about stability, simplicity, cost and effort. For me it would seem that shortening certificate life-time will be less of a problem for attackers than for customers. 😉
> 3. After an attack, victims often take evasive maneuvers which can include switching hosting providers or DNS providers. This is often done while root cause analysis is still underway (post mortem investigations can take a while and infrastructure needs to be recovered right away). Sometimes these maneuvers do actually prevent retargeting by the adversary (e.g., moves to /24 prefix space for sub-prefix BGP hijacks, providers that use DNSSEC or RPKI etc...). Thus, I would argue that an adversary obtaining an initial malicious certificate actively decreases the likelihood of an adversary being able to obtain a second malicious certificate due hosting changes/security responses by the victim.
So, once an attack is detected, certificate life-time is becoming less of an issue or how am I to understand this statement?
>4. I think a very relevant topic related to cert lifespan is cert revocation. Many of the attacks I have studied never lead to revocation. There are a variety of reasons for this including victims never properly identifying the root cause of an attack (this can actually be quite complicated when you consider a complex web service and attacks on subresources) and victims choosing not to take public action that admits they were attacked (some victims would rather just sweep everything under the rug and not talk about a security breach). In real data, significantly more certificates in attacks I have studied expire instead of being revoked meaning the malicious certs simply sit out there until their lifespan is reached.
And you argue that such "stale" certs still pose a risk where the best available option for mitigation is to reduce life-time?
Overall, I wonder if the targeted life-time of 47 days is short enough to make a significant impact on these threat scenarios. What incidents would have been prevented had we already had cert life-time of 47 days?