[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

Fri Feb 10 18:25:51 UTC 2017

> However, as the Forum discusses changes to domain validation (Ballot 169/181/182 and the subsequent activities of the PAG), as it discusses CAA, as the Forum evaluates precision around the scope of the Baseline Requirements, these are all presently things which
> Relying Parties and Subscribers - such as yourself - cannot currently expect to take place sooner than 39 months.

I don’t believe, such changes need to wait 39 months. Why not introduce them to new certs from date x?

> Put differently, imagine that the validation practices presently practiced by CAs are insecure (which, by the way, they unfortunately are). As a customer, don't you feel better assured that you can have consistent protection within a years time, as opposed to knowing that
> browsers and relying parties will continue to accept 'bad' certificates for years?

As a customer, I currently already feel worser with what has been rolled out in the past by browsers and CAs. I usually look inside certificates before giving details to any site. It’s a pain currently need to open web development panel (recently I was forwarded there, now I need to do manually in Chrome) to see, if the site is the one, it claims to be, if there is no EV and sadly there are still less EVs out there. For OV and DV there is no difference and DV finally says nothing than the site is encrypted. So if validation practice for DV was bad, it already got worser, accepting phishing and scamming as being not the role of certificates. As long as browsers claim, I’m safe to enter details to such sites, I don’t see the problem in validation practices, I see the problems in the missing distinction of encryption and identification.

> If the answer is "The CAs should revoke those certificates," then again, as a customer, are you prepared for the possibility that your CA may suddenly make your site or server stop working - potentially even with no notification (again, as we've seen some CAs do)?

If the CA doesn’t give me a deadline to replace because of bad validation, it’s the longest time, I was with this CA.

> In many ways, as a customer, this reduction helps protect you and your users. It does so by ensuring that if any practice is deemed to be insecure - whether it's something like an algorithm (which has a whole host of ecosystem dependencies) or something like how the CA
> validates a certificate request for your domain (which I'm sure you would only want them to issue to you, and not a malicious attacker) - the damage is limited to, at worst, a year.

If any practice is insecure, revoke, that’s one of the reasons for revocation. Why wait one year or is the final proposement certificates for hours or minutes, revoke and it’s done.

> However, you can only be assured that when Relying Party software (browsers and libraries) actually enforce whatever the 'new' requirements are, making sure they reject anything that uses the 'insecure' thing. However, browsers and software can only enforce when the
> 'old' certificates are expired. This is why it allows for a more rapid rotation.

The Online Certificate Status Protocol (OCSP) is an Internet protocol<https://en.wikipedia.org/wiki/Internet_protocol> used for obtaining the revocation status of an X.509<https://en.wikipedia.org/wiki/X.509> digital certificate<https://en.wikipedia.org/wiki/Digital_certificate>. ?! It’s the way to reject anything insecure by demanding revocation, when status can be checked via OCSP. If you disalike OCSP, you want to have CT logs for all certs in future. Then set the status in the CT log and check against that?

> The 'cost' to you, as a customer, is that you have to replace your certificate once every 13 months, rather than once every 39 months. However, hopefully you can see how that small cost - easily human maintainable - comes with significantly more assurance that bad
> practices will be stopped.

The cost is a potential risk, this replacement may introduce infrastructural changes which can’t be handled in 13 months. As you want to lower to 13 months in just a few months, I don’t believe, that such changes will really be encountered to decide a new algorithm rollout could take more than 13 months. As from an information security perspective, I would decline such a change introducing such a potential risk.

> If it would help, if you'd like to share which CA or CAs you use, I'd be happy to go through and find practices or issues that the CA has, which you may not be aware of, and that would show why you and your customers are at risk from their negligence or lack of care.

I was at a SSL meeting, where I was wondering just a few CAs joined and I also did not saw any browser representative, showing BR violations of the CAs. However, they offer a service for the CAs to get informed and revoke the certificates and correct their failures. That’s what should be required and doesn’t need a reduction of certificate lifetime.

> On this point, we must respectfully disagree. Across the spectrum of Internet security - whether through the IETF, through the practices software vendors practice (Apple, Microsoft, Google, Mozilla, among just a few), or through what you see through modern web
> development - there's universal agreement that regular security updates is a necessary thing. This is why 'native' software is released regularly, on the order of days (websites), weeks (applications in the Android and Apple App Stores), or even within months (modern
> browsers). The lack of such routine and modern updates is also why we have such Internet-crippling issues like Mirai ( https://en.wikipedia.org/wiki/Mirai_(malware) )

Updates are okay, but managed patch management (see ISO 27001 clause A.12.6.1 and best practice A.12.6.1 in ISO 27002). Mirai is a lack of awareness of users (no passwords, no updates at all), which is a problem of the consumer world, we talk about automation for enterprises or minimum users, which are able to run web, ... servers and may harm end users security while browsing the web and no noob installing a home router or camera without knowing anything about what he is doing there. For this ones, autoupdate may be a solution, however awareness is better.

> While I am unlikely to convince you that automation is the right answer, despite the industry widely moving towards that and recognizing it as a global "health" crisis, I do want to highlight that the opinion you're advocating is not one that is widely shared within the
> industry.

Depending on the target group I agree or disagree. Automatism, especially necessary required one, isn’t the solution for everything, enabled automatism for the consumer world may help, for the business world, best practices are different and if you look at issues like https://www.wordfence.com/blog/2016/11/hacking-27-web-via-wordpress-auto-update/ proof, that automatism isn’t the solution for everyone and everything as it may bring new risks, an enterprise would prefer to manage by themselves.

PSW Secure Mail Gateway Info - http://www.psw.net/

- The message was not encrypted and not digitally signed

PSW Secure Mail Gateway Info - http://www.psw.net/

- The message was not encrypted and not digitally signed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/2abb20d5/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3400 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/2abb20d5/attachment-0003.bin>