<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">On 2/20/2018 9:34 AM, J Decker wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CAA2GJqU4jsKki_VVfoA=6Le+SCkZp6po085PYxrfc8KdXd+83w@mail.gmail.com">

      <div dir="ltr">Client does a verification and passes or fails, and

        via the SSL layer I can query if the client validated the

        certificate.

        <div class="gmail_extra">

          <div class="gmail_quote">

            <div>If it failed, provide a option for the client to get a

              renewed certificate for verification.  If success, no

              action.</div>

            <div>If an actor lies in this scenario he answers</div>

            <div>lies *yes* and didn't, don't give him a means to

              actually verify. *noop*</div>

            <div>lies *no* but did, then give him the root cert he

              already has.... *noop*</div>

          </div>

        </div>

      </div>

    </blockquote>

    <br>

    Er... so I have my malicious MITM server serve up a certificate that

    the client won't accept, and then helpfully provide it with my root

    certificate so that it won't have any trouble talking to me?<br>

    <br>

    There's a reason for the client to verify the server's certificate. 

    If the client can't verify the server's certificate, then there's no

    reason to believe that it's the right server and can be trusted.<br>

    <br>

    Any certificate updates have to be protected by the previous

    certificate.  If you've let the certificate lapse then you need some

    kind of out-of-band verification.<br>

    <br>

    <pre class="moz-signature" cols="72">-- 

Jordan Brown, Oracle Solaris</pre>

  </body>

</html>