
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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 <smcwg-public@cabforum.org> 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>Smcwg-public@cabforum.org<br>https://lists.cabforum.org/mailman/listinfo/smcwg-public<br></div></blockquote></div><br></div></body></html>