<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos <<a href="mailto:jimmy@it.auth.gr">jimmy@it.auth.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="m_8101259580698175376moz-cite-prefix">On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:</div><blockquote type="cite">
      
      <div dir="ltr"><div class="gmail_quote">
          <div>I do not believe there is any justifiable or defensible
            reason to extend the 5 days requirement, nor do I believe
            the CA should be expected to have a 'clean' audit should
            they chose to do so.</div>
          <div><br>
          </div>
          <div>CAs facing challenges of their own creation should not be
            exploring "How do I keep these certs working", but "How do I
            make sure I don't issue violating certs to begin with".
            Anything less is gross negligence, and not the system we
            should be striving to build. </div>
        </div>
      </div>
    </blockquote>
    <br>
    Ryan, it's fine we disagree, however allow me to clarify one more
    thing. I had a very different picture for the CA that got this case.
    It was not "How do I keep these certs working" but "How do I balance
    the need for RPs to access a service ("Availability" in terms of
    C-I-A), which is also a pressing matter for Subscribers, and "the
    requirement to revoke the certificate in 24 hours or 5 days".<br></div></blockquote><div><br></div><div>I disagree that this is the correct prioritization. A bad CA should not be prioritizing availability - that sort of perverse incentive structure is one that several now-distrusted CAs have argued, precisely because it sets the wrong expectations. We've seen CAs unsuccessfully argue that even though they didn't validate the domain properly, or could not demonstrate that validation, it's still more important to availability.</div><div><br></div><div>This is no different than if your website is made inaccessible because your hosting provider failed to pay their power bill. I can understand it's inconvenient to lack availability, but your service provider is the one that failed, and they don't get to steal power in order to optimize your availability.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    The CA will still get an "unclean" report anyway because of the
    RFC5280 violation or the mis-issuance per se, we are not debating
    that. I am only pointing out the requirement to revoke within 24
    hours or 5 days. Does this make it clearer?<br></div></blockquote><div><br></div><div>You are, though, because that's not accurate to suggest the CA is guaranteed to get a modified opinion / qualified report. If the BRs endorse this, as you propose, then it's no longer a BR violation. If the information was, say, inaccurate (the domain ownership was lost due to court order), but the CA determined to optimize for availability, then the CA isn't in violation of the BRs or RFC 5280 if they decide not to revoke.</div><div><br></div><div>There is no safe way to do what you ask, nor is it reasonable to do what you ask. For a system built on trust, it requires trust in the competencies of CAs. The reality of SSL/TLS is that the cost for mistakes is externalized on the ecosystem - on to Subscribers, Relying Parties, and Application Providers - while the profits from those mistakes are centralized with the CA. That's a fundamentally imbalanced system, yet the reality we live it, but that doesn't mean we should further seek to exacerbate those imbalances.</div></div></div>