[cabfpub] Ballot 185 - Next steps
jimmy at it.auth.gr
Fri Feb 24 09:35:15 UTC 2017
On 24/2/2017 9:59 πμ, Ryan Sleevi wrote:
> On Thu, Feb 23, 2017 at 10:41 PM, Dimitris Zacharopoulos
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
> As for the feedback, I didn't see any attempts from the CA/B Forum
> to organize something specific about this topic in order to get
> more feedback. Yes, we've been discussing it for three years but
> nobody did anything about it. I understand that each CA could
> create a questionnaire and send it to its customers, and browsers
> could have a public polls, etc. However, as we all know in such
> surveys, the way questions are formulated might "lead" people to
> specific answers. Even if that was the case, and CAs/Browsers had
> independent surveys, it would be very hard to compare the results.
> This is why we proposed agreeing on a "CA/B Forum questionnaire",
> roll it out in -say- a month, wait 2 months (or even less) for
> feedback and evaluate the results. Is anyone opposed to this?
> 1) Who do you see sending this to? It sounds like you think only site
> operators, but that clearly has problematic biases.
Easy. CA's would send it to their Subscribers and Browsers to the
Relying Parties (basically, using any publicity tool/method they see best).
Having the same questionnaire for everyone, mitigates/limits the bias
issue. CAs, Browsers and Interested parties should participate
(constructively) to produce a fair and balanced questionnaire.
> 2) How do you collect the results? If it goes through any member, they
> can easily skew results?
Each member that decides to participate, will bring in the results to
the forum (through the public list I suppose). As for the second
question, we need to start from somewhere. If we can't trust each other
to provide un-skewed and honest results to a simple survey, then I think
we have more serious problems to address than the validity time of
> 3) How do you correct for methodological biases?
Each participant involved in the construction of the survey, hopefully
understands the issues at stake and impact to the ecosystem. Consider it
a test to see if members can reach an agreement to a very subjective
topic, unless you already believe that such an agreement can't be
achieved. Let's start and see. I wholeheartedly agree with your
arguments that we need practical examples and not use hypothetical
outcomes to block progress.
> These aren't easy questions. Running a meaningful survey is not
> something that takes a month, especially not at the speed of the
> Forum. Consider validation methods took _two years_ to find consensus
> on what are all common sense improvements - because it's hard to get
> the wording right.
IMHO these are two very different topics to compare. Proper validation
methods are a cornerstone to the BRs and achieving the proper wording
was a huge challenge because there were many unknown factors to address.
In the certificate validity topic, we already know -as a forum- that we
must answer to the following questions:
* what validity date should be in the BRs
* what is the phase-in period for the new validity date to be enforced
> So thank for you clarifying the position on 27 months. I hope Peter's
> restating of my point explains the position and why 13 months is
> really not something we can go beyond. I understand why as a CA you
> may not see it as more secure, but as a browser, it's critical for our
> security and the security of our users.
I believe this is not exactly our view, nobody is arguing that 13 months
is not more secure than 39 or 27 months. We have the same concerns about
security as you do. In my statement, I just added the "cost" factor
because more security comes with a "price". Each member could provide
recommendations for better security (use HSMs or FIPS devices for
end-entity private keys, renew certificates every week, validate every
domain every month and so on) but these recommendations come with a
disproportionately high cost compared to the security benefit. If we
can't balance the security benefits with associated cost (and again, I'm
not only talking about money), we'll be moving away from defining and
implementing usable/practical security.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public