<div dir="ltr">Hello Stephen,<br><br>It would probably be helpful to understand the underlying principles of the validation method in 3.2.2.1 and the proposed validation method to fully understand the risks and decide on the validation reuse.<br><br>Method 3.2.2.1 (Enterprise RA) validates that the Applicant has control over the domain portion of the email address. The underlying principle is that since the Applicant has control over the domain, they can change the MX pointers to point to another mail server that they control, and therefore control the mailbox. In fact, there is a concern here on whether a validation method that verifies operation of the domain by verifying that the Applicant controls the content served over HTTPS, such as 3.2.2.4.6 (Agreed‑Upon Change to Website), can be used to validate control of the mailboxes.<br><br>The proposed method directly validates control of the mail server by performing resolution of the SMTP FQDN. Therefore, the underlying principle is the same.<br><br>Since the security properties of both methods are the same, I believe that the reuse of the validation data should be the same, unless there is something I am missing.<br><br>Best regards,<br><br>Fotis<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 20, 2022 at 11:54 PM Stephen Davidson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-8596443066692305867WordSection1">
<p class="MsoNormal">Thanks Dimitris.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">You can see the PR at <a href="https://github.com/cabforum/smime/pull/34/files" target="_blank">
https://github.com/cabforum/smime/pull/34/files</a>, which has some related comments in place.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Your comment is also related to the upcoming topic on reuse of validation data.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">When (email) domain validation is used as described in Section 3.2.2.1 we will adopt the TLS BR standard allowing reuse for all corresponding Certificate Requests within a period up to a maximum of 398 days.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">I suggest that when mailbox validation is used as described in Section 3.2.2.2 and in this MX proposal:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in;text-indent:0.5in">1) the check must be checked for each Certificate Request, and
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in;text-indent:0.5in">2) A successful validation for each Certificate Request is valid for up to 30 days.<br>
An alternative would allow reuse of the successful verification for all corresponding Certificate Requests up to 30 days (ie, not be required every time).<u></u><u></u></p>
<p class="MsoNormal" style="text-indent:0.5in"><u></u> <u></u></p>
<p class="MsoNormal">Happy to hear alternate view points on this.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Best regards, Stephen<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Smcwg-public <<a href="mailto:smcwg-public-bounces@cabforum.org" target="_blank">smcwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br>
<b>Sent:</b> Wednesday, January 19, 2022 1:37 PM<br>
<b>To:</b> <a href="mailto:smcwg-public@cabforum.org" target="_blank">smcwg-public@cabforum.org</a><br>
<b>Subject:</b> Re: [Smcwg-public] Proposed method for "validating applicant as operator of associated mail servers"<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt"><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.<u></u><u></u></p>
<div>
<p class="MsoNormal">On 19/1/2022 7:17 μ.μ., Stephen Davidson via Smcwg-public wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Hello all:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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" target="_blank">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. 
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">It was a useful call today; thank you.<u></u><u></u></p>
<p class="MsoNormal">Regards, Stephen<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>#### 3.2.2.3 Validating applicant as operator of associated mail server(s)</b><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">This method is suitable for validating control of all email addresses under a single domain.<u></u><u></u></p>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Smcwg-public mailing list<u></u><u></u></pre>
<pre><a href="mailto:Smcwg-public@cabforum.org" target="_blank">Smcwg-public@cabforum.org</a><u></u><u></u></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

_______________________________________________<br>
Smcwg-public mailing list<br>
<a href="mailto:Smcwg-public@cabforum.org" target="_blank">Smcwg-public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><br><table cellspacing="0" cellpadding="0" style="font-family:"Times New Roman""><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif"><td nowrap style="border-top:2px solid rgb(213,15,37)">Fotis Loukos |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Security Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:fotisl@google.com" target="_blank">fotisl@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"> </td></tr></tbody></table><div>Brandschenkestrasse 110, 8002 Zurich, Switzerland</div><div>Company Identifikationsnummer: CH-020.4.028.116-1</div><div><br></div><div>This email can contain confidential information.If you received this email by mistake,</div><div>do not pass it to third parties and delete all copies and enclosures,</div><div>and let us know that it has been delivered to the wrong address.</div><div><br></div><div>Thank you.</div></div></div>