<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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:125589024;
mso-list-type:hybrid;
mso-list-template-ids:-1117359556 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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 l0: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;}
@list l1
{mso-list-id:299386764;
mso-list-template-ids:570709484;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l2
{mso-list-id:908926833;
mso-list-type:hybrid;
mso-list-template-ids:-1428641892 1451363942 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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;}
@list l3
{mso-list-id:1411653152;
mso-list-type:hybrid;
mso-list-template-ids:1022529014 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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 l3: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">Entrust would also like to provide some comments to the S/MIME BRs. First, great job, we have gone from zero to a set of baseline requirements which are now open for community review before finalization.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In some cases, we find the requirements are above current practices, so could also be considered above what we have considered to be baseline for SSL and Code Signing. The result might be to either increase time required for adoption, or
potentially reducing identity which we currently see in certificates.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Monitoring of Enterprise RAs<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">Although this is required from SSL BRs, the Enterprise RA can only approve sub-domains and approve certificate issuance. There is nothing to monitor for sub-domains, as this is in
the Subscriber’s control. For approving SSL certificate issuance, this could be as simple as 2-factor login. In essence for SSL certificates monitoring of an Enterprise RA is a minimal task.
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">For S/MIME certificates, the Enterprise RA would have to verify firstName/surname and the front end of the email address. In addition, the customer could have many Enterprise RAs,
which support the issuance of thousands of certificates per year. So how do we monitor this activity and do we really need to? Enterprise RAs are really technically constrained to verified organizations and domain names, so is monitoring required? Could we
enforce the Enterprise RA requirements in the Subscriber agreement?<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">If auditing/monitoring is required, then should a list of methods be provided? If not, then each CA can do whatever they can convince their auditor is good enough.<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">EV Verification<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">EV vetting does not appear to be a baseline requirement, it is costly and there is no extended benefit which we have from SSL and Code Signing. OV vetting does appear to an appropriate
baseline requirement and is currently used by CAs today.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">If we have EV vetting for an Organization, how does this extend to Certificate Approver, Contract Signer and Certificate Requester validation? Do we need this? This is increased vetting
for S/MIME BR, which is not required by the SSL or Code Signing BRs. We already have the Enterprise RA, which can authorize a certificate to be issued.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo4">Also, there may be too many restrictions which would result in decreasing identity. For instance, can we remove 3.2.3.6 Operational Existence?<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">S/MIME Revocation<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo5">Should revoked S/MIME certificates be removed from the CRL/OCSP responses after the certificate has expired? Since an email can be read after certificate expiry, shouldn’t the relying
party know the revocation status?<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Subscriber Private Key Generation<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo5">Section 6.1.2 doesn’t provide any indication that a CA could generate the key pair for the subscriber. The CA should be allowed to do this and that the section should provide requirements
for protecting key delivery. This has been addressed in the CSBRs.<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Subscriber Key Recovery<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo5">Not addressed. Should we address recovery, if a CA has generated the key pair?<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Multi-factor<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo5">Should this either be removed or updated? “The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.” This appears to be a
drop-in requirement, which again could be removed or updated for more clarity.<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Bruce.<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 4:54 AM<br>
<b>To:</b> smcwg-public@cabforum.org<br>
<b>Subject:</b> [EXTERNAL] [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">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<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:l2 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:l2 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:l2 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>
<i>Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the
information it contains. <u>Please notify Entrust immediately</u> and delete the message from your system.</i>
</body>
</html>