<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
This method has several challenges some of which have already been
discussed in the validation subcommittee and the server certificate
working group. It's basically the fact that the control of the
domain name is performed by a different entity, which is different
than the actual "Applicant". It is like the Applicant is delegating
control over to a different entity.<br>
<br>
Assuming we overcome these issues, if we accept the fact that the
operator of a server in the MX records of a Domain Name is by virtue
<b>authorized </b>to issue any S/MIME certificate that contains any
email address that contains the domain part of the validated domain
name, this validation evidence <u>should not be allowed to be
reused</u>. That is because the Domain Name owner could decide to
switch to another mail provider, change the MX records and wouldn't
want the previous mail provider to be authorized to issue
certificates under their Domain Name.<br>
<br>
This means that, similarly to the CAA mandatory checking requirement
in the TLS BRs, the CA would need to always check the MX records for
every Domain Name being validated using this method.<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 19/1/2022 7:17 μ.μ., Stephen
Davidson via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100017e7357c218-754f3d69-5c2a-410f-b8eb-371d5c91fe13-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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;}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;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;}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]-->
<div class="WordSection1">
<p class="MsoNormal">Hello all:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Per our discussion today of the draft text
of section 3.2.2 “<a
href="https://github.com/cabforum/smime/blob/preSBR/SBR.md#322-validation-of-mailbox-authorization-or-control"
moz-do-not-send="true">Validation of mailbox authorization
or control</a>” Fotis Loukos has proposed a new method for
"validating applicant as operator of associated mail
servers." This would apply in cases where I have my own
domain but redirect/outsource the operation of my entire email
domain to a service.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I believe that we should accommodate this
common use case in the S/MIME BR, but know that it’s different
from our previous discussions on mailbox verification which
centered mainly on familiar methods from the TLS BR. As such,
I attach the proposed text below and hope that WG members can
review the associated RFC 5321 Section 5.1 and provide
feedback on list. For example, this may tie in with another
agenda item on the reuse periods for different types of
verification. If needed we can schedule specific time (perhaps
at the F2F) to work on this as well.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It was a useful call today; thank you.<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>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>#### 3.2.2.3 Validating applicant as
operator of associated mail server(s)<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Confirming the Applicant's control over the
rfc822Name email address by confirming control of the SMTP
FQDN to which a message delivered to the email address should
be directed. The SMTP FQDN MUST be identified using the
address resolution algorithm defined in RFC 5321 Section 5.1
which determines which SMTP FQDNs are authoritative for a
given email address. If more than one SMTP FQDNs have been
discovered, the CA MUST verify control of an SMTP FQDN
following the selection process at RFC 5321 Section 5.1.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When confirming the Applicant's control of
the SMTP FQDN, the CA MUST use the methods described in
Section 3.2.2.4 of the TLS Baseline Requirements.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This method is suitable for validating
control of all email addresses under a single domain.<o:p></o:p></p>
</div>
<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>
<br>
</body>
</html>