[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
Christian Heutger
ch at psw.net
Wed Aug 21 15:22:44 MST 2019
> I think it's important to note that these responses can be read, and certainly read to me, as a powerful display of how dysfunctional many enterprise customers remain today, when it comes to
> their certificate configuration and in how they view automation and modernization. That so many organizations continue to mistakenly believe that doubling their manual renewal rate would
> cause severe disruption, or that automation of certificate issuance is an unimportant aspect of their own organizational security and agility, is a compelling reason to proceed with this ballot and
> mandate reduced certificate lifetimes. The survey results make clear that many current enterprise customers are not prioritizing this work on their own, and that a mandate covering all CAs at
> once is likely the only effective way to drive progress here.
Or it shows, that enterprises reject automatism because of many reasons and prefer a systematic change management process. In which position are you to force enterprises to be unable to decide, if they prefer automation or want to stay on a formal change management? And it’s not about just a one year validity period, it’s about that this won’t be the last step. So this lowering down of lifetimes as workaround instead of working directly on the primary problem and issue should be negotiated at all and enforcing companies to follow your position on automation is really a bit arrogant.
On Wed, Aug 21, 2019 at 1:04 PM Chris Bailey via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
All,
Entrust also sent out a survey to our customers similar to the DigiCert survey to solicit feedback on the proposed ballot to shorten certificate lifetimes. The total response size was 573. We have also included the customer comments. As you will see, there are many comments.
The overwhelming number of customers are not in favor of shortening certificate lifetimes.
Thanks,
Chris Bailey
---
SURVEY TO ANALYZE IMPACT OF CA/BROWSER FORUM BALLOT TO REDUCE MAXIMUM VALIDITY PERIOD FOR SSL/TLS CERTIFICATES FROM PRESENT 2 YEARS TO 1 YEAR
1. On average, how often do you replace your TLS/SSL server certificates today? (571 respondents)
88.48% Every 2 years or longer
10.30% Every 1 year
0.17% Every 90 days
1.05% Don't Know
2. To what extent does your organization currently use automated certificate installation methods (e.g., Venafi, ACME, DevOps orchestration)? (467 responses)
74.95% 0% automation
9.21% 1% to 10% automation
5.14% 11% to 25% automation
6.00% 26% to 50% automation
2.35% 51% to 75% automation
2.35% 76% to 100% automation
3. What would be the impact on your organization if the CA/Browser Forum approves a ballot reducing the maximum validity period for SSL/TLS server certificates from the current 825 days (27 months) to 397 days (13 months), effective for new certificates issued on or after March 1, 2020? (496 responses)
Comments: See Comments for Question 3 at end of this message.
4. Do you favor or oppose the proposal to reduce the maximum validity period for SSL/TLS certificates from the current 825 days (27 months) to 397 days (13 months)? Why? (573 responses)
12.57% I favor reducing the maximum certificate validity period from 825 days to 397 days.
83.25% I oppose reducing the maximum certificate validity period from 825 days to 397 days.
4.19% Don’t know / no opinion
Comments: See Comments for Question 4 at end of this message.
5. Under the proposed ballot, an organization and its domains would have to be revalidated every year instead of every two years. Do you believe the added security from revalidating this information every year is worth the cost of revalidating this information every year? (573 responses)
14.31% Yes
79.41% No
6.28% Don’t Know
Comments: See Comments for Question 5 at end of this message.
6. Do you have any other comments or additional information you would like us to present to the CA/Browser Forum on your behalf? (You will not be identified in connection with your comments.) (142 responses)
Comments: See Comments for Question 6 at end of this message.
7. In which country are you located? (570 responses)
62.28% United States
2.63% Australia
0.18% Brazil
15.96% Canada
0.18% China
1.05% France
0.88% Germany
5.09% United Kingdom
11.75% Other
8. Using your best estimate, how many employees work for your firm/organization worldwide? (568 responses)
7.54% 1 to 99 employees
15.96% 100 to 499 employees
10.18% 500 to 999 employees
27.02% 1,000 to 4,999 employees
21.75% 5,000 to 19,999 employees
16.32% 20,000 or more employees
1.23% Don't know
--END OF SURVEY--
**COMMENTS FOR QUESTION 3**
What would be the impact on your organization if the CA/Browser Forum approves a ballot reducing the maximum validity period for SSL/TLS server certificates from the current 825 days (27 months) to 397 days (13 months), effective for new certificates issued on or after March 1, 2020?
- would be very impactful do to frequent renewals required and impacts to integrations that leverage SSL/TLS certs.
- Manual process, will require additional administration on our part
- It would increase our support costs and not necessarily provide increased security.
- More clock cycles of administration
- Severe. I have hundreds of certs. I like having time in between having to renew.
- Multiple areas in my company are having trouble preventing certificate outages as it is. Reducing the validity period to 13 months will increase the rate of certificate turnover, and lead to an increase in system outages. The impact of a system outage can at my employer and may range from a web app being down to interruption to factory processes.
- No impact.
- This would create additional management overhead and the possibility for service disruptions as other enhancements to certificate services are introduced that requires changes to technology solutions.
- zero impact. we already have max validity of 12 months
- COST IMPACT
- for public certs no impact for internal certs huge impact
- Increased maintenance, compliance, customer notifications, integration and testing -
- It would increase workload as we maintain a lot of certificates for our agency.
- Resources from point of view of more effort to renew all certificates and the process impact/downtime to applying new/renewed certificates
- For manhours to renew and reinstall certificates
- Increased certificate maintenance - probably double the effort required today. Pending certificate renewal automation - which we are not against but there are multiple sites and platforms involved and initial setup will require significant work.
- Currently not much effect. However the continuing trend toward shorter and shorter periods is concerning. If we had to do 90-day certs, that would be a major pain.
- More manual work.
- It would require certs to be updated manually at a more frequent rate.
- Huge administration impact that might push us for another provider who can provide at least 2years.
- as we are not allowed to use self-signed certs even for internal only sites or servers, this would have a great impact on our systems.
- possible to forget
- too frequent for me
- We have been moving more items to cloud based system which provide their own certificates and renewals but still have more of our own for remote access and some phone connectivity. These expire in Jan 2020 and Jan 2021.
- we only do one cert for 2 years, and it should be a problem
- Significant. It would effectively double the effort in maintaining the many certificates we need to manage, at no benefit to us or our customers.
- It would be disruptive and would have negative business impacts.
- It would double the work (based on frequency) required to manage certificates.
- It would be a major blow to our limited team who manage certificates for our organization. Every renewal, we already deal with multiple outages and issues between teams and third party vendors. Many of our "cloud" solutions make it a painful and tedious process to go through cert rollovers.
- The workload would increase somewhat. We are not a huge organization but the certificates are managed by one person.
- It would introduce extra overhead to all our technical Teams.
- On the servers? No impact. We do have applications that are tied to the certificate and renewing each year will cause issues.
- This would significantly increase our workload for updating certificates and would be undesirable.
- it is an administrator nightmare. we have over 200 applications and to have to coordinate replacing certs that often and taking outages is not acceptable to the administrators and the users
- The impact on my portion of the organization, which signs PDFs to ensure authenticity would be minor and would perhaps help to keep staff familiar with the renewal process.
- We would have no impact as we currently only issue 1 year certs as policy.
- increase in workload
- This change would not be helpful to our organization. We would need to spend extra time renewing certificates and arranging system outages for server restarts.
- Significant impact, would change vendors. This is a ridiculously low threshold for the amount of staff we have that handle this (1) and no automation. We have 25-30 certs to manage.
- 10,000's devices would require manual intervention by my support team more frequently.
- redeploying costs increase
- It would have a large impact because of the number of SSL certs we use.
- Heavy alteration to processes.
- That will increase the amount of work hours and downtime to renew certificate. The impact is high.
- We would have to update more often with all the different certificates which is a pain.
- Interruption of service and downtime for services\systems that require use of an SSL certificate.
- A lot of work. We can't automate this. The certs have to be saved on the server in a keystore. The certs also have to be chain is a very specific way. Overtime has to be paid and scheduled for a person to do the changes off hours.
- This effectively will increase workloads unnecessarily.
- It would cause more work for us and our customers.
- We would need more resources to manage renewal process
- It would be detrimental. Are IT dept is small but we do have a fair number of websites. Having to update certificates every 90 days would put undue strain on our human resources.
- Increase in management time and cost for our customers, as some certificates would have to be renewed a second time for a short period of time when trying to harmonize expiration dates of the customer's services.
- We would have more work load, but we consider it acceptable
- It would have a HUGE negative impact on our organization.
- It would be a huge management problem. We have a very complicated array of different systems with different, typically manual, procedures for updating certificates, often owned and managed by people who do not themselves understand certificates. We have no way to automate this. Our people who do understand certificates are spending far too much time helping these system admin replace the certificates instead of doing more productive work. It is costing us a lot of money.
- Minimal
- Roughly 250 additional hours of work per year.
- It would have a sizeable resource impact on our cyber, application, and systems teams.
- This would not be good. It is difficult to keep up with certificates as it is and replacing is always a bit of a "process". We don't have a lot of people that are skilled at replacing certificates and it is a time consuming and often complicated process. It also puts us at risk of expired certs.
- While we prefer a max validity of 2 years the impact to our organization is minimal. This will also depend on additional cost as a result of reducing the max validity.
- We would spend more resources and time to verify certificate renewals. We have a lot.
- Double the work to manage certificates
- Negligible
- Doubling the amount of work needed to manage certificates
- Minimal.
- More manual effort to do the steps that are needed. We have NO budget for more people OR automation software to do this more frequently!
- Even the lowering down to 27 months has increased the burden on our organization for renewing certificates, lowering it to 13 months would increase the demand across all of IT to an unacceptable level.
- Changing the maximum certificate validity period from 27 to 13 months would just about double our companies current workload for the certificate renewal process.
- Severe impact and major issues for renewal that are shorter than two years.
- It is difficult to keep up with certificates on even a 2 year basis, moving it to 1 year will be quite difficult to manage and the risk is having significant site issues due to expired certs.
- We have a couple hundred certificates being managed, this would require a turnover on average of about 1 certificate per business day
- it would require a lot more work to update certificates on our servers and applications more frequently.
- Increase need to renew the certificates and a requirement to move to an automation solution to be able to keep up with the volume and requirement of the certificate change. For us this would be a significant procedural change and would require a re-architect of how we presently deal with renewals and how we could embed orchestration into that process.
- Administrative overhead
- It would not be good.
- Too much unnecessary work to replace certs that often. No value.
- It would mean that we would have to generate new certificates every year instead of every other year
- More work for everyone, staff, vendors
- Since we'd be halving the lifetime of the certificates, that would double the work we do manually replacing/renewing them.
- I would have to spend more time replacing certificates.
- Reducing the validity period would increase our certificate work by double or more.
- Twice the work
- This could take me days to renew all certificates every few months. The longer the validity period, the longer I have in between renewals. I would have to research and purchase a certificate automation tool.
- We are highly opposed to this measure. If you are to incorporate this, a multi-year timeline needs to be established. An entity as large as us, will be highly impacted if this change was approved.
- Major impact, no autorenewal processes around 150+ certificates.
- additional administrative effort
- it would force us to develop or purchase some automation
- It would require more work.
- It would effectively double the workload of maintaining certificates in the environment unless there is an ACME etc. method deployable in our environment.
- more cost involved
- We already replace most of our certificates every year. Our certificate replacements cannot be automated.
- It would have a big impact since the majority of our certificates that a deployed are renewed manually so that would require that work for renewing the certificates to happen more often.
- This would suck severely! I despise certificates and this would unquestionably increase my frustrations with using certificates!!
- eh...more work.
- It will be a pain in the ass with the additional management frequency.
- This would have a high impact on our business which is healthcare. It will increase costs and resources required on an already stretched budget.
- It means more work for us.
- It would double the amount of work. Why does it double the security
- Positive Impact
- Little to none
- It's effective
- no impact.
- This would be very detrimental as it represents a significant increase of our workloads. While most certificates are for web sites, we have a significant number that are used in applications and appliances, most of which do not offer a way to automate this process.
- much more work for the IT department to renew and install certificates on many of our servers.
- it would cause us to have to change out certificates more frequently.
- big LOE increase, perhaps double
- It would create more work for my developers on a more frequent basis. It's already a headache to coordinate updating our SSL certificates every 2 years because we have numerous secured domains, internals tools that rely on certificates, as well as multiple locations in which they have to updated at. Updating the security certificates at the moment is a full day’s work and we have to coordinate it during off-peak hours to prevent major outages while people are using our website. We also can't rely on automation because our content delivery network is not capable of this yet, so for our organization, this proposal would put even more stress on this process.
- Certificate renewals for us takes at least an entire day and its always a major exercise. Not all systems update the same way and we often have to involve third parties. I’m not sure how this will measurably increase security.
- We would have to do a manual refresh all our certificates every year.
- increased administrative workload - we have no automation for certificate replacement/renewals
- increased cost and overhead
- It would be a disaster. We have hundreds of certs , I have other things to do I don't have time to replace certs all day long.
- It would increase the frequency of replacing our certificates for all our systems. A small impact, but an impact none the less.
- More work, potentially more outages as application owners miss these new dates.
- more busy work, just what I need
- Too much time would need to be spent managing certificates.
- More time required for certificate management.
- We would have to worry about certificate expiry more that we currently do and critical patient services would be affected more often.
- We would grudgingly comply and look for an alternate solution.
- Have to hire more people to ensure certificates won't expire. Impact would be negative
- More support work
- Given that we're currently moving to SSL on the majority of our web sites (100+), the increased work load would require more manpower that we can't afford.
- increased workload and difficulty keeping track of expires. This would mean sites and services going off line. A lot of the systems which use certificates cannot be automated. Very few certificates are used for webservers.
- We would spend more time managing certificates
- The impact would be more manual updating of certificates on our systems.
- A modest increase of work for IT administration.
- We have hundreds of sites and although we have researched automation not every vendor in our stack supports it.
- Substantial impact on the staff dedicated to managing and testing SSL/TLS
- a lot more work, we are a medical facility and changing certs usually requires downtime for the type of apps we use and I highly doubt that those apps will have automated cert renewal anytime soon as a feature, especially when the FDA has to approve any changes, which is why medical software updates are so slow
- This would be a significant impact. Many products we have to interact with do not have the capability to leverage certificate management automation tools.
- Way more admin work. I think 2 years is a good mark. 1 year is just too soon.
- Have a negative impact
- We do not have the manpower to do this consistently every year, this is something we would not want to do since it would pose a hardship on the small team that does it now.
- more work for IT staff
- This would be very burdensome because we have a lot of certificates for an org of our size.
- Increased overhead in replacing external-facing (public) certificates.
- that would add a lot more management load, plus , the time and effort for third party vendors who manage some of our apps to schedule maintenance windows. I am definitely against a 13 month lifespan
- Increased cost, increased administrative and logistical overhead
- It would create a lot more work manually renewing and reinstalling certificates.
- Annoyance, if it were up to me I'd make the certs not expire for 5+ years or more. It's a pain to manually renew the certs.
- administrative time consuming issues
- A lot of whining
- a lot of overhead on the support teams.
- No impact
- This would be a huge impact. Please keep it at 825 days.
- Double the manual effort and cost for certificate management
- Right now it would double the amount of time and effort we spend reissuing all certificates.
- We would be flooded annually we have too many certs to handle with too many internal groups to do them all on the same year!
- significant
- Given the number of certificates our organization has in production in a non-automated environment, this change would have a severe impact on our operations.
- This would be a lot of extra work for us
- As a school district, we have a minimum IT staff and budget. Shorting to 13 months would negatively impact staffing resources and budget.
- No impact
- twice the work obviously. but we are working to make our process more efficient and not relying so much on the web site owners to generate the renewal - as this is where most f the delay is for us.
- Additional workload for Operations and Security staff who are already swamped with project workloads. Adding more frequent maintenance tasks will directly impact timelines.
- none because we renew certs yearly
- Increased cost.
- Additional labor as this cannot be automated. Given the current situation of how we operate.
- Changing the CA if this happens, this will be the impact. We have ultra reduced team.
- increased work load for renewals, and due to internal change Process lead times, effective life of some certs could be reduced by several months, which in turn would increase costs as renewals would be more frequent
- It would be disruptive to us. We're a large government organization and cannot use automated methods for domain validation or certificate renewal due to the security posture of our systems.
- High impact. We would need to acquire a tool to automate certificate deployment.
- Major impact as SSO and MFA becomes the norm.
- Likely would kill our service offering.
- Increased operational cost for maintenance/replacement activities.
- Would dramatically increase cost of commercial SSL certificates. We are using commercial certificates on a temporary basis.
- As more and more applications become web based, the reduced time frame would add additional monitoring. A stable auto renewal process would remove this burden.
- Additional maintenance overhead
- We generate and mange hundreds of certificates for our infrastructure and our customers. Automation is a real challenge because of the diversity and complexity of managing a large number of independent infrastructure. Added to the cost of certificate we would probably have to get another person full time on the renewals/automation.
- No large impact at this time.
- No Impact
- This would be undesirable and increase workload
- More work which more cost
- Huge increase in overhead/administration, plus as with all change, no matter how small, the possibility of outage and service interruption.
- This change will bring an unwanted burden to our web environment. Our staff is small and these changes take time to plan. We would rather have this time to focus on other projects instead of changing certificates every year.
- More frequent renewals
- Will move to using an internal CA for all of my systems as they are all internal and we have no public facing systems.
- Much more work and costs, I don’t think this is necessary at all.
- More work with no benefit
- More admin overhead
- Increased overhead for maintain our many customer systems
- None I can see for now except for increased administrative workload
- more work
- It would create more work for our organisation.
- We have between 10-20 services that use the WildCard certificate that we will have to manually update each year. As certificate installations are not automated within our organisation this would have a significant administrative impact in terms of time resources on our small IT department if this is done each year.
- Admin and financial overhead
- It will be small impact, we use only few certificates with longer than i year period
- Extra workload
- we would have to do a few more renewals a year
- We have 23 certs currently and this would be unworkable on a yearly rotation.
- Validating every 13 months will add additional effort and time and may lead operational issues.
- More administration
- HIGH
- We would have to implement an automated way of updating our domain wildcard certificate on about 40 servers. This automated deployment method would also need to be agreed with the system suppliers that operate fully-managed servers that run our domain certificate. Currently we seek supervised desktop access to install our domain certificate on them every 2 years. We also have a variety of appliances that run our domain certificate, and I doubt they would support automated deployment.
- Certificates are managed manually, so reducing the validity would require more frequent handling of key material and key exchange. Which for us would be less secure.
- big impact, lots of stress
- It would be practically impossible to manage it because of the bureaucratic procedures of our organisation
- Significant amount of manual effort as we have many HTTPS sites
- not a lot
- lot more time an effort
- High. We are a healthcare organisation with limited IT resources and use many applications. To ensure this get updated yearly would need extra resources.
- To review everything within a very short time.
- More costs
- much more workload. e.g. multisan cert containing 100 sans of different domains, adding/removing sans during the cert lifetime leads to different expiring dates for the eligibility to issue cert. more validity period means less frequency of revalidation. less validity period will lead to constantly have one or more domains to revalidate
- It would be business impacting and very expensive to hire extra staff to deal with verification and certificate issuing for all the domains.
- we have to automate the process
- More management charge over IT people, taking away time from other more important task.
- I don't know exactly, but people don't like renewing certificates
- It would be a pain, but workable I guess. Any less than this would be a real problem for us though...
- Bigger amount of work in order to generate, install the certificates and also in administrative tasks. A lot of problems related to unavailability due to oversights.
- only little impact - i bit more workload
- creating a work group only for managing certificate issuing
- Great impact.
- We would have to automate certificate renewal
- quite a lot of effort, as automation is not yet in place for renewal or even new delivery of SSL/TLS certificates. All the job would need to be done manually, for every application using these SSL/TLS certificates.
- Very much more works. Probably some certificates will expire. We have many customers and SSL is growing.
- A great deal of extra work, which I don't want thanks
- double effort and workload
- It will cause much more work. Even when automated you have to keep an eye on more frequently that it is working properly.
- Significantly more manual overhead
- More work , less gain from using certificates.
- This would significantly increase the workload as we do not currently use any automation to renew certificates. We would probably need more people for this job. By no means do I expect a change of less than 2 years.
- Have to study change of CA or automation renewal
- More work for us, more maintenance brakes for customers.
- this generates massive additional effort even it automation is setup its success must be monitored
- A lot of extra work.
- Significant since it will require much more effort.
- It would cause too much overhead and increase the workload to our admin and project teams
- WE have only few servers, but this would be manual work to renew these. So more work which I would considers futile, extra work.
- admin overhead and expense
- This would be a huge impact for us and our clients. Many of our clients liked the 3 year option but to move to a year this would create a lot of overhead for these groups and downtime when certificate have to renewed.
- It would be a pain, but we'd learn to live with it.
- Negative, we would like to keep it 27 months
- The operation cost would drastically increase.
- It would be a nuisance, but hardly catastrophic for us. We only have a half dozen certs. I would be opposed to having to revalidate my organization every year though as these processes are manual and would come at inopportune times causing us to choose strategically when we buy a cert.
- increased workload
- Doing so would increase the amount of manual work our organization would need to do to renew our certificates.
- Huge. The turnaround time for our service provider takes a really long time and would add much more work for our staff who manage certificates.
- There is no any technical barrier. But admin overhead will be high because we have to get internal organization approval for renewal, generate CSR, renew certificate, install certificate in annually instead of every 2 years.
- this will increase our workloads significantly and costs. Totally unnecessary to do this
- it would more than double the time spent renewing certificates
- very high.
- It would suck.
- Unnecessary overhead
- Once we move all of our certs to Lets Encrypt won't be much on an impact. Your certs are crazy expensive.
- It would be a pain to replace the certificates
- It will add an extra work to our already busy engineers.
- Extra work, more chance of error, potential customer downside if a date is missed.
- More investments on automation
- Moderate increase in operational overhead / 3rd party contract costs to manage certificate renewals and installation, potential for service outages due to failure to manage certificate renewal in a timely manner
- There will be a lot of issues including replacing on every subdomains uses on Wildcard certificates
- We would need to find a better, more automated way of renewing.
- Increase in Operational and Maintenance Costs
- Increased overhead on maintenance for something each organization should have control over.
- There would be little impact to my current organisation as we generally renew SSL certificates every 12 months.
- Significantly increase workload for an already overloaded staff.
- This would doubt the certificate renewal work for both the requester and approver in our organization.
- We might want to further reduce reliance on public certs and use internal certs. Renewal of public certs every 2 years is already an effort.
- Considerable impact until certificate automation would be in place.
- More manual work for our staff
- Will unnecessarily increase the workload related to the certificate replacement.
- Increase the work for the LRA of our organization and the system administrators. It will not be beneficial for our organization.
- More work
- This would create additional overhead in an already over worked and time stricken department.
- will need to research how to automate renewal
- none.
- This would be a huge cost to both my organization and our customer.
- We would need to move to a more automated renewal process.
- Significant
- Due to the manual processes required by legal mandate the extra workload of replacing 400+ certificates every year, across multiple disparate devices is excessive. MOST of these devices are not capable of having their certificate updated automatically.
- Much overhead of renewals and configuring equipment
- No major impact
- We would spend more time changing certs than necessary.
- More administration work. Our onprem and iaas systems w\couldn't be easily automated as there are many different types of devices used with certs.
- As we manual change certificates manually it will create more work.
- More manual tasks performed more frequently that adds no value.
- This would require more of our time and increase the likelihood of an improperly installed certificate causing issues.
- Relatively minor
- Certificate team has to do lot of follow-up with vendor and impact analysis again and again.
- Unsure - if this imposes a change to DoD standards, then yes it would impact and force more rapid renewal. I presume the change to 397 days would not be highly onerous, just a pain.
- Not too much, at this point.
- There is a remarkable amount of administrative overhead that will go along with this. The number of certificates that we have to manage will mean that we are renewing and managing a different cert every other week.
- Undue IT staff burden
- More work and probability of errors.
- Lots of resistance
- Additional cost, changes interrupting operations
- considering the hundreds of devices and scada devices we use don’t have a method to support automatic certificate registration, we would be screwed. Its already a huge task to get and replace all of these certs, and as scada devices, I doubt there is enough capacity on them to run the libraries and processes required to do an automatic renewal - its already a challenge just to get a cert running on them. This is a big deal for us as a manufacturer with these small devices that we are trying to secure - it’s not like some huge web server that we can add the auto enroll / auto renew client. We would have to switch to an internal CA and add that root to everything internally - which is more pain and less secure.
- This would create a lot of work. Many devices still cannot be automatically updated.
- It would cause more disruption in our environment.
- None at this point.
- insufficient resource to perform task until higher automation use.
- It would create unnecessary overhead in certificate management. We only use external CA for systems that cannot use automated certificate renewal, so this would cause us major issues
- It would increase our administrative work load and be an unnecessary annoyance.
- Increase in overhead costs
- As long as the process for renewing certificates with the CA can be made more streamlined than it currently is then this is not a problem. At the moment the process of getting a quote (for our price point), getting spending approval, uploading CSRs, downloading certs, email-based org validation (as opposed to DNS-based validation) are all way too manually intensive to reduce the frequency. If all of those things can be streamlined then we would happily automate certificate renewal. Even a 90 day validity would not be a problem.
- increased risk of web sites and applications becoming unavailable to users due to certificate expiry, increased overhead of managing certificates
- Would push clients to drop EV or push automation platforms like AWS ACM to support EV.
- More work, or need for automation
- It would be a huge headache that would roll around too frequently, especially dealing with ADFS and updating Relying Party Trust relationships.
- It will basically double the maintenance costs for certificates
- Increased labour costs for us and our clients.
- Extra administrative burden / costs. The safe and secure management of the private key is more important than the automation and renewal frequencies, in our view.
- This change would double the work our organization has to perform to change certificates. We have certificates exchanged with many customers, partners, and integrated vendors and this change would significantly increase the tempo of our having to spend maintenance time updating certificates.
- Increased workload on the teams with the fewest people to support it. More risk of outages due to expiration and misconfiguration.
- massive hardship ridiculous amounts of labor spent on managing certs
- Minimal change
- It would increase our workload substantially.
- We would need to manually update hundreds of SSL certificates every 13 months, this would require a large amount of operational effort for just updating certificates
- We would have to either spend effort to automate renewals where possible, or spend double the manual effort that we currently spend on certificate renewals.
- Naturally, we'd have to renew certificates twice as often, but 1 year is certainly do-able.
- Reducing time would only affect us in annual budgets
- This change represents a significant burden on organizations with small IT departments.
- This would be a huge impact as there are many legacy systems where automatic certificate renewal cannot be performed. Spending time and effort to automate something that doesn't need to be automated is not where we want to spend our resources.
- more operational overhead
- Move overhead
- huge impact to order and manage renewal on thousands of servers when no direct access on DNS to validate, and server not visible from public internet or firewalled
- As the workload of maintaining certificates is increased with little to no benefit, we would more aggressively limit our usage of third-party certificates and secure communications in other ways where possible.
- We apply quite a few certificates, which, more and more, need to be thrid party certificates. Reducing validity could dramatically increase our workload and risk to application operation. It should be up to us to decide.
- This would cause a major issue for our IT team. We would need to dedicate a team to certificate replacement. 24 months is a perfect expiry time line.
- Much increased workload. With current work freezes during holidays (our busy season), we would have to replace certificates even more often to prevent expirations during peak season.
- more work
- Underproductive and lot of overhead. We have multiple certs managed by variety of teams and business owners. It would involve more planning and change control if we reduce the validity period
- There would be no immediate impact since we already proactively limited validity to 1 year for external certificates and also use this as an incentive to push users to use internally issued certificates that are valid for 2 years.
- 13 months
- The effort to manage our certificates doubles. In the majority of cases, automation is not an option as the workflows involve multiple parties. This would have a very negative effect on our resourcing and operations.
- Extra work for very little benefit.
- Cost - more communication with customer of changes to our certs etc
- More management, disruption
- we would have to validate every year rather than every 2 - boo
- The impact would be great as most of our business partners would not be able to keep pace with annual renewals leading to brand and reputation damage for our domain.
- More workload to manage renewals
- Significant cost to implement
- Low impact
- Higher costs on management and on validation processes.
- high
- It would create an increased workload in terms of tracking and renewing certificates. We do not have automation for this, it is a lot of manual work. I foresee some systems getting missed and the issue not being discovered until something stops working.
- It'd be a major impact. We rely on the vendor to generate the CSR, which is billable and our IT support vendor to purchase and install it, which is also billable. If we don't purchase a new certificate in time, we lose the ability to generate revenue.
- Increased workload in the short term, but that would also drive increased automation for certificates.
- Medium impact as this work is completed manually today
- At one year, I would not only be revalidating twice as frequently, but I would need to perform more reporting and my overall attention would need to be more in tune to SLL Certs in general. With the amount we have, as the period continues to reduce, I would not be able to cover this responsibility on my own and would need to hire someone specifically to handle this job.
- more often downtime and more work!
- This would cause a significant impact on our company and we have many systems, which use SSL/TLS server certificates and we already feel an impact from what we used to have (3 years) to (2 years 3 months), so reducing it even further would not be something we want to do.
- No impact form reducing to 13 months
- More manual work to update ssl certs
- not fun
- More administrative overhead, possibly more outages for certificate replacement depending on the webserver vendor (at least a restart)
- Would cause a huge workload increase for us.
- it would at least double the amount of certificate issuance and create more work for each web master and/or server administrator.
- Minimal
- more work for admins...
- Our deployment teams would require more work hours dedicated to renewing certificates, taking them away from other duties. An automation solution would not be quick to deploy.
- My opinion is that it would be a low impact for us as our internal standards are to replace CA SSL Certificates after one year.
- We have 100s of certs that we manually manage, so the impact would be huge.
- Just a flavor change - no biggie
- Increased workloads for staff, more time allocations for certificate management.
- It would double the work to update certificates. And we have a number of clients trusting our certificates so it takes a lot of work to get them all to trust the new cert. That would have to happen twice as frequently
- More administrative overhead for sys admins to implement new certs which could mean more maintenance windows to perform these tasks. More tasks for admin personnel to perform regarding cert renewal.
- It would have a very adverse effect for our ability to support certificate services for our remote clients.
- It would highly impact our org. We do not have someone dedicated to managing our certs.
- Hi. many of our certificate renewals require expertise our application owners do not have.
- Additional time spend working with Web administrators, Application Administrators and Network Administrators for each certificate renewal.
- Additional work
- Many sites including Exchange which are critical to the operation of our business. Cert renewal is currently not automated and thus is quite error prone
- This would require much more manual effort to renew and replace the certificates that we're using right now.
- More time and effort in keeping certificates up to date
- Not having the option to allow for a longer public certificate validity period would increase the management and risk of outage. During any long term resource deployment, certificates which last a longer period are greatly welcomed. Did they also suggest resetting user passwords every 15 days to make them “more secure”? ;)
- Major impact. Current corporate standards have been set to 2 years, as most systems require manual renewal for certificates. Reducing this to 1 year creates a major overhead for the organization.
- This would be a disaster. As an MSP we have to work with over 250 clients to ensure deployment within appropriate timeframes coordinating this on a yearly basis would be untenable.
- Onerous requirement
- Increased operating costs, higher potential of down time.
- Cutting the expiration in half would mean we'd spend twice as much time managing certificates.
- This would be an unwelcome burden on our infrastructure staff. Certificates are embedded throughout our infrastructure and each vendor has a different process for renewing/reinstalling a certificate. To add an organization re-validation on top of this seems excessive,
- The impact would be similar to denial of service. A major negative impact to our production systems.
- We are not in favor of this! The impact would be horrible because we have almost 100 certificates to renew.
- Hundreds of staff hours.
- minimal - we do not have more than 10 certs
- Impact would be minimal
- This is an unnecessary change and one that would negatively impact our organization.
- I call it a cash grab and absolute nonsense.
- Likely significant. The administrative burden of replacing certificates in an enterprise with a multitude of different technologies, each requiring different replacement methods is not trivial and doesn't lend itself to easy automation. What's not clear in the information which has been provided is why this is being pursued. I can probably safely assume the answer is because it's more secure, but it would be good to understand in precisely what way this makes things better. Over time do certificates become less trustworthy, for example at two years is one less trustworthy than at 60 days. The clear benefit isn't obvious.
- greater management overhead
- No Impact
- Our systems do not offer automation of certificate renewal and would double the time to go through the process.
- Having to renew/request new certs every year would add more work for us. Most certificate requestors a requesting for even longer validity.
- We would be forced to automate the solution. Not a bad thing, but I would like to see more offerings to automate.
- More administrative work. We have over 12 production certs, and a small staff to manage it.
- It would be a pain, more time consuming task with a small IT staff. Why change cert if you don't have to. Website url will not change. Actually, I liked the 3 year certs before they scaled back to 27 mo.
- Limited resources to effectively manage too frequent change
- That would double my work load
- we have roughly 225 certificates so reducing the validity period to 13 months would cause our organization to have a resource more dedicated to certificate management.
- This would be a terrible burden and to be honest, I cannot see the reason to do such a thing.
- More than double the work. Increased risk because every time a cert is touched there is risk that it gets left lying around where it can be stolen.
- It would have a huge impact. It would double our amount of resources required.
- Since we have a limited staff and the majority of our renewals are done by hand, this would be a huge impact to resources on our team.
- Increased manual effort for issuing certificates.
- Impact would be minimal, a little more work for admins to swap certs.
- It would not be a huge impact. Mostly annoying.
- We'd have an annual certificate changing party where I force all the admins to update their servers certificates. We currently use a wildcard for most things and each admin is responsible for making these kind of changes on their own servers. Our process wouldn't change much, it would just be a more frequent event.
- It would require more man-hours to maintain the certs.
- Negative. We have excessive workload already.
- More labor time for an already overloaded IT Team
- A lot of overhead
- Minor inconvenience but may lead to needing to go elsewhere for long term cert. If longer period is still an option on EV cert then it doesn't matter
- This will greatly impact or work load!
- No major impact
- More overhead to renew certificates
- increased maintenance costs
- Require significant additional work for local staff.
- It would double our workload involving certs and hurt morale.
- We have around 600 external certificates and over 10,000 internal certificates. While some do auto renew, this would be one to two people's full time job.
- this would effectively more than double the time spent now and would be a significant impact
- high impact due to additional administration overhead
- Significant increase in workload to replace certificates on a yearly basis.
- With our limited staff, this would be a nightmare ! It’s hard enough to keep up with as many certificates that we have. We have 1200 users/500+ servers with applications with 4 people maintaining this!
- This will seriously affect our operations as we will need to manually schedule outage windows in our IT systems every 12 months to install a new certificate.
- Certificate operations would increase in frequency. I would like to think that it would prompt us to accelerate our automation efforts.
- Additional expense and management of certificates.
- Twice the amount of work requiring twice the man hours. We have 1000s of certs-- this would become someone's full time job
- All of our certificate renewal processes are currently manual. This change would result in an increase in workload.
- It will significantly increase resource requirements needed to manage certificates
- pain
- More management required to continually update and maintain the certificates on products.
- It would cause an increase effort on the part of our system engineers as well as increasing the likelihood of system outages due to expired certificates.
- This would require more manpower or the purchase and training on some form of automation tool.
- If reduced, we will spend more time to renewing certificates
- hardship - may have to look for a different certificate vendor
- More time spent renewing certificates.
- I'll have to adapt but I prefer renew with a larger frequency.
- Either a lot of additional administrative work to renew certs more frequently, or a project to look into automated certificate renewal processes.
- Extra work … we are against this.
- The administration overhead would be very heavy on our organization and would be a burden. With delegated administration deployed geographically the coordination efforts involved would also cause undue stress on the organization.
- Operational overhead
- Way more work on our end. Possible downtime due to having to deal with 3rd party vendors.
- lots of work will be involved to replace expiring certs
- A lot more down time for long standing operations, lot more operation work for sysadmins
- Minimal impact, potential adjustment to current practices to become more proactive in replacing the certificates.
- More work load to renew, install, and test
- Increased Certificate / manual process 825 is a good medium
- Greater workload to manage SSL certificates, much greater chance of certificates expiring and impacting business operations.
- It would require us to apply for new certificates manually twice as much
- horrible … horrible horrible horrible … don't do that
- We are not at full automation, nor are have we fully adopted the mindset of that rapid of renewal.
- we would be forced to move to automated solutions for certificate management, installation and renewal.
- Significant increase in manual labor/tracking and/or expenses to automate certificate deployment. We are VEHEMENTLY against this. Direct impact to our bottom line.
- Increased work load
- More than doubles our workload in certificate management. But understand improving security. Would support 18 month.
- This would drive additional work to us who manage our certificates but it would probably also encourage us to develop a better more automated process to manage our external certificates.
- No impact.
- minimal
- Negative impact. Outages more frequent.
- more work
- Additional work on our service desk team
- More time managing certificates
- disastrous impact on workload renewing certs 3x as often as is current!
- Twice as much time commitment and cost to replace certificates.
- Create work that is not needed
- It would add to my burden as an IT Systems Administrator, without any clear measurable benefit.
- Increased workload as we do not automatically renew certificates.
- services down more often as have to replace more frequently. certs expire all different times of year so customer impression is that IT dept is a joke as things are always broken
- Support personnel would be required to devote additional time to managing the renewal and installation of certificates at roughly twice the frequency.
- Excessive workload
- extra administration
- Minimal, though having to re-validate each year would be an extra pain. 90-day expiration would suck, though.
- Additional Workload to generate and apply certificates.
- Scheduling off hours work for our applications that require there services to be restarted for a new cert is difficult with a global company of our size. We have people working in just about every time zone. Having to do this more frequently than we do now would be a major inconvenience.
- a lot more extra work and bit potential for service unavailability being more frequent
- This would greatly increase the amount of manual work required in our environment.
- Ugh.
- It'd be a lot more work. We don't have automated certificate installation.
- A lot more administration work. Most of our certificates are not web servers, they are other devices that may not support automated methods at this time.
- negative impact.
- Multiple certificates to change, scheduling some systems downtime is what will make it harder.
- Extremely negative - Much more manual labor dealing with certificates.
- Lots of added overhead
- it would double our workload and other internal teams also, email, notifications back and forth, the only good might be records would be easier to keep track.
- Will increase the cost of maintenance. Not supportive.
- I would expect more expired certs. and more emergency issues due to lapsed certs.
- Heavy labor impact, not only for renewal/replacement of the certificates themselves, but domain validations as well. We have hundreds upon hundreds of domains we would have to revalidate. It is not a trivial effort.
- minor
- Inconvenience
- test
- We would need to double our staff to take care of the additional load.
**COMMENTS FOR QUESTION 4**
Do you favor or oppose the proposal to reduce the maximum validity period for SSL/TLS certificates from the current 825 days (27 months) to 397 days (13 months)? Why? (573 responses)
- Manual process, will require additional administration on our part. I place a cert on a firewall. I am not replacing the firewall for 3-5 years.
- I oppose the proposal. The impacts to corporations would be too high. And I don't see that reducing the validity period would greatly increase security benefits. It's important to remember that it is critical to balance the need for security with operational support. I feel reducing the window further limits places extremely burdensome requirements on business without greatly improving security. In the case of my company, this would mean replacing 3,000+ certs every year. And remember that availability is a key tenet of security. This proposal introduces great risks to system availability. Finally, while I appreciate some of the improvements the CA/B Forum has made in improving security of the Internet, remember that SSL certs aren't restricted solely to websites. And, quite frankly, I don't think the CA/B Forum has any business dictating how often my company needs to rotate its certs or demanding that we use automation. Our cyber security department has a limited budget. While automation is all well and good, we don't have $1,000,000+ available in our budget for a tool like Venafi.
- since our impact is minimal no real opinion either way.
- While I can see the need to renew certificates in 2 years, I think a shorter requirement would increase the work load unnecessarily.
- I'm not sure what this is accomplishing. Most organizations that purchase SSL certificates intend to operate that cert for longer than a year. If the cert is abandoned after only a year, it is most likely because that effort failed. Otherwise it will continue. For general business considerations, 2 years seems to be a common market fail-point. Around the two-year mark, a business either fails or will continue to a second stage of development as a business. Two year renewals and re-validations coincides with a long-standing known business-wide trend of success or failure, and marks a good time period for re-validations and renewals.
- I oppose this reduction. It reduces options to your users. Those wishing to enforce more frequent cert replacement can simply enforce a local policy to update certs before 825 days. Those wishing for longer cert replacement times will be impacted if validity dates are shortened. If users wish certs to be replaced for frequently than 825 days then they have that prerogative. If user wish certs to be good for 825 days and the validity date is reduced then
- If this is for tighter security as certificates become at risk then it is worth it to be more frequent. What is the real reason to renew sooner?
- I'm unsure what would be the benefit of such a reduction, other than perhaps to organizations that sell automation services or consulting.
- See above!
- Shortening the validity period will have a varying effect on organizations depending on their size and maturity. Many small to medium organizations already experience pain with certificate management and the technology is definitely not to the point to allow all systems to handle automated certificate rotation. We have already felt the pain from the reduction to 825 days and shorting it further will cause greater stain and likely lead to more configurations.
- It will be a nightmare especially since certificates are not my only job. Business owners and users are not very understanding each time we have to take an outage and replace a certificate.
- The public, to the extent that they know about online security, rely on SSL and related technologies to conduct their business securely. The impression of security can be as important as the actual underlying technology. Requiring website owners and others to renew their certificates annually could aid that.
- This is in line with our current security standards.
- A number of our systems do not automation to update the certs requiring manual intervention.
- those organizations that are more concerned about security always have the option of reducing their expiration durations
- A lot of work. We can't automate this. The certs have to be saved on the server in a keystore. The certs also have to be chain is a very specific way. Overtime has to be paid and scheduled for a person to do the changes off hours.
- I see no valid reason to reduce the duration. And automation is sometimes NOT an option, for some highly secure servers, or located behind a firewall preventing the use of mechanisms such as ACME. This would only increase work and costs for customers, with no added benefit to their security.
- We consider it a security improvement
- This would be a management nightmare for us and I seriously doubt that it would enhance our security that significantly.
- However, I don't think that end goal of 90 days or less is feasible for most organizations.
- This would not be good as many systems that use certificate have their own unique processes for replacing and/or updating. We also do not have a lot of staff that can do this task and they are overwhelmed as is. This would be more complex and not offer much in benefit.
- Depends on additional cost.
- See above.
- No, This would add risk to our websites due to the potential of expired certs and increase the workload on our staff even more.
- While there may be a small measure of security gain in the shortened life of the certificate. The cost structure incurred and the weaker procedures that will inevitably begin to permeate the process at budget reduced companies in the end would actually reduce the security for these companies I believe.
- just a make work proposal
- More work for questionably more security?
- This puts a burden that we are not prepared to meet.
- This won't cause us much extra work.
- This would suck severely! I despise certificates and this would unquestionably increase my frustrations with using certificates!!
- This would have a high impact on our business which is healthcare. It will increase costs and resources required on an already stretched budget.
- Keep in mind it is 'Maximum' not 'Fixed'. The industry should allow the customer to select their own validity periods based on their needs, not every business has resources to manage certificates every year
- I feel 825 days is adequate
- These changes represent added workloads to already overburdened organizations. I believe the reasons for these changes are primarily for security, however, this issue can (and should) be mitigated by the proper use of certificate revocations. This also represents an attempt to build income by forcing users to purchase or build automatic certificate renewal processes, or upgrade embedded systems that cannot be automated.
- This would create essentially no reason to make use of EV certificates because most browsers don't even show the green bar feature anymore and the only other reason we wanted an EV certificate was to have less frequent certificate updates which will be abolished if the proposal goes through successfully.
- while this is a good idea, the state of the industry is not ready for this.
- I don't understand why this is even being brought up. It's ridiculous. I don't even know why it was cut from 3 to 2, now 1 year? This is a bunch of nonsense. Who's pockets is this going to fill is the real question. I can tell you that I would just start using self-signed certs with a 30 year expiration date for any servers I can.
- I'm all in favor for reducing Certificate life for security reasons, but it seems like a ham-fisted way of forcing people to automate. It would have no impact to the management of automated systems, but many systems still do not play nicely with automated certificate deployment.
- Replacing them is relatively easy even when manually done. Reducing the validity would help minimize certificate theft usage.
- The people who work in the trenches should be making decisions. Not people who are sitting in glass doors. Next they will say every month we need to change the certificate.
- CRL is effective method to invalidate compromised certificates, so no need to force support personnel to update valid certificates when there is nothing wrong with them.
- Increases cost and risk for very minimal security gain
- Good and bad on both sides. More job to manage yearly expiring certificates but theorically slightly safer web if expiration is shorter.
- This should be left up to the organization to decide and the reduced validity period should be a recommendation only.
- just adds more work, if certs aren't actually sufficient for security, then that is a separate issue which needs to be addressed, like maybe more encryption bits, but to be honest, since at least the US government has quantum computers, it is all just obfuscation anyway.
- Certificate validity ultimately comes back to the validity & reputation of a Certification Authority. When a CA issues bad certs, the industry reacts and often that CA is relegated to the dustbin. Increasing certificate renewal looks great on paper, but in the real world there are too many poorly implemented solutions that cannot leverage certificate management automation, putting a manual onus on administrators to perform additional work.
- We do not have the manpower to do this consistently every year, this is something we would not want to do since it would pose a hardship on the small team that does it now.
- see my comments on question 3
- I oppose this at this point in time due to the impacts stated however I am in favour in general of reducing the maximum validity period.
- This would cause undue workload on my team and I have not been given realistic reasoning on why it is needed.
- administrative time consuming issues
- I have never seen a study indicating that security is _significantly_ increased by frequently replacing SSL certificates. This proposal needs to be grounded in reality. CAB might believe that the Web and the Internet are one and the same, but certificates are used for more than protecting the Web. I cannot replace some certificates without including our payment processor - they don't blindly trust our public certificate unless they have a copy on their end. There is no way to automate this process.
- What is the reason??????
- theoretically this would reduce the impact of a compromised certificate as the certificate would be replaced earlier even if the compromise wasn't identified earlier.
- as mentioned above, it will increase work load for renewals (arranging change windows and lead times etc) and costs could increase with the more frequent renewal intervals
- This is now a money making scheme it would appear. What is the actual time it would take to break a cert?
- Only ticked 'oppose it' because there was no option that said: "Why? oh my god why would you do this?"
- As this leads to a rapid cycling of certs (especially if it leads to a 90 day cycle!), it will require additional work that we're not interested in.
- We all know who is driving this and it is about time internet returned to what is was intended for - the betterment of humanity, not to line the pockets of a few Californian billionaires.
- Increase in work load or requirement to purchase orchestration software.
- if it strengthens web security.
- Admin and financial overhead
- From a security perspective the validity is better if its shorter however cost is a factor
- unworkable on a yearly rotation
- I feel 2 years is a good amount of time to re-validate information
- I don't believe the case for increased security has been made by the proposed reduction.
- As above.
- only pseudo- security; for provider not practicable
- Extra costs as the single year option is very unlikely to be 50% of a two-year certificate therefore more expensive over time. Extra administration overhead of buying and installing certificates.
- OV and EV validity period will be in alignment. This will impact on ordering more OV than EV but it will make see the main difference between OV/EV as Extended Validation is the best way to assert identity and protect a company.
- More costs
- see above
- more secure
- I think that nowadays 825 days period is well sized.
- Doesn't seem necessary to me.
- It would ensure that person/application owning the certificate are still the same within organization. If certification is too long, sometimes difficult to find back relevant person. 2. It would be put more pressure on making sure an automation product would exist within organization.
- Too much work to follow hundreds of customers SSL certificates.
- I use certificate allocation as a gateway point for new projects and as a means on identifying if systems are still needed. we have no prospect of automating certificate deployment any time soon , so this would be a nightmare. No thanks
- double effort and workload
- We should rather focus on security aspects like keeping the private keys in physical storage (HSM). I don't see an benefit in reducing the certificate lifespan.
- I don’t see a need to change. Most people don’t use the cert to validate an organizations identity anyway — they just want to be sure that their web traffic is “secure” whatever that means and certificates provide no assurance of that anyway. Why inconvenience the honest people who have strong valid certificates?
- shorter validity period will increase the security of certificate usage.
- It depends on how hard it would be to recertify domains on private networks
- To install a certificate without automation, takes 3 teams..... It a nightmare to coordinate.
- We don't have a way to automate the renewal and installation of certificates in many of our platforms. For example, some certificates are installed on "software appliances" for which we must use the manufacturer's manual procedure for updating certificates.
- I would agree for EVL certs, but possibly overkill for standard certs. I would be okay with shortening to 18 months.
- As a large enterprise, the operation and maintenance cost of certificate renewal is immeasurable. We still hope that there are channels to apply for a certificate that is valid for three years.
- If we could implement automated renewal for at 80% of our certs I might change my response to favor it.
- The change would need to address a security concern before I found it acceptable.
- I would rather increase the maximum to 3 years. If others would like to renew their certs more often then go ahead but don’t force everyone to do that. We have a lot of security initiatives to take care of don’t want to waste time renewing certs.
- I believe, if managed appropriately, 825 is acceptable for securing our sites.
- Why not have the option of 1 year or 2 year expiration? This is how it how it works currently and its great. Sometimes you have sites that are low security risks but will need to be around for years to come, so a 2yr cert makes sense. Others you can set as 1yr if you anticipate them going away in the near future. It makes sense to me to have the option to choose. Thanks!
- It is unclear to me how this will provide significant risk reduction.
- I favour the move to automating certificate renewal process.
- Helps to keep things safe let if a very is compromised
- I haven't understood the reasons for doing it except the automation, that not always is the solution because there could be involved business validations that should be performed more often.
- This change would do little to improve security while increasing the amount of work we must do.
- We can have both option.
- Our URLs and domains do not change that frequently. This appears to be a "change for change's sake" proposal. Is there a security risk in a longer validity period? This is not made clear.
- This is an acceptable shift to improve security, as long as tooling and notification improves.
- SSL/TLS certificates are used in many, many devices and operating systems for which no way to automate certificate updates exists. So would become burdensome to IT staffs.
- much more secure, more checking, etc.
- At least it forces people to consider automation for their certificates.
- This is the maximum duration. With automation we could select a lower effective duration. Large companies with antiquated process in an operational model will have the workload doubled for certificate renewals per year.
- It currently takes us about 4 weeks to do manual cert renewals in our environment. We dont have resources to do that more frequently. We don’t have ability to automate this in any way.
- 2 years would be more appropriate. Organizations should not have to renew constantly, seems like a money grab.
- Reduces the period of an undetected key compromise. If they can be automated then I'd be in favour of a renewal period down to 90 days. This would provide enough time to detect and correct a failure to automatically renew.
- If forward-secrecy ciphers are used, the benefit of shorter crypto periods is much less. Better efforts would be spent improving the use of certificates through DANE support in browsers. This does not help reduce phishing. CAA + DNSSEC + DANE do.
- Increased costs.
- From our vantage point, there is little security improvement benefit vs. the increase in workload for our entity.
- The documented risk of cracking SHA-256 is not high enough, yet, to justify the decrease in key lifespans.
- this is stupid cert cycle provides not one iota of improved security; just extra labor costs and someone pocketing some money somewhere
- Workload and operation risk... i.e. when we have many certificates in place, buried deep within some applications we have little resource to support there's a risk we'll miss an expiry and or take significant time to replace an expiring certificate without costly resourcing.
- We are still adapting to the 2-year standard. We haven't even had a full 2-year cycle yet and already there is a push to shrink it further.
- This will create an unnecessary work load
- Unless there is a proven security risk this change has no value and will only increase support costs and certificate related outages.
- Don't do this. It would result in us looking to another provider to do business with that offered longer terms.
- More management, disruption to service
- I would support making them 2 years long or 735 days
- Rationale for the opposition is that many of our business partners will struggle with annual certificate renewals and we feel that he current validity period of 825 days is secure enough and does not provide a large surface area for attack or comprise of public key infrastructure.
- Same answer as to question 3. We do not have an automated process and this would place an undue burden on us. Even if we did have an automated process, I am not clear on how renewing annually and/or using an automated process would make things safer.
- I oppose it "at this time". I believe that the validity period should be reduced in 1 or 2 years.
- My company cannot use the automation services because they do not want to concede the access. Therefore I oppose reducing the maximum validity period.
- I support this proposal, but re-validation should be automated.
- If I wanted to change certs all the time I'd use certbot.
- having a 825 day renewal window allows us to update certs on a biyearly basis
- Since I do not have an ideas of what the need to reduce the life of a certificate I have to lean on the side on not reducing. There may be valid reason but without knowledge of the reason I have to look at the work load that would increase for the CA and for my work space and work place as well.
- Speaking only for our business this would not be a huge impact but it means we have to deal with this as a task more frequently, and dedicate the time to do so. Not fully understanding what the implications are of keeping a certificate longer than 13 months so will have to do research on my end.
- By simply reducing the time validity period of the certificates I do not believe it will have desired impact. A seamless automation solution needs to be available that can be used with multiple CA's and 3rd party hosting vendors. Otherwise all you are doing is increasing the workload for everyone. Unless they want everyone to move to Let's Encrypt and whatever hosting is compatible... Although we are currently using Venafi we are still a long ways from having the install automated, due to incompatibilities and unavailable agents, this also does not include anything that would be hosted publicly at a 3rd party, only what the Venafi engine can connect to on the internal/DMZ network. A reduction in the validity period right now would be a huge burden and cause additional work to maintain certificates. This seems like a huge make work project that doesn't factor in all of the issues, and considerations for coordinating between many Lines of Business and many 3rd party hosting sites.
- I cannot speak for those that manage multiple External Web Servers, and how the proposal may affect their day-to-day operations. My particular hosts are intranet and customer facing, and by design cannot use an internal CA authority, must use a public CA authority. A bit costly, but cheaper that helpdesk tickets explaining to internal users why to reject the browser recommendation to close, when the server is using a valid Self-Signed Certificate.
- Adds no practical security benefit in our environment; creates unnecessary additional operational overhead; automation solutions are not yet mature / widely available / affordable.
- With the current changes today - best to be safe than stupid and take those consequences
- This will increase manhours consumed per certificate managed so depending on the org, this could increase costs to manage certificates significantly.
- reducing the validity period greatly increases my work
- Oppose; 2 years is a sensible limit. 1 year will generate too much overhead for existing areas and processes.
- It does keep the certificate inventory more current and requires less time to transition to new crypto standards (minimum key size, ECC). It will also force organizations to automate certificate replacement. Since there are some systems that do not support automated certificate replacement, it would become a heavy burden to make the max validity less than 12 months.
- ABSOLUTELY OPPOSED!
- policing can be done through revocation
- From an Operational perspective, if Max. validity is less, then there is less risk of seeing an outage due to forgotten Certificates or processes.
- Limited resources to effectively manage too frequent change
- I'm assuming that reducing the validity period is going to somehow reduce risk (by reducing how long a stolen cert can be used for) but it's also increasing risk by increasing how frequently a cert must be touched. Every time a cert is touched there's risk that it might be left laying around and stolen. Essentially, this increases work for web administrators and increases revenue opportunities for CAs that issue trusted TLS certificates (because SSL is dead so stop talking about it). While this may be well intentioned, this isn't the answer to how to protect certificates better, this just makes them less valuable and puts them in greater risk. Also, automation increases the attack surface. Conversely, issuing certs with validity periods for 10 years is also a risk but in the other direction. A little over two years is a good balance.
- Since the certificate revocation process can terminate compromised certificates I don't see the need for this change. It's already more burdensome having at the current 27 months after it was shortened previously.
- I think the current two years works well giving the other security protections in place to revoke, etc.
- I am not sure I understand why? It there security concerns?
- It's honestly not that big of a deal for us.
- I'm in favor for basic cert so long as there is EV or other premium cert available for extended periods
- Understandably the proposal is looking to mitigate risk from illegitimate certs, but taking an approach to forcing all cert types and functions down to shorter renewal cycles is shotgun and punishes the masses due to the illegal few. Company identity validation can run on a shorter cycle without impacting certificate validity - if the company validation fails, revoke the certs.
- It's annoying. If there is a problem with a cert, revoke it. Stop making those of us in the trenches without the benefit of endless resources suffer because of some personal crusade. If they want to re-cert every 90 days then nothing is stopping them from doing so right now. Don't make us do so. All this will do is make people more likely to self-sign and say the world can deal with it.
- If the verification process has been followed through for initially verifying the requester, there is no reason to expire the certificate every 12 months. If a key is compromised, the cert should be replaced at that time. It's like the new guideline on password rotation - no need to rotate passwords unless it has been compromised.
- This is not a good idea.
- I am in support of this.
- Certificates are poorly managed in our organization. This may force us to adopt automated processes.
- Good security practice.
- It would be optimal to be able to "tag" certain certs as being more/less important for your organization, thus causing them to have longer or shorter renewal frequencies.
- Several applications have unique requirements to replace certificates … and it's a lot of extra work.
- The administration overhead would be very heavy on our organization and would be a burden. With delegated administration deployed geographically the coordination efforts involved would also cause undue stress on the organization.
- Would prefer something like 18 months.
- this will increase overhead work
- I don't see a good reason for reducing the validity period. Creates more work to renew the same certificate and validate the domain more often.
- Strongly Oppose
- VEHEMENTLY opposed
- Would support 18 months.
- I setup a policy to only allow 1 year issuance, thus it’s like an annual refresher for system admins to remember how to install a certificate.
- I honestly, believe it should be 30-90 days
- Manually placing our wildcard cert on hundreds of systems is a time consuming process. Would not want to do this more frequently than we already do. It was bad enough they shortened the window from 39 to 27 months cutting in half to 13 would be a nightmare.
- I have government certs that cannot be automated
- I strongly and vehemently oppose this overreach in policy
- I do not feel it is necessary to reduce the validity period.
- It's fine, I suppose. It's a good security measure, but I naturally recoil a bit when I see Google throwing weight around in an effort to curate the Internet.
- Scheduling off hours work for our applications that require there services to be restarted for a new cert is difficult with a global company of our size. We have people working in just about every time zone. Having to do this more frequently than we do now would be a major inconvenience.
- see question #3
- Poor cost / benefit IMHO.
- To avoid intensive work of scheduling changes (change management) on multiple devices
- Why not 25 months. Every single year is a bit crazy.
- more security
- Leave the maximums where they are. Shorter lifetimes will be easier to deal with as automation becomes more widely adopted, but for now, it will be a lot of extra work for very little gain. 2048bit RSA is our standard and a key pair isn't going to get brute-forced within the current 27-month maximum. What's to gain with the shorter lifetimes?
- security is an ongoing challenge, this appears to be a better hedge against future attacks
- We just reduced certificate lifetimes a couple of years ago. I think 2 years is a good compromise between operational efficiency and security.
**COMMENTS FOR QUESTION 5**
Under the proposed ballot, an organization and its domains would have to be revalidated every year instead of every two years. Do you believe the added security from revalidating this information every year is worth the cost of revalidating this information every year?
- Because I can cancel a cert that may be compromised at any time.
- No, I don't believe validating domains every year would improve security. We have 250+ domains already to manage. And it's a struggle to update those every two years as it is.
- This is time consuming and can lead to being unable to issue certs or renew certs if a revalidation is missed
- Not with our Current staffing levels
- It will only be worth the cost if you charge more for it.
- No!
- For us there is very little turnover so our ownership/management doesn't change very often.
- If domains and certificates were being compromised on a regular basis this would make more sense. In our experience one has never been impacted. Should metrics exist indicating rates of compromise exist to back this decision it would generate serious concerns as to the competency and value of the said issuing bodies.
- Hard NO. It is very time consuming and therefore very expensive to re validate domains.
- Those revalidations are already a huge strain when managing dozens of different customers, with all the back and forth required to guide some of these customers through the process. I see no valid reason to require more frequent re-validations, especially for OV certificates.
- This is not an effective (and definitely not efficient) approach to addressing the threat.
- We have additional risk of expired certificates and few staff that can handle. It would be better to focus on helping us with better best practice methods to help us better secure our platforms.
- I don't feel very strongly about this because it is very easy to revalidate domains, but I don't see this change increasing security very much.
- Web sites for our company are stable entities that are dealt with when needed. There is nothing gained by doing these steps more frequently.
- Again, this would be more of a risk to us and not a benefit.
- Again too much work to do every year
- More often means more automation which means removing people that could check strange things that might be happening vs automation where everything could be humming along (good or bad)
- Domains do not change ownership very often so having to revalidate more often would cause more work and no benefit.
- It would have been nice to include what are the "added security" of such a measure.
- The revalidation process is extremely painful and time consuming.
- Validating our domains can take up to two weeks of our time. We don't have that kind of time laying around to devote one person to revalidate our domains at a higher frequency. Our domains aren't set up standard so automated validation will *not* work and has never worked. Our validation usually takes several support calls and we usually have to have engineers go in and manually approve our domains. It takes a long time to get our providers to admit that they need to take these measures for us.
- This would suck severely! I despise certificates and this would unquestionably increase my frustrations with using certificates!!
- This is a waste of time and resources, a terrible idea!
- Validating an organization and its domains more often makes sense because it helps secure the internet
- But only if we start using the CAA DNS records, reducing the need to update the DNS each renewal.
- I think this is an unnecessary change and would most definitely push people away from wanting to spend more than twice the average amount of an SSL certificate for an extended validated alternative. In most cases, I think it's safe to assume that the organization in question did not change ownership in a two year span. Even for the edge cases, it would be a huge shame to make the process harder for valid organizations because of a few.
- Stop. Just stop.
- Every extra dollar charged is eating into our budget. Then we would be forced to use wild card certificates from DigiCert and not worry about Advanced certs.
- This is a manual process for our customers, some of whom are not technical. Again, I think a recommendation and or changes to the process need to happen to reduce the burden of these changes.
- Maybe tier it if you want but no one wants more work, other than people whose only job is to make work for others so they feel like they actually have a sense of purpose instead of getting a real job.
- Tls sha2 is very robust. Maybe the CAs should collaborate with other vendors to come up with the next gen tls, so that we can leave the max period of 825 days.
- Absolutely not in any case.
- Absolutely NOT!
- I am in favor of certificate renewal every, but don't believe the effort/cost associated with domain verification is worth it.
- As previously mentioned the move from 3 years to 2 almost killed this service for us. Going to 1, would could not possibly continue to operate as we have been and would likely have to go to much cheaper certificate re-seller.
- See previous responses - this is not because 'a certain browser company' cares particularly about all things security otherwise they would not be advocating reducing use of EV certs, it is, as always, part of their master plan to control more of the internet and thus make even more money.
- Depends on cost, revalidating certs is generally quite a quick process
- See comment above
- The technology is what makes certificates secure and as such carrying this out more frequently will not add ANY extra benefit.
- Probably yes, but the administrators always have the chance of renewing the certificates of their systems if they think it is needed. However, 825 days is still secure.
- If validation intervals would be increased validation should be completely automated and continous so it would increase security. Manual validation only validates pretty much just the validation date so doing it yearly or every two years is pretty much the same as far as security is conserned.
- Its again a challenge for big organization.
- Revalidating is more streamlined and automated than renewing/replacing certs (at least for my organization).
- It is difficult to weight the added security from shorter lifespan against a possible drop in organizational care for certificate renewal. Frequent renewals may lead to a drop in protecting keys, etc. I would favor improving certificate revocation and suspension.
- This wouldn't add that much effort for us.
- Why not have the option of 1 year or 2 year expiration? This is how it how it works currently and its great. Sometimes you have sites that are low security risks but will need to be around for years to come, so a 2yr cert makes sense. Others you can set as 1yr if you anticipate them going away in the near future. It makes sense to me to have the option to choose. Thanks!
- Exception for edu domain
- Too disruptive and no matter how much automation one has, it involves, people, process and customer updates. This is ridiculously too frequent of a process
- The case for what added security would be gained has not been sufficiently worded.
- We have automated part of the solution for this already, so it is of less concern to us.
- It would make more sense to revalidate when there is a change in domain registry or pooling account renewal.
- If it can be done through DNS validation (e.g. Persistently publishing a TXT record) can be automated by certification authorities and puts the onus on the DNS domain license holder.
- There are currently too many other vulnerabilities that seem to have a higher impact. The bad buys won't be thwarted by needing to renew their certificate or just buy a new one.
- Definitely not
- Most systems remain static for at least two years, usually longer.
- ABSOLUTELY NOT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- This repeated revalidation will push both sides into full automation. If this automation is not properly constructed, it will just create a new avenue for compromise.
- Unless the value can be quantified, this is again more work without value.
- Based on this years EV validation process for several domains I am involved with this will not improve security
- Make it 2 years not 1
- It would be a better security measure to control this frequency on NEWLY created domains only.
- I am not clear how forcing everything to be revalidated annually makes us safer.
- No
- I don't know what the current cost is and I am not aware of the cost impact of reducing re-validation.
- This is similar to the current timeframe for EV, I don't think the impact would be as bad. It would be nice if there was a way to specify an alternate email for certificate requests/validations though, as our hostmaster group only handles domain registration, and certificate related requests are handled by us.
- Basic math says twice the work equals reinforced security at twice the cost. Question: what is the difference in security today and after March 1, 2020 if proposal goes into effect? If the security remains the same, [only now that we are touching and looking each year oppose to each two years] than only the cost has increased. I do not see how this will apply to additional security!?
- Else it will cost more later....
- I think the underlying TLS cipher suites are more important that changing cert keys every 24 months.
- No. Validation per 2 years is good enough. As long as validation is given after checking that the domain is registered until at least the 2 years requested, it should be fine.
- Since domain validation can't be automated (new random value each time), I would no be in favor or shortening that interval. If the revalidation process was performed by checking for the same marker (DNS, web file), it would be much easier to accommodate the shorter revalidation period.
- ABSOLUTELY NOT!
- Not at all. Certificates can be hacked if the hackers want to. It has been proven over and over again.
- I have the same thought as for Answer 3. I'd like an expert to tell me precisely why this is more secure. Perhaps cite some real-world examples of problems due to the current two year revalidation which clearly wouldn't be present at one year.
- DV happens via DNS. This should be automated and shouldn't really have a cost.
- The community is assuming that this will actually improve security but what I don't think is being factored into the risk equation is that the increase you get from a shorter life can be more than offset by risks introduced from having to renew certificates more frequently if the custodian doesn't have mature practices for managing certs. Think of it this way, certs will be worth about half of what they're worth today because of the reduced lifetime but the risk that they get stolen will go up because without fixing the practices of the people who are renewing certs the statistical likelihood that certs get left laying around goes up. This results in less security (but also less time to exploit the stolen certificate). Reducing the time a certificate can be exploited does nothing to reduce the impact that occurs while it's exploitable and the proposed change increasing likelihood of theft but fails to reduce impact (it just reduces the amount of time a thief can exploit the certificate for).
- I am not sure what the cost is on your end, I think it helps tighten security though.
- Definitely not. Validation for us is already extremely difficult.
- The current rate of hardware evolution or decrypt algorithm does not warrant the change according to us. But it would also oblige organization to update to the latest and greatest standard more faster, which is good.
- I believe in the improvement in overall security and accountability tying legitimate businesses to their certificates, but i also don't know if this lever (revalidating the company) will measurably improve internet security.
- The CA could use Whois history tracking information to see if the info has changed and the domain requires re-validation. Every 2 years is acceptable.
- Unnecessary.
- The cost isn't that high.
- No - only if there is complete compliance is this worth the effort. Since I can get a free certificate from other services instantly with no validation I do not see this achieving the goal for those of us that are legit.
- Unless the revalidation process is made less intrusive without costing me more.
- Some certs are not critical for the business and a longer renewal timeframe is not an issue.
- No no no - use a centralized flagging or point system, like state governments do with licensed drivers
- In particular this is valuable for EV domains
- Validating a Company and its domains via a DNS tag is an easy update. This would help root out bogus companies and domains.
- Absolutely NO
- When you're in Networking, it's a bad look to ever say security measures aren't "worth it", but we all know compromises sometimes...er...often, are made. I wouldn't fight it that much, but it's making an aspect of my job more costly and tedious, to be sure.
- Absolutely not.
- Domain name validation is usually set with ownership of our own, with client side ownership this would add additional work to all
- I don't believe the cost benefit is worth the extra expense.
**COMMENTS FOR QUESTION 6**
* Do you have any other comments or additional information you would like us to present to the CA/Browser Forum on your behalf?
- Is the cert technology is flawed? That is the real question.
- Yes, the CA/Browser Forum needs to understand how their actions impact real businesses. We don't all have the unlimited budget of Google to work with.
- I do not perceive this as providing additional value or security...
- Opposed to internal CA certs being 13 months when Auditors point to CA Forum to write us up for our internal certs.
- 27 months is adequate enough.
- I would like to hear more about the security implication of automated certificate renewal - what are the risks?
- One year (and even better 90-day) renewals will ensure a more steady and frequent revenue stream for the certificate vendor industry. Providing new paid-for access to utilities to facilitate more automated renewals and re-validations will generate increased opportunities for industry revenue.
- We are a government entity and we are forced to use https for everything and not able to use self-signed certs this would cause a major need for use to get things automated as it could turn into a full time job.
- Do you have a lot of fly-by-night organizations/domains that are hard to keep track of? If so, deal with that issue separately, rather than making things more difficult and costly for established businesses. When I first got involved in acquiring certificates ~20 years ago, I remember it being a fairly detailed process to register/validate my organization for certificates. Is this no longer the case? Certs should have some perceived value on the internet, not be something that anyone and his dog can acquire. If an organization (or certificate) NEEDS to be revalidated after a year, perhaps we shouldn't be representing them as a stable and trustworthy business!
- Please do not reduce the maximum cert limit. It would not be advantageous.
- In so much as my opinion matters don't do it!
- I am not in favour of total automation of the SSL/TLS process. I believe that the routine human validation of customer information by the Cert authority or their agent is an important element of the trust the public place in the system.
- Are you really finding certificate being valid for 1 year is more secure? Who is cracking these private keys? I don’t understand how the crypto can be compromised? Rainbow tables? Brute force? What is the driving force for 1 year?
- More frequent refresh makes sense for *some* SSL users, but not all. Should not increase required technical hurdles via behest of an organization rather than allow each business to make their own specific choice that is best for them.
- This is tax payer money. I cannot automate this process. This is not convenient for every organization. A small company with just regular WEB site maybe but not for big ERP software that is more complex and across Canada
- In the technological industry, we understand that security needs to be ingrained into everything we do. To reduce a certificate to a single year will increase workloads and increase fiscal needs, unnecessarily. From a CA point of view this is a great method to increase revenues, however, will provide the consumer zero benefits.
- If security is the primary motivation for these proposed changes (I fail to see how much security it would add, to be honest), then maybe limit it to EV certificates, while leaving DV and OV certificates as they are?
- Please focus instead on better security processes around certificates and help educate us on how to meet these best practices.
- We would not support reducing the period to anything less than one year.
- HELL NO to the 90 day option.
- You need to go the other route and allow validated corporation/organizations to do 36 month certificates again. For companies with 100's of certificates 12 month expirations increase the workload for all of our IT teams.
- I believe my answers to the previous 5 questions clearly defines my company's position on this matter.
- Please maintain the 2 year process. Instead focus on stronger validations and help us with best practice that allow us better ability to protect these certs.
- A verifiable and proven security issue would should require this change. Not just because a user wants it changed. They should be able to change their environment to what they want, but why put this onus on everyone? I do not see the need to do this. Security measurements also need meet practical practices. A user's password is not changed every week. This seems to be the same type of scenario.
- No
- We are overburdened with work already and oppose going down to 90 days of validity. Propose strengthening certificates instead to keep their validity at 1 year+.
- This would suck severely! I despise certificates and this would unquestionably increase my frustrations with using certificates!!
- I guess I would ask - Why. If the agency has been validated, why the need to revalidate in 13 months. Do Agencies change that often where they need to be revalidated?
- Great initiative
- I understand the need for security, but there needs to be a risk reward evaluation. We cannot spend all of our time managing certificates when we need to apply resources to upgrading and maintaining our many and diverse systems. Automated certificate renewal system such as Let's Encrypt, are ripe for abuse and present a false sense of security to both the customer and the business owner. Automated systems have a tendency to be forgotten and much damage can occur if issues are not addressed in a timely manner.
- I think this proposal has not been thoroughly thought out by the browser who submitted this and quite frankly, I see our CA and its competitors losing a huge portion of their customer base because of said proposal. This not only creates more work for businesses to update their SSL certificates, but it also creates more work annually to prove the organization is still valid. EV certificates specifically are already losing value today when there are numerous free alternatives with automation such as Lets Encrypt and removing yet another advantage to having an EV certificate on my website makes it that much easier to abandon securing my website(s) with an expensive solution when I can pay less to have almost the same benefit from regular certificates. The green bar is already being phased out by Google who has the most browser market share and by removing the 2 year validity period, the only customers who would still need an EV certificate would be the customers wanting to only own a single multi-use certificate with an organization attached to it. Please rethink this proposal and realize that this would ultimately negatively affect the people who use them.
- This is fine if your organization has armies of people to manage this. Not everyone has PKI experts on staff.
- While this is a good idea, the state of the industry is not ready for this.
- The CA/Browser Forum should actually have smart ideas, not dumb ideas.
- We would have to worry about certificate expiry more that we currently do and critical patient services would be affected more often.
- Tell them to be realistic in their decision. If they think changing a certificate every year will improve their certificate they are wrong. One year is a long time for anybody who has the right tools to attack any system. One has to deal with lot more than just applying the certificate every time. It is quite simple on IIS and some Apache instances. It is not trivial when we apply certificates to non standard web servers. We would have to dedicate a team of folks just to do certificates year round.
- If the person who proposed this wants to go to annual or quarterly renewals, they're free to do that now. It should not be up to them or you to mandate that for everyone.
- With rapid changing certificates and expiry, users will see expired warnings more often and get more used to clicking ok to continue without thinking. This will reduce security.
- If there is an issue with certificates, then changing them even every 90 days isn't going to fix the issue, correct the underlying problem by making better encryption and security than just trying to change your mediocre security measures faster than the competition can crack it. Pushing off the work to us common folk, while a time honored tradition, isn't fixing it.
- Make a new class of higher security certificates with maximum lifespans of thirteen months to secure financial transactions, medical data or other particularly sensitive data. By increasing the administrative cost of security to validate lower value sites (blogs, web comics, surveys, etc), you increase the probability of folks choosing to simply use http instead of https.
- None that come to mind
- Organization validation has been proven broken and so it shouldn't be a crucial consideration for this move. Our organization understands reasoning for reduced cert validity period and welcome it. Realistically we're moving everything to automated certificates anyway which are 90 days max validity.
- This would be a huge impact. Please keep it at 825 days.
- Without a reduction in certificate issuance costs, this is more of a revenue generation question than a security question.
- The Internet and the web are not one and the same. Certificates protect more than the web. Not everything can be automated. Where is the proof that frequent certificate replacement significantly improves security?
From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> on behalf of Dean Coclin via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Reply-To: Dean Coclin <dean.coclin at digicert.com<mailto:dean.coclin at digicert.com>>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Date: Tuesday, August 20, 2019 at 2:37 PM
To: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>, "Tobias S. Josefowitz" <tobij at opera.com<mailto:tobij at opera.com>>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
I believe this is referring to a comment I made at a recent CA/B Forum meeting where I stated we were going to send out a survey to our “enterprise” customers. I believed this to be true at the time I said it, but I later found out that the survey went to all customers (i.e. enterprise, retail, partner, etc.) and not any specific target.
Dean
From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Monday, August 19, 2019 7:28 PM
To: Tobias S. Josefowitz <tobij at opera.com<mailto:tobij at opera.com>>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
On Mon, Aug 19, 2019 at 6:56 PM Tobias S. Josefowitz <tobij at opera.com<mailto:tobij at opera.com>> wrote:
In line with that, I doubt the referenced post would prime the
participants of said survey to much but their own, en masse not terribly
informed opinion.
It would go against my expectations if any such survey showed a nuanced
understanding of regulatory challenges present in the ecosystem.
Hi Tobi,
Just to take a few snippets here of your mail. I certainly didn't have very high expectations for the survey, based on the information previously shared, so I doubt my perspective on the results from the specific questions is that valuable here. That's why I was hoping to understand more about DigiCert's goals and objectives in sharing the results, which I think is far more important.
Part of the concern is that while DigiCert's post in this thread didn't acknowledge the selection method, DigiCert's past communications from not-yet-public calls made it clear that they were not after an objective selection, and were carefully curating the list of customers solicited for feedback. That is, while presented as "a customer survey" and "an overwhelming number of customers", it was in fact a limited sample of certain "high-value" customers, and thus at best "an overwhelming number of hand-selected customers who responded to the survey".
I wasn't sure if that remained the selection methodology, or if something more rigorous had been applied. However, given that DigiCert did not provide context as to what they saw the particular value of the survey to be, or its relevance to the discussion, it was also unclear how to interpret the results they did decide to share. Assuming a perfectly fair and balanced survey, it seemed useful to highlight how, even in a responsibly selected study, techniques such as priming can spoil the results, and might thus impair achieving those goals.
While I certainly understand that academic rigor is not the objective here, it's important to consider these facts when evaluating the results DigiCert shared. I also wanted to help DigiCert here; as they're laboriously working to summarize respondents' free-form text results, if the survey was spoiled, or if the desired objective was fundamentally unobtainable due to the selection method, perhaps it's not worth that effort and not worth further discussion? That surely would save time and energy, which could then be used for more productive engagement?
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg
--
Eric Mill
617-314-0966 | konklone.com<https://konklone.com/> | @konklone<https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190821/1c54b77f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3860 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190821/1c54b77f/attachment-0001.bin>
More information about the Servercert-wg
mailing list