<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=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:212814923;
mso-list-template-ids:745171440;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:908926833;
mso-list-type:hybrid;
mso-list-template-ids:-1428641892 1451363942 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:6;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hello:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you for pointing out that we need better handling for “Sponsor-validated certs” where the vetting is performed by the CA or an RA which is not an Enterprise RA. I have drafted proposed text as a new item 6 at:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#3241-attribute-collection-of-individual-identity">https://github.com/cabforum/smime/blob/preSBR/SBR.md#3241-attribute-collection-of-individual-identity</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regards, 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 <smcwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Christophe Bonjean via Smcwg-public<br><b>Sent:</b> Monday, April 25, 2022 5:54 AM<br><b>To:</b> smcwg-public@cabforum.org<br><b>Subject:</b> [Smcwg-public] Comments and questions on draft SMIME BRs<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><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In reviewing the draft S/MIME Baseline Requirements, GlobalSign has the following comments and questions:<o:p></o:p></p><p class=MsoNormal><b><o:p> </o:p></b></p><p class=MsoNormal><b>Validation level<o:p></o:p></b></p><p class=MsoNormal>With SMIME certificates, the goal is to provide “reasonable assurance” that the other party to the communication identified in the certificate has control of the domain or email address being asserted. <o:p></o:p></p><p class=MsoNormal>We realize that additional validation elements as described in the TLS EVGs could provide a higher level of assurance than merely "reasonable assurance", however certain elements that are central to the TLS EVGs may place a significant burden on the Applicant organization (physical address, verified method of communication, operational existence).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What's the justification for requiring EV level validation over OV level validation?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Profiles<o:p></o:p></b></p><p class=MsoNormal>Multiple levels of profiles have been defined (legacy, strict) to allow for transitioning from legacy to a stricter profile, however the principle appears to be not consistently applied. <o:p></o:p></p><p class=MsoNormal>For example, there is a requirement for subject:givenName and subject:surname in the sponsor-validated (section 7.1.4.2.4) and individual-validated profile (7.1.4.2.5), both for legacy and strict.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If the intent for the legacy profile is to capture the profile of existing certificates, should givenName and surname be required only for the strict profile?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Enterprise RAs<o:p></o:p></b></p><p class=MsoNormal>If Enterprise RAs validate first name, last name and the first part of the email address, to which extent could that be considered constrained? The requirements of section 8.8 are subject to interpretation. If review or auditing is required, should we define specific criteria or practices?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Identity validation: eIDs<o:p></o:p></b></p><p class=MsoNormal>eIDs as defined and notified under eIDAS are currently excluded under "Digital Identity Documents" (section 3.2.4.1 option 2), which seems to aim at physical identity documents but with a digital component.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Given the defined framework, recognition and practical application of eIDs, it seems their purpose would fulfill the identity validation requirements of individuals for SMIME certificates. What's the rationale for excluding them?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Identity validation: Sponsor-validated without Enterprise RA<o:p></o:p></b></p><p class=MsoNormal>For sponsor-validated certificates with Enterprise RA, the validation of the individual identity information can be based on Enterprise RA records (section 3.2.4.1 option 4). For non-Enterprise RA sponsor-validated certificates, there is no equivalent option to rely on an attestation made by the sponsor for the individual identity information (e.g. first name, last name) or affiliation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Would it be possible to introduce the option to rely on attestation of the validated sponsor in the same way as we would rely on the Enterprise RA records if it meets the same requirements (Section 1.3.2 and Section 8.8) for individual identity information and/or affiliation?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Identity validation: Individual identity information<o:p></o:p></b></p><p class=MsoNormal>Should we also consider incorporating agency sources as a source for listed director individual identity information (akin to the Enterprise RA records, but publicly available and where the identity validation is regulated in the relevant jurisdiction of incorporation)?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Identity validation: Digital signatures<o:p></o:p></b></p><p class=MsoNormal>For digital signatures (section 3.2.4.1 option 3), could we allow additional adopted standards to be used under certain conditions, for example:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>CA has a documented procedure to review adopted standards against the SMIME BRs to ensure they meet the required assurance level;<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>the CA lists additional accepted standards in their CPS; and<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>CA notifies these additional standards for inclusion within the SMIME BRs, but pending acceptance/rejection these standards may be used.<o:p></o:p></li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Organizational Units<o:p></o:p></b></p><p class=MsoNormal>Would departments as organizational units fit within the profile? And if yes, could they be included in organization-validated or sponsor-validated? The current definition of organizationalUnitName (section 7.1.4.2.2 item c) seems to be limited to affiliate entities, but not departments?<o:p></o:p></p><p class=MsoNormal><b><o:p> </o:p></b></p><p class=MsoNormal><b>Key generation<o:p></o:p></b></p><p class=MsoNormal>Section 6.1.2 does not currently specify whether it's prohibited or allowed to generate private keys for customers?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Revocation status<o:p></o:p></b></p><p class=MsoNormal>Since emails may be read a while after the validity period of the certificate, should status information remain on OCSP/CRL after expiry of the certificate?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Christophe<o:p></o:p></p></div></body></html>