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

[Ryan Sleevi]

On Fri, Feb 10, 2017 at 11:51 AM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> Building consensus in meetings is different than building consensus for a
> ballot. Discussions happen in meetings without concrete proposals, as was
> shown in the chart I posted earlier from the Zurich meeting. I can’t recall
> anyone coming out before this ballot seeking consensus for a 1 year
> validity effective in 4 months.  So yes, I do think that now that a formal
> proposal (ballot) has been issued, a serious attempt to build consensus
> should be undertaken. This will likely take more than 2 weeks of online
> back and forth. We have a F2F coming up in 40 days, giving folks time to
> reach out and get more input.  I do believe that everyone wants to improve
> security but as the scattering of input shows, this must be balanced with
> the user constituency needs which really haven’t been fully vetted for THIS
> particular proposal. You’re right, I’m not saying we can reach consensus on
> this ballot but perhaps an alternative compromise can be reached which
> balances the needs of all constituencies.
>
>
>
> Regarding the motive, all I’m saying is that there is no consensus,
> therefore, it seems a ballot failure is a foregone conclusion and you must
> know that, but you want it to go forward anyway.  Call me crazy?
>

We had a number of concrete proposals. It was clear there was no consensus
that any one of them would work for everyone, that part was clear.

However, we also know it doesn't have to work for everyone, it has to work
for enough of them. And as we discussed - and discussed and discussed -
regarding the ways in which to structure Ballot 183 - we also know that
unless and until faced with a binding vote, it can be incredibly difficult
to measure consensus and process.

So I put forward a ballot that represents the absolute maximum acceptable
validity period we're willing to consider at this time, given the three
years of information that CAs have shared, the concerns raised, and the
challenges that have arisen in the ecosystem in that time. If CAs have
information that they haven't shared, despite knowing this was an important
matter of concern - and despite the practical evidence of this - well,
that's unfortunate for those CAs' customers that their CA does not consult
with them or represent their views in an actionable way.

Further, since it's quite clear - again, from our three years of meetings -
that no proposal so far, short of _extending_ validity periods (which is
outright unacceptable) - had the necessary consensus for success, there's
also value in understanding how other Root Stores / Application Software
Suppliers feel about the security risks of CA practices.

I think it's important to realize that the "Baseline Requirements" is
simply the minimum set of common standards. It does not, in any way,
represent industry consensus on *best* practice, merely consensus on
*minimum* practice.

It's possible that this ASS is the only ASS that feels that, when faced
with ecosystem challenges, such as multi-year misissuance issues
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ
( based on current information, absent a reply to
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ
), that an acceptable way to minimize risk to our users is to reduce
validity periods.
It may be that this ASS is the only ASS that is concerned that 39 months to
fix issues like
https://groups.google.com/d/msg/mozilla.dev.security.policy/zsBB_XqdOCg/CZCQnnOcDAAJ
is too long.
It may be that this ASS is the only ASS concerned that more CAs than one
may have issues similar to
https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ
, and that, given the possibility of future issues like that, we should
strive to limit validity so that we can reduce the risk in the period from
detection to remediation.
It might be that this ASS is the only ASS who is deeply concerned about the
reliability of CAs to detect and respond to misissuance, given issues like
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
It might be that this ASS is the only ASS who is deeply concerned about the
ecosystem and the impact to relying parties when steps such as
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
are necessary, and how to minimize disruption to as many parties as
possible.

Perhaps that's because other Root Stores / Browsers have different concerns
than this ASS. And if so, it's good to know.

However, as the Forum affords a public and transparent venue to judge the
reaction and consensus among Browser vendors, and as we know, Ballots are
the effective way to get opinions on the record, particularly when
potentially binding, it helps to measure the zietgeist in a way far more
effectively. It also effectively avoids the many troublesome issues that
CAs have no doubt considered before forming the "CA Security Council," and
which hopefully they're paying close attention to avoiding.

By having this discussion - with a concrete ballot - we can effectively
measure consensus, and know whether CAs are committed to security. We can
understand if ASSes are being unreasonable, by encouraging CAs to
concretely articulate objections that can be responded to or addressed,
rather than vague statements or empirically flawed surveys. And we can
better understand what impact, if any, would happen if ASSes needed to
expressly limit the validity period of certificates via root policy, if
consensus cannot be reached.

But I do want to emphasize again and again - the Baseline Requirements
represent just that - the baseline, not the best practice. As we ASSes
consider how to best protect our users, it's important to realize we strive
to do more than the bare minimum for protecting our users.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/f764b116/attachment-0003.html>