<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>We should definitely add guidance, but it needs to be couched in “if using CSRs …”.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I consider CSRs to be mildly obsolete, and generally useful only because they are the format that most key generation tools and CA toolchains are used to dealing with and have robust support for. Which I agree that clarifying that a CSR is only for transporting a key, and PoP, if necessary. Though CSRs tend to be bad for PoP anyway, especially if you remove the identity information, because without any context binding the CSR is globally replayable and therefore doesn’t prove anything about who owns that key.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But there are many ways to request a certificate that don’t use a CSR at all, and those are often preferable anyway. We need to make sure we don’t accidentally negatively impacts the ability to use better methods than CSRs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <smcwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Saturday, September 30, 2023 10:13 AM<br><b>To:</b> smcwg-public@cabforum.org<br><b>Subject:</b> Re: [Smcwg-public] Fields for S/MIME CSRs<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On 30/9/2023 4:39 μ.μ., Stephen Davidson via Smcwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hello all:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>If widely supported, should we consider documenting this in the S/MIME BR?<o:p></o:p></p></blockquote><p class=MsoNormal><br>I had the impression that this is was the common understanding and already a dominating practice (using only the public key out of a CSR). There are many documented CA incidents (<a href="https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Closed_Incidents___.YXAzOmRpZ2ljZXJ0OmE6bzpjMGQyZmVkMjUwYjAxNjljNGY1MDgzZThhMjY0ODkyYjo2OjZjNWY6ODE1MWIzZWI5ZjQ5NjIwZTA4NTMxZWQ2MGM3N2JjNjM0YjdmOTA1YTg0ODk5OTM0NWQ2MmU4ZTViNmRmZWY5MzpoOkY" title="Protected by Avanan: https://wiki.mozilla.org/CA/Closed_Incidents">https://wiki.mozilla.org/CA/Closed_Incidents</a>) that explain that using any information inside a CSR other than the public key, is dangerous and could result even in attribute encoding issues.<br><br>I am very supportive of adding this clarification/guidance into the S/MIME BRs and other BRs :)<br><br><br>Thanks,<br>Dimitris.<br><br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Best, Stephen<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org"><smcwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Clint Wilson via Smcwg-public<br><b>Sent:</b> Friday, September 29, 2023 12:52 PM<br><b>To:</b> Ben Wilson <a href="mailto:bwilson@mozilla.com"><bwilson@mozilla.com></a>; SMIME Certificate Working Group <a href="mailto:smcwg-public@cabforum.org"><smcwg-public@cabforum.org></a><br><b>Subject:</b> Re: [Smcwg-public] Fields for S/MIME CSRs<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Hi all,<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal>-Clint<o:p></o:p></p><div><p class=MsoNormal><br><br><br><o:p></o:p></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">smcwg-public@cabforum.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal> <o:p></o:p></p><div><div><div><p class=MsoNormal>All,<o:p></o:p></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?<o:p></o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Ben<o:p></o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>Smcwg-public mailing list<br><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><br><a href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzo0ODEzZjE5MTQ3NmQzMzBiY2EzZTg1MTAwNWYzODA0NTo2OjgzYjE6YjY4YzcwZWIwNTgwZmY3MmVlMjljNzM5Yzg0YmE4OWMyYTUwMDJmODE3NWY5ZTBjOWI5NzFiZjllODc2YjMwMjp0OkY">https://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzo0ODEzZjE5MTQ3NmQzMzBiY2EzZTg1MTAwNWYzODA0NTo2OjgzYjE6YjY4YzcwZWIwNTgwZmY3MmVlMjljNzM5Yzg0YmE4OWMyYTUwMDJmODE3NWY5ZTBjOWI5NzFiZjllODc2YjMwMjp0OkY</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal> <o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Smcwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzpjMGQyZmVkMjUwYjAxNjljNGY1MDgzZThhMjY0ODkyYjo2OmYwNzI6M2E3ODMyNzc5YTZkYTY4MDEyOTdmZmQ0YTdkZDRhZDkxNDU5NWI2N2VlNDE1MDA1ZjYyNjRhZTliMzFmMjNiODpoOkY" title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>