<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Calibri">I fully concur with Clint Wilson.</font></p>
    <p><font face="Calibri">Adriano</font></p>
    <p><font face="Calibri"><br>
      </font></p>
    <div class="moz-cite-prefix">Il 29/09/2023 17:52, Clint Wilson via
      Smcwg-public ha scritto:<br>
    </div>
    <blockquote type="cite"
cite="mid:0100018ae1a3f6b2-0272cd2e-d6e1-4167-98b7-8ab52834368f-000000@email.amazonses.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Hi all,
      <div><br>
      </div>
      <div>In my opinion, CSRs should really be limited to conveying the
        public key and a proof of possession of the private key; the
        fields included therein <i>may</i> act as confirmatory signals
        for a CA, but shouldn’t be directly relied upon e.g. to generate
        a tbsCertificate. Rather, the values placed in fields of a
        tbsCertificate should originate from the CA’s validated data
        store to ensure that the only paths for data to become part of a
        signed certificate are through static configurations (e.g.
        signatureAlgorithm) or known-validated data.</div>
      <div><br>
      </div>
      <div>There’s plenty of nuance we can discuss as well, but
        generally speaking I believe it’s bad practice to rely on fields
        in the CSR.</div>
      <div><br>
      </div>
      <div>Cheers,</div>
      <div>-Clint<br id="lineBreakAtBeginningOfMessage">
        <div><br>
          <blockquote type="cite">
            <div>On Sep 29, 2023, at 8:27 AM, Ben Wilson via
              Smcwg-public <a class="moz-txt-link-rfc2396E" href="mailto:smcwg-public@cabforum.org"><smcwg-public@cabforum.org></a> wrote:</div>
            <br class="Apple-interchange-newline">
            <div>
              <div dir="ltr">
                <div>All,</div>
                <div>I'm interested in gathering information from
                  Certificate Issuers about the kind of information that
                  they would like to collect/extract from the CSRs they
                  receive from S/MIME certificate applicants. This
                  information could be used to refine a system to
                  generate CSRs that result in certificates compliant
                  with the various profiles defined in the S/MIME BRs.
                  Alternatively, what is the minimum amount of
                  information that CAs might expect to obtain from CSRs?
                  In other words, which fields should a CSR generator
                  integrated with a Certificate Consumer's software
                  support?</div>
                <div>Thanks,</div>
                <div>Ben<br>
                </div>
              </div>
              _______________________________________________<br>
              Smcwg-public mailing list<br>
              <a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><br>
              <a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
    </blockquote>
  </body>
</html>