<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 9:32 AM, Eddy Nigg <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<div>On 06/11/2015 07:02 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Sorry, that reply was meant to be towards browsers
checking daily.
</p>
</blockquote>
<br></span>
Yes of course, I explicitly mentioned in my original response that
any cached data will remained cached for whatever time the CA sets
in the OCSP response. <br></div></blockquote><div><br></div><div>We're not talking about caching, we're talking about stapling.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
But any new connection checking an updated OCSP response would of
course take affect from the time of revocation by the CA. </div></blockquote><div><br></div><div>If they ignored stapling. Which they don't.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">There is a
difference, certainly if we are talking about the max. time of 10
days (which is commercially interesting enough for an attacker I
guess -, and probably the reason why some/most browsers cache the
OCSP response for only 24 hours).</div></blockquote><div><br></div><div>Again, I'd appreciate if you could name names, because this is not true for implementations that I've seen.<br></div><div><br></div><div>That is, your opposition is on the basis of some behaviour of some unnamed clients that you presume was made for security reasons (as opposed to being a side-effect or bug of the vendors, and thus subject to change at any time). You're arguing that these clients are thus more secure (with OCSP) than they are with short-lived certificates, and it would help to understand how this claim is formed.</div><div><br></div><div>It's not strictly necessary - certainly, you could oppose the change simply to oppose it. But I think it'd help to understand and appreciate if you could point to these behaviours and they could be examined to see if the claims are correct.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
</span></div>
</blockquote></div><br></div></div>