<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 10:14 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" class="cremed">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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think Eddy, Rich, and Rick all are on the right track. Take the simplest case – a CA issues a short lived cert, and within an hour realizes it’s been punked
by an imposter. What to do next – no ability to revoke? Just say, “oh well, it will all be over in a week.” Contact every browser and application in the world and say “Will you issue a patch to un-trust this bad cert I just issued with no ability to revoke?”
(Sounds a little like Diginotar… no ability to revoke.)</span></p></div></div></blockquote><div><br></div><div style>Kirk,</div><div style><br></div><div style>If the CA has issued a valid, signed OCSP response, then they have no ability to revoke that certificate for any client that supports stapling, until that OCSP response expires.</div>
<div style><br></div><div style>That's the reality of today's deployed market and the Web PKI. As such, short lived certs do not change the threats here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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">We as an industry should not let the perfect be the enemy of the very, very good. With revocation checking in place for *<b>every</b>* cert, a bad short-lived
cert that is revoked should return a negative response (“revoked”) for very many users – maybe not everyone, but many. </span></p></div></div></blockquote><div><br></div><div style>As explained by several others, the "very many" is an intentionally shrinking number, as more and more relying parties support techniques like OCSP stapling.</div>
<div style><br></div><div style>This is a GOOD thing - as OCSP stapling can improve performance AND the reliability of revocation information - and this makes SSL a better, more secure solution.</div><div style><br></div>
<div style>The only way to address the "revocation issue", as you present it, would be to encourage clients NOT to support OCSP stapling. And that would be an enemy of the quite good indeed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That’s a good thing. In my mind, it is not responsible for CAs and browsers to say “If we can’t convey a message of “revoked” to 100% of
users during the 7 or 10 day validity period of the short-lived cert, it’s not work conveying that message to *<b>any</b>* user.”
<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">Caching, stapling, failure of browsers to bother checking for revocation, etc. etc. should not change this, in my opinion. </span></p>
</div></div></blockquote><div><br></div><div style>Well, despite opinions to the contrary, the facts and deployment is that it does. Which is the point :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> If a CA is to be trusted by the
world in issuing a cert (short or long lived) that is deemed “good” to the world because the CA’s roots are in the browser or application, I believe the CA has a duty to be alert and diligent at all times, and to revoke that cert for a problem, even if it
only has 7 or 10 days to go until expiration. If others don’t want to check for revocation, that’s their decision, but we CAs shouldn’t enable that kind of practice by turning off revocation. (And shortening the next update time to 24-48 hours is a great
idea – let’s do it.)</span></p></div></div></blockquote><div><br></div><div style>CAs enable this practice today, by providing OCSP responses.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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">Finally, I’m guessing that any short lived cert issuance process is going to be totally automatic – machine to machine from CA to customer – repeated constantly
unless turned off – without human intervention unless something goes wrong. I don’t trust automatic processes like that – how will the new short lived certs get through the customer’s firewalls to be installed, and how will the customer be sure the new cert
is automatically installed correctly on the right servers – so I see potential new vectors for attack (or simple screw up).</span></p></div></div></blockquote><div><br></div><div style>While understandable that there are technical complexities, the CA/Browser Forum should not attempt to prevent new markets or new techniques that can improve security - especially when they are demonstrably no worse than the existing security guarantees provided to relying parties by forum members.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:public-bounces@cabforum.org" target="_blank" class="cremed">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank" class="cremed">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Rick Andrews<br>
<b>Sent:</b> Friday, March 22, 2013 6:00 PM<br>
<b>To:</b> Ryan Sleevi<br>
<b>Cc:</b> CABFPub</span></p><div class="im"><br>
<b>Subject:</b> Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal<u></u><u></u></div><p></p>
</div>
</div><div class="im">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m not sure I’m following you, Ryan. Are you saying that short-lived certs don’t need an AIA pointer as long as the OCSP response is stapled? I buy that, but
what happens when the stapled response has expired or can’t be cryptographically validated or doesn’t get returned at all? If the client hard-blocks, I buy that too. But I doubt browsers would do that, and I’d prefer that there was a fallback method. That’s
why I’d like to see AIA extensions even in short lived certs.<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">My logic was this: I see a 2-year cert that was issued one day ago; the CA must have thought it was valid or it wouldn’t have issued it; the CA very likely
also issued an OCSP response that says the cert is good for the first 7 days; even without fetching the OCSP response I can conclude that even if I fetched one or got one via stapling, it would say that the cert was valid. Since I already know the answer,
I don’t have to ask the question.<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">Orthogonal idea: If CAs feel they want to experiment with short-lived certs and they must be signed under public roots, would it make sense to spin up new roots
just for that, perhaps with a meta-data bit that browsers would use to expect that only such roots would sign short-lived certs?<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">-Rick
<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 style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank" class="cremed">sleevi@google.com</a>]
<br>
<b>Sent:</b> Friday, March 22, 2013 5:44 PM<br>
<b>To:</b> Rick Andrews<br>
<b>Cc:</b> <a href="mailto:ben@digicert.com" target="_blank" class="cremed">ben@digicert.com</a>; CABFPub<br>
<b>Subject:</b> Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Mar 22, 2013 at 5:38 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com" target="_blank" class="cremed">Rick_Andrews@symantec.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m very much in agreement with Eddy on this.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Consider this: If I take the basic argument that you don’t need to check revocation on a short lived
cert (say, valid for 7 days) because the CA’s OCSP responses are also good for 7 days, then I would claim that when SSL clients (browsers) see a long-lived SSL certificate, they can skip revocation checking if the cert is less than 7 days old. I certainly
wouldn’t want browsers to do that.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Rick</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm not sure I follow your logic, Rick.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If the browser has obtained a valid OCSP response (eg: via OCSP stapling), they can skip obtaining fresh revocation information - because to every compliant implementation, it IS fresh revocation information.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If there's NO revocation information, I don't think the same argument applies.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The point of the discussion here is not about what the exact behaviour is - but what the effective security is. And in the case of short-lived certs, the effective security is identical.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It's certainly reasonable to discuss whether the effective security is IDEAL, but that's a separate discussion than the one we're having - which is establishing whether or not the effective security of a short-lived cert is the same effective
security as providing revocation information.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</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>
</blockquote></div><br></div></div>