<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 10:50 PM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just because you (and others) may have had an *<b>undisclosed</b>* expectation about something, and I (and others) had an opposite *<b>undisclosed</b>* expectation
 about the same thing relating to initial adoption of the BRs doesn’t make any of us liars.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In the future, if anyone thinks some new CA/Browser Forum requirement is meant to be retroactive (i.e., will apply to certificates already issued or to agreements
 made before the effective date of the new requirement) – please speak up, as that’s a big expectation to have, and many may oppose it.</span></p></div></div></blockquote><div><br></div><div>I think we need to be clear on this:</div>
<div><br></div><div>I can certainly understand and appreciate that when the BRs were adopted, there was NOT an assumption that all pre-BR certs would have to be revoked. There was no giant flag day.</div><div><br></div><div>
However, there has unquestionably been the expectation - from the root stores, from the audit guidelines, and from the BRs itself - that all certificates issued from the effective date must comply. This is, after all, why the effective dates are so typically set further in the future - to give CAs time to adequately prepare to implement the required measures.</div>
<div><br></div><div>The fundamental disagreement seems to be about which has higher priority: existing agreements or the audit compliance. If a CA has an existing agreement that says "We (the CA) agree not to conform to the BRs for Customer Foo", then you cannot simultaneously argue that the CA is in compliance with either the letter or the spirit of the BRs or of the root program requirements.</div>
<div><br></div><div>If this was an acceptable interpretation, it seems like it incentivizes every CA to put into their contracts language that runs counter to the BRs, as it provides a "get out of jail free" card for any non-compliant certificates. This would, in effect, make the BRs meaningless - a symbolic hollow gesture.</div>
<div><br></div><div>If we want to talk about undisclosed expectations, I would simply highlight that the BRs, unlike the EV guidelines, say nothing about re-key beyond 15.2.2.a. Absent any clarifications, and given the prevalence of terms like "issuance", which itself has a defined meaning, it seems unreasonable to think that rekey was or is exempt from this. If "rekey" was not an instance of "issuance", then surely it would mean that no CA was obligated to keep audit logs for any certificates they "rekeyed" - or if any (other) attributes were changed on the certificate. Naturally, I hope you can see why this interpretation is so fundamentally alarming, even if the current example certificates are less troubling.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I can say that the only explicit requirement included in the initial BRs about maximum validity period for certs is BR 9.4 – and by its terms, it clearly does
 not apply to certs issued or agreements made before the effective date of the BRs.</span></p></div></div></blockquote><div><br></div><div>I would hardly agree this point is clear, as stated above and previously. After all, this thread would hardly be as active it if was so clear and unambiguous.</div>
<div><br></div><div>Further, in your reply, you've now added an extra clause "or agreements", which itself is not present in the BRs. This indicates another fundamental disagreement here, and I hope to understand how you've reached this conclusion, so that we can make sure that the BRs (and the CA/B Forum Membership) are clear and in agreement on this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I can also say that in the future, Trend Micro is likely to oppose any new requirements that are explicitly intended to be retroactive and would require a CA
 to revoke outstanding certs and/or breach existing agreements with customers, unless there is an extraordinary, proven, and immediate security threat – and the issue currently under current discussion doesn’t meet that test.</span></p>
</div></div></blockquote><div><br></div><div>I would think that any CA that is not considering and incorporating, as part of their agreements, the implications that the Baseline Requirements will have on current and future certificate issuances may be acting in bad faith with respect to making forward progress here.</div>
<div><br></div><div>Suggesting that no improvements can be made that disrupt the status quo would be truly unfortunate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Eddy Nigg (StartCom Ltd.)<br>
<b>Sent:</b> Tuesday, August 06, 2013 2:51 PM<br>
<b>To:</b> <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a> >> <a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a></span></p><div class="im"><br>
<b>Subject:</b> Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><br></p><div><div class="h5">
On 08/07/2013 12:43 AM, From <a href="mailto:kirk_hall@trendmicro.com:" target="_blank">kirk_hall@trendmicro.com:</a>
<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Ryan and Eddy – if it was anyone’s intention to put CAs in the position of breach of contract with their existing customers for long-term certificates they had issued pre-BR
 (by effectively prohibiting them under the BRs from reissuing an existing long term cert for the balance of the cert validity period, as the CAs had agreed to do with their customers by contract), that was never made clear by anyone.</span><u></u><u></u></p>

<p class="MsoNormal"><br>
Well, as I mentioned earlier, if you are in this situation then fire your lawyers and whoever is responsible for setting up the policies and agreements. But there are other possible solutions to make a customer happy and still stay in compliance with the BR,
 I don't have to mention those here.<br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">If it had been made clear, I doubt many CAs would have supported that position.  We don’t think that’s a common-sense interpretation of the current BRs.</span><u></u><u></u></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
In my opinion it's the only logical interpretation and not only that, but we've discussed this extensively and the current BR was created by consensus being fully aware of the implications. Claiming otherwise would be a lie.<br>

<br>
<u></u><u></u></p>
<div>
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in">
<p class="MsoNormal">Regards <u></u><u></u></p>
</td>
</tr>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in">
<p class="MsoNormal"> <u></u><u></u></p>
</td>
</tr>
<tr>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal">Signer: <u></u><u></u></p>
</td>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal">Eddy Nigg, COO/CTO<u></u><u></u></p>
</td>
</tr>
<tr>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal"> <u></u><u></u></p>
</td>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal"><a href="http://www.startcom.org" target="_blank">StartCom Ltd.</a><u></u><u></u></p>
</td>
</tr>
<tr>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal">XMPP: <u></u><u></u></p>
</td>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal"><a>startcom@startcom.org</a><u></u><u></u></p>
</td>
</tr>
<tr>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal">Blog: <u></u><u></u></p>
</td>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal"><a href="http://blog.startcom.org" target="_blank">Join the Revolution!</a><u></u><u></u></p>
</td>
</tr>
<tr>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal">Twitter: <u></u><u></u></p>
</td>
<td style="padding:0in 0in 0in 0in">
<p class="MsoNormal"><a href="http://twitter.com/eddy_nigg" target="_blank">Follow Me</a><u></u><u></u></p>
</td>
</tr>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in">
<p class="MsoNormal"> <u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div>
</div>


<table><tbody><tr><td bgcolor="#ffffff"><font color="#000000"><pre><table><tbody><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></tbody></table></pre></font></td></tr></tbody></table><br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div></div>