<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 12:50 PM, Adam Langley <span dir="ltr"><<a href="mailto:agl@chromium.org" target="_blank">agl@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Feb 4, 2014 at 3:37 PM, Jeremy Rowley<br>
<<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> Doesn't that simply require the cert user to either start using OCSP with an<br>
> embedded certificate or getting a new certificate from the user?<br>
<br>
</div>If the certificate was used with OCSP stapling, the CA had a<br>
reasonably short OCSP validity window and the CA could update the SCT<br>
in the OCSP response quickly then that would solve the problem.<br>
<br>
However, for the purposes of this spec I don't think we said anything<br>
about that because of the complexity. Having multiple SCTs is clearly<br>
ok and that kept things simple.<br>
<div class="im"><br>
> Plus, under the current plan, the site doesn't go dark. Instead, their EV cert isn't recognized as an EV certificate.<br>
<br>
</div>For EV certificates the problem is greatly reduced. But EV<br>
certificates are just a trial for doing it universally and we have the<br>
end state in mind.</blockquote><div><br></div><div>Also, EV has the added benefit of recommending/requiring (depending on which doc) fresh revocation checks. As such, CAs that feel that multiple logs are too onerous can benefit from the OCSP delivery method. Failing to obtain fresh revocation information can already cause a loss of EV UI, so including an SCT should be a much less onerous cross to bear.</div>
<div><br></div><div>It also allows for issuance patterns other than pre-certs.</div><div><br></div><div>Of course, it means that any sites purchasing certificates from such a CA support OCSP stapling. </div></div></div></div>