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

Sat Feb 11 12:51:32 MST 2017

Hi,

I’m currently on holidays, so please excuse late responses.

It’s information security finally what we are talking about and information security is about risks and countermeasures. However, you state risks and you state countermeasures, but in the role of an information security auditor, I can’t follow your alignment of the countermeasure been able to control the risk.

Your countermeasure is about reducing the impact, although with revocation you have a much better countermeasure to reduce the impact, but why not reduce the probability of occurence by finding a countermeasure, which is more appropriate.

That first said,

> I think the misunderstanding is that I'm not saying it's OK for CAs to break the rules - it never is - but shorter validity times help reduce the time to enforce the rules. By enforcing the rules, any breaking of the rules
> 1) Is detected sooner
> 2) Doesn't have any advantage, because the software will reject it.

I still don’t understand how a lower validity period will help neither to detect rule breakings (how should a validity period do that?) nor enforcing rules will avoid rule breakings, so then more rules are broken than before, however, rules are still broken. It’s part of auditing (so I wonder, if WebTrust audits aren’t therefor to audit observance from a third party point of view) and if there are failures, they will result in revokes and revokes are no advantage, as the software rejects revokes as it should be.

> Under today's world, so long as you don't get caught and called out, CAs can find there are economic incentives to breaking the rules, as long as the software accepts it.

See above, don’t accept revocations. Audit observance. How do you want to enforce rules otherwise?

> Unfortunately, we all need to learn from our mistakes, and as CAs make mistakes with the validation rules, we need to adjust them to make sure we've taken steps to prevent them. That is, there's a class of mistakes that result from CAs intentionally violating the rules, but
> there's also a class of mistakes that result from CAs misunderstanding the rules. The second time can happen when things are unclear, or when the CA is not acting in the interest of the ecosystem, and thus "looking for loopholes" (much like you might find someone who is
> looking to reduce their taxes to take advantage of every possible loophole, since that's the most personally advantageous, even if it's not societally advantages)

Understand, but such adjustments again need time to be well implemented (which finally is the goal, isn’t it?) on CA side, expecting most CAs don’t do loophole picking but there are some things unclear. Looking through the BR, I was wondering, some chapters are really short, so there is still work to do. So maybe as suggested the 27 month timeframe is a good compromise here.

> Ah, I see. Unfortunately, this argument - that it's the CA's responsibility to revoke - only works if revocation works. But even then - in a world where revocation works - we still have many of the issues I've raised.
> The messages in https://cabforum.org/pipermail/public/2017-February/009471.html and https://cabforum.org/pipermail/public/2017-February/009475.html expand upon that.

The big problem is, that there are many different argumentation paths which conflict with eachother. Rolling out new algorithms should be a long hand planned thing, which is best timed within a 3 year timeframe. Reacting on security risks like anything broken, revocation is the correct answer, for sure with deadline. Breaking the rules, audited by auditors, found via tools which provide BR check with proven breakage also revocation is the correct answer. To realize continual improvement, find a timeframe, which can fit the improvements to be implemented, but also don’t slow down improvement. My suggestion here are 27 months, I also can’t believe, 13 months will work here (however, I still don’t understand 13 months, I expected 1 year + 3 months possible renewal overlap, so 15 months or 455 days).

> I think the misunderstanding for many of the points raised in the part that I snipped is that we don't have a way to determine what was "really" misissued and what was simply done with a less secure method. Well, we don't have any way short of relying on the CA. And the
> problem is this threat model is that, when a misissuance happens, we don't really trust the CA.

But you trust WebTrust and isn’t it their job to audit what has been done good and what hasn’t, find countermeasures, use such BR rule checking tools, ...?

> I think a good example of this - where the CA didn't understand or downplayed the scope of the issue - might be found with an event that happened two years ago. You can read Google's initial remarks https://security.googleblog.com/2015/09/improved-digital-certificate-  > security.html<https://security.googleblog.com/2015/09/improved-digital-certificate-%20%20%3e%20security.html> , but the more important part is with the follow-up, in https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
>
> And while that might seem like a one-off, it currently seems like we're already seeing a repeat of the issues with the same CA, as you can see in the following three messages:
> - https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ
> - https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ
> - https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ
>
> As you can see, when something 'bad' happens, relying on the CA to responsibly detect and disclose the issues is a challenge, especially when all the incentives of the ecosystem mean that there are benefits to be had if the CA hides or misrepresents misissued certificates,
> since then they can avoid revoking those certificates without warning or timeline, which then, as you note, will cause customers to change CAs.

Understand, but the correct answers followed up: Revocation, auditing, changing of internal structures, processes, ... CT log as an extra safeguard detected such mis-issuance, I don’t see anywhere here, why a shorter lifetime would have helped to prevent such issue, now or in future? Revocation without notice or deadline is a failure of the CA. If they are aware (or aren’t aware and got aware) of a mis-issuance and they fail to notice or giving a deadline to their customers, it’s their failure. So not loosing customers changing their CA, warnings or deadlines are their job and if they don’t do the job, it’s not depending on the revocation, it’s depending on communication failures.

> Sure. But to be clear and repeat: This ballot is only about making certificate updates more frequent, so that regardless of the change - new algorithms that take a long time to phase in, or smaller security improvements that can be done in months - consistently take effect
> within 13 months of their actual effective date.

It wasn’t clear to me and I also don’t believe to others. There’s also still confusion on „replacing“ revocation with shorter lifetimes. There’s also confusion in discussions on lifetimes of months or weeks, which makes absolutely no sense for implementing improvements faster, as such fast no improvement adjustment can be made to any CA infrastructure. As stated above, I now understand a faster improvement cycle than 39 months is something, which is worth thinking about. However, it still should be realistic, Ballots can result in small but also bigger changes. They can result in changes, not only CAs need to fullfil (and as stated should do correct) but maybe there are also jobs to be done by SubCA customers, private CA operators etc. (if e.g. browsers check for such changes been rolled out). So I suggest a compromise of 27 months resulting of 2 years + 3 months. Algorithm changes may be stated also to be only in 39 month rotations.

> I'm not saying we're going to change everything every year. Just that a year is the longest reasonable time to go without 'patching' a bug or being able to make sure it's fixed.

So I say again: a bug should be patched by revocation, a bug is a bug and e.g. in Scrum must be solved same day. An improvement could and should be rolled out in 27 months.

> You've misunderstood the point of this ballot then. It doesn't mean everything will be phased out in a year or less. It simply means that browsers can begin enforcing those changes - whatever they are - within a year of them being required. In the time between "when it's
> required" and "when it's enforced", the only protection you have is assuming that no CA, anywhere, that's trusted, will make a mistake. And that's a big risk - too big for the ecosystem - since mistakes happen, especially the more CAs you have, and doubly so when there
> are economic incentives to intentionally "make mistakes" if you can make money from it.

Exactly the „whatever they are“ bothers me, as there are changes, which can’t be done in 1 year, but it opens the possibility to bring such a pressure (finally also damaging the ecosystem, if enterprises fail to gain). Depending on the changes, which need to be enforced, other methods may be better. I’m no fan of potential risk just for potential changes. However, for improvement purposes, I would vote for 27 months as stated before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170211/d3fae41a/attachment-0001.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://cabforum.org/pipermail/public/attachments/20170211/d3fae41a/attachment-0001.bin>