<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 3, 2018 at 1:48 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_-6346194225499355923moz-cite-prefix">On 24/8/2018 4:10 μμ, Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Fri, Aug 24, 2018 at 1:42 AM Dimitris
            Zacharopoulos via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not
            sure if this has been discussed before (sorry if I missed
            did),<br>
            but I would like to bring up the fact that there might be
            Subscribers<br>
            who suffer a Key Compromise (like the ones distributed with
            their own<br>
            software or embedded within customer devices), who would be
            willing to<br>
            leave the compromised Certificate/Key out there until they
            find a way to<br>
            replace it (that might take more than 24 hours or 5 days).
            This is a<br>
            case where the Subscriber weighs the impact of Availability
            in the<br>
            security properties of the offered service more than
            Confidentiality.<br>
          </blockquote>
          <div><br>
          </div>
          <div>I don't agree that the Subscriber's wishes should trump
            the Relying Parties. Otherwise, we never would have
            deprecated SHA-1 or RSA-1024.</div>
        </div>
      </div>
    </blockquote>
    <br>
    I agree that for cases where the risk of compromise is high (like
    the SHA-1 or RSA-1024 deprecation) and the impact to the ecosystem
    equally high, there should be firm requirements that mitigate this
    risk. However, cases such as [1] about improper encoding of IP
    Addresses as dNSName type in SAN extension, which is properly
    validated information but clearly non-conformant to the
    requirements, that IMHO seems to have a lower risk to the ecosystem
    and impact to the Relying Parties. The impact of the Relying Parties
    losing access to these services seems greater if the CA were to
    revoke the Certificate within 24 hours (or even after 5 days,
    because the Subscriber is not able to update their system sooner
    than 5 days).<br></div></blockquote><div><br></div><div>I disagree.</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 only reason I am following-up on this is because there will
    certainly be CAs in the future that will be tempted to violate the
    5-day rule if they come across a dilemma like the one SHECA is
    facing. The public would benefit from a disclosure requirement for
    revocation cases where the revocation time must extended the 5 days
    requirement. CAs will have no excuse if they do not revoke
    mis-issued certificates within the 5-day rule and not use the
    disclosure provision to extend the 5-day rule and share the
    particular revocation case with the public. IMO, it is better for
    CAs to share pro-actively, rather than getting caught and share the
    information anyway, under worse conditions.<br></div></blockquote><div><br></div><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>