<html 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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle22
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=en-SE link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>+ Another one. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>I’m also worried that this 3% audit for Enterprise RA’s might become a GDPR (or likewise in different territories) nightmare. <o:p></o:p></span></p><p class=MsoNormal><span lang=en-SE style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Smcwg-public <smcwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Doug Beattie via Smcwg-public<br><b>Sent:</b> Thursday, 10 March 2022 14:47<br><b>To:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; SMIME Certificate Working Group <smcwg-public@cabforum.org>; Henschel, Andreas <a.henschel@d-trust.net><br><b>Subject:</b> Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span lang=EN-US style='font-size:10.0pt;color:black'>CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>I agree that we should not permit completely unvalidated in in the certificates, but can we delegate the validation of these 3 fields to the Enterprise RA to not include “misleading” information (without requiring CA and Enterprise audits)?  Mandating formal audits of this data is a no-go, imo.  <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> <br><b>Sent:</b> Thursday, March 10, 2022 7:59 AM<br><b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>>; SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>>; Henschel, Andreas <<a href="mailto:a.henschel@d-trust.net">a.henschel@d-trust.net</a>><br><b>Subject:</b> Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>On 10/3/2022 2:22 μ.μ., Doug Beattie wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US style='color:#548235'>If there are usecases that demand more, then let’s let them define those rules and policy OIDs to be used in the certificates on top of the profiles we’re defining here.</span><span lang=EN-US><o:p></o:p></span></p></blockquote><p class=MsoNormal><span lang=EN-US><br>I'm afraid I can't support that position. We have always had rules to include validated information in the certificates, even "any other method" that the CA deems appropriate. Even for the subject:organizationalUnitName field, there were rules describing what the CA MUST NOT allow. Allowing fields without any vetting whatsoever is not correct IMHO. It should not be considered "appropriate" from the CA because it is not performing any sort of validation!<br><br>BTW, I agree with the position to bring in use cases and define rules. The WG needs to be a bit more active in that regard because it is the only way that existing use cases will be discussed, analyzed and safe practices included in the SMBRs. However, until we have those use cases brought forward so that the WG can define rules, I believe we should not allow them.<br><br>Dimitris.<o:p></o:p></span></p></div></div></body></html>