<div dir="auto">So, will all CA systems out there accept and process my S/Mime CSR if I submit it with just the public key and no Subject DN or SAN? Has that been tested?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 5, 2023, 2:51 PM Berge, Jochem Van den via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="NL" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="m_-5224068849881471405WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Hi Adriano/Rob,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Although I can see were you’re coming from (I’ve seen plenty of examples of garbled subject info in CSRs over time) I doubt
the use for such a check. Any kind of authentication or authorization is managed by different means already. If an applicant requests a certificate, is properly authenticated and the data in the TBS certificate is properly validated by the CA according to
the SBRGs but the Applicant uses a CSR with garbage subject info, that is not an issue that a CA should fix IMHO. Incorrect subject information in a CSR has zero impact on the end certificate (or it’s trustworthiness).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Having thought about it, the only use cases for subject data in a CSR I can see are either:<u></u><u></u></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="m_-5224068849881471405MsoListParagraph" style="color:#1f497d;margin-left:0cm">
<span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif">The Applicant has used the wrong CSR for a request by mistake, in which case a CA check on the subject data in the CSR could stop issuance of the certificate
and alert the Applicant that a potential mistake was made. But those kind of things can also happen with CSRs with the right subject data (multiple CSRs with identical subjects and different keys, although that is maybe less common for S/MIME and more for
TLS) <u></u><u></u></span></li><li class="m_-5224068849881471405MsoListParagraph" style="color:#1f497d;margin-left:0cm">
<span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif">Easy identification of CSRs if you have a whole stack of them in the same place/system. That is mostly for the Applicant, the CA should already have a database
entry for every application request and/or certificate. <u></u><u></u></span></li></ol>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Scenario 1 could be useful for a CA to check mainly with regards to customer service but with regards to the SBRGs it opens up another can of worms
if the vetted identity data in the CA application portal uses slightly different data than the CSR. Spelling variations, diacritics etc. can make this difficult and can also make an application for an S/MIME certificate frustrating if the check is too strict,
but automated checks tend to be black or white (0/1).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">In the end I agree with Clint’s original statement I think. The CSR should only be used to bind the certificate to a public key. Any other authentication
data or verification of source are managed elsewhere.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Kind Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Jochem van den Berge<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Compliance Officer PKIoverheid<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:14.0pt;font-family:"Verdana",sans-serif;color:#538135">Logius<u></u><u></u></span></b></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Digital Government Service<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">Ministry of the Interior and Kingdom Relations<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">........................................................................<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="FR" style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#1f4e79"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">M</span></b><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d"> (+31) (0)6 – 21 16 26 89<u></u><u></u></span></p>
<p class="MsoNormal"><b><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">T
</span></b><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">(+31) (0)70 - 888 76 91<b><u></u><u></u></b></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><a href="mailto:jochem.vanden.berge@logius.nl" target="_blank" rel="noreferrer"><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#0563c1">jochem.vanden.berge@logius.nl</span></a></span><u><span lang="FR" style="font-size:9.0pt;color:#0563c1"><br>
</span></u><span style="color:#1f497d"><a href="http://www.logius.nl/" target="_blank" rel="noreferrer"><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#0563c1">www.logius.nl</span></a></span><u><span lang="FR" style="color:#0563c1"><u></u><u></u></span></u></p>
<p class="MsoNormal"><span lang="FR" style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:#1f4e79"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="FR" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">workdays Mo-Tue & Thu-Fri<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#1f497d">........................................................................<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>Van:</b> Smcwg-public <<a href="mailto:smcwg-public-bounces@cabforum.org" target="_blank" rel="noreferrer">smcwg-public-bounces@cabforum.org</a>>
<b>Namens </b>Adriano Santoni via Smcwg-public<br>
<b>Verzonden:</b> dinsdag 3 oktober 2023 08:52<br>
<b>Aan:</b> <a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer">smcwg-public@cabforum.org</a><br>
<b>Onderwerp:</b> Re: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p>I agree with Rob.<u></u><u></u></p>
<p>Adriano<u></u><u></u></p>
<p><u></u> <u></u></p>
<div>
<p class="MsoNormal">Il 02/10/2023 20:45, Robert Lee via Smcwg-public ha scritto:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span>Hi all,</span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<p class="MsoNormal"><span>So, I can see the sense to Clint’s argument that fields in the CSR may be confirmatory but shouldn’t be the only source of the information that gets put into a certificate because it should be coming
from the store of vetted information held by the CA. But what if the fields in a provided CSR are explicitly contradictory to what is to be in the requested certificate?</span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<p class="MsoNormal"><span>Providing a CSR with no subject information in it to support the certificate request is one thing, but what if a subscriber provides a CSR containing subject information completely different to that
which should be put into the certificate? If I am requesting a certificate for <a href="mailto:rob@example.com" target="_blank" rel="noreferrer">
rob@example.com</a> and the CSR I send to the CA to provide my public key and proof-of-possession contains only the email address “<a href="mailto:definitelynotrob@definitelynotexample.com" target="_blank" rel="noreferrer">definitelynotrob@definitelynotexample.com</a>” then there is a reasonable
argument to be made that something strange is going on and that my CSR does not support my certificate request because the information it does contain doesn’t match what should be included in my certificate.</span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<p class="MsoNormal"><span>I guess I’d argue for a position of “The CSR doesn’t need to contain everything, but what is in there should at least be correct” which I _<i>think</i>_ mostly aligns with Clint’s position.</span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<p class="MsoNormal"><span>Best Regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span>Rob</span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><b><span style="color:#18376a">Dr. Robert Lee MEng PhD</span></b><u></u><u></u></p>
<p class="MsoNormal" style="background:white"><span style="color:#18376a;background:white">Senior Software Engineer with Cryptography SME</span><u></u><u></u></p>
<p class="MsoNormal" style="background:white"><span style="color:black"><a href="http://www.globalsign.co.uk/" target="_blank" rel="noreferrer"><span style="color:#0563c1">www.globalsign.co.uk</span></a></span><span style="color:#18376a">|</span><span style="color:black"><a href="http://www.globalsign.eu/" target="_blank" rel="noreferrer"><span style="color:#0b4cb4">www.globalsign.eu</span></a></span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<p class="MsoNormal"><span> </span><u></u><u></u></p>
<div id="m_-5224068849881471405mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org" target="_blank" rel="noreferrer">
<smcwg-public-bounces@cabforum.org></a> on behalf of Adriano Santoni via Smcwg-public
<a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer"><smcwg-public@cabforum.org></a><br>
<b>Date: </b>Monday, 2 October 2023 at 07:57<br>
<b>To: </b><a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer">smcwg-public@cabforum.org</a>
<a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer"><smcwg-public@cabforum.org></a><br>
<b>Subject: </b>Re: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs</span><u></u><u></u></p>
</div>
<p>Not necessarily: the email address can be transmitted to the CA as a separate datum.
<u></u><u></u></p>
<p>Indeed, I would say that this is preferable because it allows syntax checking on the email address without even starting to look at the CSR, from which in my opinion only the public key should be taken.<u></u><u></u></p>
<p>Adriano<u></u><u></u></p>
<p> <u></u><u></u></p>
<div>
<p class="MsoNormal">Il 29/09/2023 21:21, Ben Wilson via Smcwg-public ha scritto:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div align="center">
<table border="1" cellpadding="0" width="30%" style="width:30.0%">
<tbody>
<tr>
<td valign="top" style="background:yellow;padding:1.5pt 1.5pt 1.5pt 1.5pt">
<p class="MsoNormal"><span style="color:red">NOTICE:</span><span style="color:black"> Pay attention - external email - Sender is
<a href="mailto:0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@amazonses.com" target="_blank" rel="noreferrer">
0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@amazonses.com</a> </span>
<u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal" align="center" style="text-align:center"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Shouldn't at least the email address be included, and verified, of course, by the CA?<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES <<a href="mailto:pfuentes@wisekey.com" target="_blank" rel="noreferrer">pfuentes@wisekey.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">+1<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer">smcwg-public@cabforum.org</a>> a écrit :<u></u><u></u></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi all, <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-Clint<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" target="_blank" rel="noreferrer">smcwg-public@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">All,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Ben<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Smcwg-public mailing list<br>
<a href="mailto:Smcwg-public@cabforum.org" target="_blank" rel="noreferrer">Smcwg-public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" target="_blank" rel="noreferrer">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
Smcwg-public mailing list<br>
<a href="mailto:Smcwg-public@cabforum.org" target="_blank" rel="noreferrer">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=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw&s=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA&e=" target="_blank" rel="noreferrer">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><u></u><u></u></p>
</div>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Smcwg-public mailing list<u></u><u></u></pre>
<pre><a href="mailto:Smcwg-public@cabforum.org" target="_blank" rel="noreferrer">Smcwg-public@cabforum.org</a><u></u><u></u></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" target="_blank" rel="noreferrer">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><u></u><u></u></pre>
</blockquote>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Smcwg-public mailing list<u></u><u></u></pre>
<pre><a href="mailto:Smcwg-public@cabforum.org" target="_blank" rel="noreferrer">Smcwg-public@cabforum.org</a><u></u><u></u></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" target="_blank" rel="noreferrer">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><u></u><u></u></pre>
</blockquote>
</div>
<br>
<hr>
<font color="gray" size="1" face="Arial">Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.<br>This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. <br></font></div>
_______________________________________________<br>
Smcwg-public mailing list<br>
<a href="mailto:Smcwg-public@cabforum.org" target="_blank" rel="noreferrer">Smcwg-public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" rel="noreferrer noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><br>
</blockquote></div>