> On Feb 10, 2017, at 11:38 AM, Ryan Sleevi <[email protected]> wrote: > > On Fri, Feb 10, 2017 at 8:19 AM, [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> wrote: > > 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.
The only mention I made of the Mesh was when I gave a practical example of the site being down due to the botched automation at my Web Hosting provider. Since when is providing an example of an actual system failure abstract? > 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, So state the alternative reason concisely in reply. Instead you complain that I am failing to engage in arguments you think you have made but I do not see in your posts. > 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. If you refuse to state them, how can we do anything other than ignore what you won’t cite? You then posted two links in response, the first of which was arguing that shortening the lifecycle does not impose an additional administrative burden. Whether or not that is true, the post gave no argument for making the change. The second was about SHA-1 which was precisely covered by the second of my bullet points. So what are these other reasons that I am ignoring? > 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? No, I don’t think it has. Just more of this pointless meta-discussion. Arguing that the issue has already been argued is a classic tactic in agenda denial. You may think that you have made a different case but I am not seeing it. > 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. Again, you are the proposer of this change. It is for you to state your argument concisely and with precision. At least half of the thread so far has been on the revocation issue that you say isn’t the motivation for the change. > Which is cryptographic algorithm agility that you were trying to avoid > engaging on. > > Is that what you believe my response was? My second bullet point was 2) To enable changes to cryptographic algorithms or withdrawal of certain types of permitted algorithm class to take place more expeditiously. Since you were arguing that I had not addressed the point raised in your second link, it was sufficient to point out that I had in fact addressed cryptographic agility. But that was not the only type of agility that had been raised. > 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 be a lot more willing to accept that argument if you were doing hardfail OCSP. PKIX and the WebPKI were designed to use revocation. As it turned out the original validation process was sufficiently robust to almost eliminate revocation for cause for the first decade of operation which led some peopler to the belief they could simply remove it. And now experience of the second decade of WebPKI has turned out differently they will look at absolutely any other change they could make rather than revisit that decision. > 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. Well we agreed on that: "That said, even though the purpose of the proposal wasn’t revocation, the discussion of revocation highlights the fact that the lack of fully functioning hardfail revocation remains the major limitation in the WebPKI and we should fix that."
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
