<div dir="ltr"><div>Hello Dimitris,</div><div><br></div><div>Thank you very much for reviewing the proposed text. Responses can be found inline.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 19, 2022 at 6:37 PM Dimitris Zacharopoulos (HARICA) 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>
<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></div></blockquote><div><br></div><div>I appreciate the concerns on the correctness of the entity that applies for a certificate. I believe that this case is the same as the case of "control" vs "operate" the device in the WebPKI BRs. The CA/B Forum has agreed that both of these cases are valid and acceptable cases for the issuance of a TLS certificate.<br><br>In addition, in this case the Applicant has the same properties as the Applicant in the Enterprise RA validation method, which this WG has already agreed is an acceptable validation method, and one of the major use cases of all CAs. Note that the entity that the CA is validating in the S/MIME BRs is the mailbox and not the domain, therefore in the Enterprise RA case the CAs still don't have the entity that controls the mailbox as an Applicant, but the operator entity that controls the domain, and therefore controls the MX records that point to the mail server. Having said that, I believe that if the WG raises these concerns, they should be raised for all similar cases, both control of the mail server and control of the domain (Enterprise RA case) since both of them are based on the same principles.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<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></div></blockquote><div><br></div><div>Similarly to the previous concern, this concern can be raised for most other types of validation, both in the S/MIME BRs and the TLS BRs. For example:<br><br>- For the Enterprise RA case in the S/MIME BRs: the entity that applied for the issuance of a certificate decides to stop using this email address, and therefore the domain administrator should not be authorized to issue certificates under their domain name for the old email address.<br>- For the Enterprise RA case in the S/MIME BRs (second case): the entity that controls the domain changes the NS record in their registrar, and therefore the domain administrator should not be authorized to issue certificates under their domain name.<br>- For the Agreed‑Upon Change to Website in the TLS BRs (more clear use case): the entity that controls the domain decides to change the A/AAAA record, and therefore the operator should not be authorized to issue certificates.<br>- For the Email to DNS CAA Contact in the TLS BRs (exactly the same use case): the entity that controls the domain decides to change the email contact in the CAA record.<br><br>In practice, in all those cases, reuse of validation information is allowed based on section 4.2.1.<br><br>The way the CA/B Forum mitigates this risk in the TLS BRs is not by requiring mandatory checking of the validation for every single issuance, but with the following additions:<br><br>4.9.1.1 Reasons for Revoking a Subscriber Certificate<br>The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:<br>…<br>5. The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon.<br>…<br>9.6.3 Subscriber representations and warranties<br>…<br>5. Reporting and Revocation: An obligation and warranty to:<br>…<br>b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;<br><br>I would be glad to work on sections 4.9.1.1 and 9.6.3 once the WG gets there, in order to address your concerns, but at the moment I feel that the validation method should be accepted as it has the exact same properties as the Enterprise RA validation method.<br><br>With regards to the CAA comment, I think that this is a completely different use case related to the authorization of the CA and not the validation of the Applicant.<br><br>Best regards,<br>Fotis<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
<br>
Dimitris.<br>
<br>
<div>On 19/1/2022 7:17 μ.μ., Stephen
Davidson via Smcwg-public wrote:<br>
</div>
<blockquote type="cite">
<div>
<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)<u></u><u></u></b></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>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Smcwg-public mailing list
<a href="mailto:Smcwg-public@cabforum.org" target="_blank">Smcwg-public@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</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></div>