<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Calibri">We also find it unjustified to require
EV-style vetting in "Baseline Requirements".</font></p>
<p><font face="Calibri">More comments will follow in subsequent
emails.<br>
</font></p>
<p>Thank you,</p>
<p> Adriano</p>
<p>ACTALIS S.p.A.</p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 25/04/2022 16:48, Bruce Morton via
Smcwg-public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:01000180613226f5-f9792ea1-34e0-45e5-a21d-a98193ed6198-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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-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;}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;}div.WordSection1
{page:WordSection1;}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]-->
<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
<a class="moz-txt-link-rfc2396E" href="mailto:smcwg-public-bounces@cabforum.org"><smcwg-public-bounces@cabforum.org></a>
<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> <a class="moz-txt-link-abbreviated" href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a><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" style="text-align:center" align="center">
<hr width="100%" size="2" 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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
</body>
</html>