<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>