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

Ryan Sleevi sleevi at google.com
Fri Feb 10 16:38:13 UTC 2017

On Fri, Feb 10, 2017 at 8:19 AM, philliph at comodo.com <philliph at comodo.com>
> > Unfortunately, the flaw in your argument starts here, and unfortunately
> invalidates the rest of it.
> I really don’t think you help your case with that type of talk.

Similarly, I'm not sure how abstract talk about the mathematical mesh
really helps identify or resolve the problems we've identified.

> I have read the threads and I find that each time someone tries to pin you
> down on an argument you skate away and claim that you were actually arguing
> something different.

No - I'm highlighting that your approach to trying to present it as
"There's only these two reasons" is flawed, and so any conclusion that
tries to look at only a subset of the arguments is understandably going to
have the possibility of reaching a different conclusion, but is also
flawed, because it's ignoring a large number of other arguments.

If it helps by analogy to help you understand this point, it's a bit like
discussing a math problem in the form of "(2x + 3y + 4z + 7a)/13b = 400".
The goal is to "Solve for X", but as you can see, there's a complex set of
variables here. My arguments to date have been of the form that "We know
(from outside data) that y is 13, z is 23, a is 15, and b is unknown, but
we want it less to be 40" - and thus advancing the argument that x is
bounded by the goal of keeping b < 40.

Your argument here seems to be that "We can ignore y, z, a, and b if we
treat the problem as simply 2x = 400, thereby x = 200, thereby whatever
value you propose X is, is wrong". That is, you're ignoring the other
variables' value entirely, and trying to simply ignore them being present
in the equation.

I can understand why you believe your solution is right - and indeed, if it
were that simple, it might very well be. But unfortunately, your
understanding of the problem is wrong, and thus the solution you advance is
for a different problem.

This is not being cagey - this is reiterating to you that we cannot ignore
y, z, a or b.

> Arguing that the point has been answered elsewhere seems to be the only
> mode of argument you wish to engage in.

Well, when you insist on ignoring the fact that the point has been
repeatedly addressed, what else is there? By trying to understand where the
previous remarks have left you confused or unsatisfied, we can perhaps
reach a common understanding. However, by simply presenting strawman
arguments - which are not the ones being advanced - so that you can
demolish them, we aren't able to actually move forward.

Which is cryptographic algorithm agility that you were trying to avoid
> engaging on.

Is that what you believe my response was? If so, how can I better
communicate to you that my point was not that cryptographic algorithm
agility was not important, but that it was not one of only two factors to
argue for this case. Indeed, by examining the many _other_ cases where
agility benefits us, independent of algorithm agility, you might hopefully
realize that the problem is not _just_ algorithm agility, nor is it
_primarily_ algorithm agility, but the systemic issues involved in any
meaningful transition of any insecure practice - whether it be algorithm,
domain validation, information vetting - or to the systematic introduction
of any improvements - such as CAA, CT, EKUs, or normalized OIDs.

I would think you, of all people, would be sensitive and appreciative to
this argument, given your previous lament about the IETF rejecting your
multi-signature solution. Consider how the ecosystem might look if it had
been accepted, but the practice was such that certificates were valid for
10 years or more (as they were at the time you introduced the proposal). In
this model, relying parties and browsers would not be able to _require_
multi-signature until the non-multi-signature certificates had expired. Or,
alternatively, when the ecosystem needed to phase out SHA-1, it would still
be forced to break all SHA-1 signed, non-multi-signature certificates -
which, again, depending on timelines, could be a significant amount.

My point is that your solution, if it can be called that, only works
because it's solving a different problem, by only constraining itself to
one small part of the problem, and ignoring the systemic and symptomatic
issues of the overall whole. I am not trying to tell you your answer is
wrong for the problem you're setting out to solve, I'm telling you that
you're solving a different problem, and due to it being only a subset of
the overall issue, the wrong problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/6c3e3fe8/attachment-0003.html>

More information about the Public mailing list