<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ryan, to clarify, I was not referring to you when I summarized an early posting on this issue stating a preference for case-by-case decisions on allowing untrusted SHA-1 certs
instead of creating objective standards available to every applicant who qualified. I was referring to an early posting by Gerv (see below), so I have not mis-characterized anything you have said.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I disagree that the methods Dean has proposed for making the interim SHA-1 certs untrusted will not work. For example, issuing and immediately revoking will make the certs
untrusted. If some browsers no longer check certs for revocation, it is the decision to abandon revocation checking that creates any security vulnerability for users, not the cert itself – and that vulnerability exists today even for SHA-256 certs that have
been revoked for misissuance, misuse, etc. If the browsers are treating revoked certs as “good” when serving content to users, that’s a totally different security issue. Likewise, browsers can add these interim SHA-1 certs to their CRLsets list, and users
will be protected. If I understand correctly, the WorldPay case only involved 8 or 9 certs total, so this is not a great burden on the browsers.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I still don’t see how Forum members can evaluate any special pleading from an applicant who needs these interim certs – I assume in all cases applicants can’t update their
devices, so the devices will go dark if they can’t get an untrusted SHA-1 cert for the next 90 days, etc. What other information would you want?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Finally, this situation really illustrates that we should NEVER again create split dates for changes in requirements, where there is an early end date on issuance of some type
of cert, and a later “last validity” date. In this case, we should have made December 31, 2016 the “last validity” date only, and CAs should have been allowed to issue up to that date (even be able to issue a one-day cert on December 30, 2016). That will
get the attention of customers – when they apply on May 1 and are told they can only get an 8 month cert, customers will understand the deadline is real and approaching, and we won’t face the argument “I could have gotten a one-year cert on Dec. 31, but can’t
get any cert on Jan. 1 – that makes no sense.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] On Behalf Of Gervase Markham<br>
Sent: Thursday, March 10, 2016 9:08 AM<br>
To: Ryan Sleevi; Dean Coclin<br>
Cc: CABFPub<br>
Subject: Re: [cabfpub] SHA1 options for payment processors<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Mozilla agrees with Ryan that it is not acceptable for us to produce some generic solution such that CAs can go away and start re-issuing<o:p></o:p></p>
<p class="MsoPlainText">SHA-1 certs at will for their customers.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">We feel that any company coming forward to ask for an exception should request it on its own merits. And so in order to discuss this further, we need such a company to come forward (as WorldPay did) so the problem can be discussed in
concrete terms.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Gerv<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Monday, March 14, 2016 7:30 AM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] SHA1 options for payment processors<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><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>
><o:p></o:p></p>
<p>> 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). <o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>> 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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>> 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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>> 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. <o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>