<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 13, 2017 at 11:47 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    This is a very good description of the situation and the comparison
    of the security concerns between the Certificate issuing system
    (certificates signed by a CA) and the OCSP responder system
    (responses signed by either the CA or a delegated OCSP responder),
    is fair.<br>
    <br>
    Could we try to focus what should be expected for the off-line Root
    CAs and their delegated OCSP responders? Roots that delegate OCSP
    responses via OCSP responder Certificates and issue responses for 12
    months (per BRs 4.9.10), should probably have a minimum lifetime of
    12 months to match the validity of the OCSP response. Currently, the
    BRs are silent about how an OCSP responder should protect its key,
    so perhaps we could have similar (or the same) protection controls
    for Private Keys associated with OCSP Responder Certificates that
    are delegated from Roots, as the Private keys associated with the
    Root Certificates. <br>
    <br>
    Would it be reasonable to allow for 1-year OCSP responder
    Certificates if the Private Key associated with that responder
    certificate is treaded/protected similarly as the Root Private Keys?
    <br>
    <br>
    Of course, it would take a while before CAs adapt to such a change,
    especially for pre-generating OCSP responses and serving them to web
    clients through a separate layer.<br></div></blockquote><div><br></div><div>As I mentioned to Tim, it takes more than 'just' protecting the private key. You need a whole systemic architecture that ensures the flow of information (and thus the inverse flow of compromise) constantly flows down from the secure zone to the insecure zone.</div><div><br></div><div>Obviously, there's a lot of loopholes in the current text for all sorts of unquestionably insecure and unadvisable practices (of which some CAs are engaged in), but it's certainly trying to work through the security goal - which is that the 'worst case' for a revocation should be bounded by some O(days) [with the text proposing O(30) as the absolute upper bound], with leaf certificates bounded by less (currently specified by MSFT as O(7 days), although they tried for shorter) </div></div><br></div></div>