<p dir="ltr"><br>
On Mar 13, 2016 4:41 PM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
></p>
<p dir="ltr">> Dean has proposed a general procedure with objective criteria by which a CA may issue SHA-1 certs that expire by Dec. 31, 2016, and which is intended to ensure that these interim SHA-1 certs will NOT be trusted by any of the browsers (and which includes some fairly ingenious methods for ensuring they will not be trusted). </p>
<p dir="ltr">Regrettably, this is not true, which is why we are still having this conversation, although I appreciate that you find the browser-proposed alternatives to Dean's original request for blanket issuance ingenious. Every method Dean proposed, for example, does NOT ensure they will not be trusted - and as such, puts profound risk on the Internet at large.</p>
<p dir="ltr">If such risk is to be accepted, a meaningful discussion how to mitigate that risk is a prerequisite. It is simply brazenly unacceptable to suggest that the risk is equal for all participants, or that a one size fits all approach takes into consideration the needs of anyone but the CA and their customers. I appreciate your view that the risk is acceptable, but this is not a shared view.</p>
<p dir="ltr">> In fact, this creates greater user security than if the customers managed to purchase one year SHA-1 certs on Dec. 31, 2015, which they could have done, so already Dean’s proposal is an improvement on the existing security situation for SHA-1 certs.</p>
<p dir="ltr">This is so logically flawed and factually wrong that I am uncertain on how to respond. It would be truly disappointing if you believe that allowing new issuance of SHA-1 creates less or no risk than the alternatives.</p>
<p dir="ltr">> Dean’s draft criteria included some objective business and technical requirements similar to what we already have for BR 6.3.2, which carves out limited, objective  circumstances under which a CA can issue a 60-month DV or OV cert instead of limiting the cert to 39 months (basically, BR 6.3.2 requires the CA to confirm that the customer has a legacy app that will fail with a cert of less than 60 months validity period and where there is no known security risk to Relying Parties, etc.).   That is a very good approach to a situation like this.</p>
<p dir="ltr">I strongly disagree - which is why there is a ballot proceeding right now to remove it. To the best of my knowledge, only a single CA argued for this exception, and only a single CA used this exception, and that CA is the same one requesting more exceptions today. There may have been more, I admit, but that too highlights why such things are bad - because such general exceptions make it hard to balance or quantify the scope. Further, as you may be unaware from the debate and discussion regarding this ballot to remove that exception, because it was so broadly worded, there is no understanding about the scope or even need for it, in the general sense.</p>
<p dir="ltr">But most importantly, and seemingly, most obviously, both the exceptions (direct issuance from root and a long-lived cert) do not directly put the entire Internet at risk, nor does it create risk for all participants in the ecosystem. A long-lived cert affects only the named domain holder, and direct issuance from the root is an operational risk of bringing a root key online that is similarly mitgatable via appropriate procedures. These are both vastly different in scale and impact than the proposal before us.</p>
<p dir="ltr">> Early in this discussion, someone made a comment along the lines of “I don’t want to approve any general criteria for allowing these interim, untrusted SHA-1 certs, instead I want to approve such certs on a case-by-case basis for each and every applicant, who must make its case to me.”  I think that’s a really bad approach. </p>
<p dir="ltr">Well, if you are going to summarize me, you could at least have the courtesy to do it accurately. Luckily, as this debate is happening publicly, it is easy to point back to my past messages in the archive to demonstrate easily and obviously that this is not what I said, nor is your characterization accurate. Which is part of the point - this is a public debate being held about the need for a public debate, and when someone so clearly misconstrues an argument, it is easier to point to fact and what was actually said than to haggle over the recollection of what was said in a proverbially smoky room or private phone call.</p>
<p dir="ltr">Given the nature of your further remarks, I find it unlikely to provide further value to reiterate the points I made earlier on the value of both public debate (for the ecosystem AND for the Forum), other than to highlight that the argument is already laid out, and rather than refute it or address it, you've chosen to mischaracterize it. As such, I can't really respond - because you're no longer making a thoughtful argument to a nuanced debate, but seemingly a straw man that you can tear down.</p>
<p dir="ltr">If you do take the time to revisit the past responses, from me and others, you will see your questions have already been answered as to "Why?", and if you have trouble understanding them or you disagree, I think it's entirely reasonable to ask that you just say that. I'm sure I and others would be happy to explain to you further, and would be happy to address your criticisms on their merits.</p>