
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Well… given that anyone can generate a CSR containing arbitrary information, taking this a a criteria for linking the public key with the “who” can lead to dangerous assumptions. </div><div dir="ltr"><br></div><div dir="ltr">Anyway I understand your exercise and intent. In our case we don’t see fit taking anything from the CSR but the public key, but maybe other CAs can bring useful ideas to consider. </div><div dir="ltr"><br><blockquote type="cite">Le 29 sept. 2023 à 21:51, Ben Wilson <bwilson@mozilla.com> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div>Hi,</div><div>It seems simply, as a method of tracking, that Certificate Issuers might find it helpful to have an email address in the CSR. Plus, if you're establishing proof of possession, then doesn't it help to know something about "who" is asserting possession of the key pair? (I don't think a CSR with only a signed public key is sufficient.) I'm not disagreeing about how this should be done securely, end-to-end, and I'm certainly not saying that Certificate Issuers create certificates based solely on CSRs. I'm just asking for suggestions from Certificate Issuers about a set of common fields that might be in the most basic type of CSR that would then lead up to the issuance of an S/MIME certificate, once all of that information has been validated. <br></div><div>Thanks,</div><div>Ben<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 29, 2023 at 1:33 PM Pedro FUENTES <<a href="mailto:pfuentes@wisekey.com">pfuentes@wisekey.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">That’s an interesting point, but the same than there’s no need to consider the domains coming in the CSR to issue TLS certificates, I personally don’t see the practical need here. </div><div dir="ltr"><br></div><div dir="ltr">For example… We could have an Enterprise RA that can issue certs for any email address in a set of preauthorized domains and this would just make the content of the CSR quite irrelevant. </div><div dir="ltr"><br></div><div dir="ltr">In our case, we rely on other security methods (e.g. authentication credentials to the certificate management system) to link the certificate request attributes, the domain validation method and the public key in the CSR. We just think is better to rely on the verified information and not on whatever the CSR had. </div><div dir="ltr"><br><blockquote type="cite">Le 29 sept. 2023 à 21:21, Ben Wilson <<a href="mailto:bwilson@mozilla.com" target="_blank">bwilson@mozilla.com</a>> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Shouldn't at least the email address be included, and verified, of course, by the CA?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES <<a href="mailto:pfuentes@wisekey.com" target="_blank">pfuentes@wisekey.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">+1</div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" rel="noreferrer" target="_blank">smcwg-public@cabforum.org</a>> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">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="m_-2600798333352524199m_-6534719190591544900lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" rel="noreferrer" target="_blank">smcwg-public@cabforum.org</a>> wrote:</div><br><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 href="mailto:Smcwg-public@cabforum.org" rel="noreferrer" target="_blank">Smcwg-public@cabforum.org</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=3Ai2uFDmuPvkjzx8-NXCPUEmAIzjkD-8sGOWakiphpuCLfulDVnTYuieselnddbL&s=DlmLTfjyPj2kGhM6d66NyUTRj15XswMU-gv6MKDY5F8&e=" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><br></div></blockquote></div><br></div><span>_______________________________________________</span><br><span>Smcwg-public mailing list</span><br><span><a href="mailto:Smcwg-public@cabforum.org" rel="noreferrer" target="_blank">Smcwg-public@cabforum.org</a></span><br><span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw&s=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw&s=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA&e=</a></span><br></div></blockquote></div></blockquote></div>


</div></blockquote></div></blockquote></div>


</div></blockquote></body></html>