> - Sending a link that must be accessed to approved is known-insecure, as > automated mail scanning software may automatically dereference links in > e-mail (in order to do content inspection). Confirm/Reject buttons alone > shouldn't be seen as sufficient to mitigate this, as that may vary based on > how the crawler works. Requiring explicit entry of the random value is a > necessary "human" measure (aka similar to a CAPTCHA)
We do actually have a CAPTCHA above the [CONFIRM] / [REJECT] buttons, which must be filled before proceeding. Is this not considered sufficient? I wonder because I have recently seen this same email DCV method process in other CAs (link that must be accessed to approve), and no captcha nor explicit entry of the random value is required; just “approve” button (not even “reject”). If it was deemed necessary, instead of including the RV in the link, we could include the RV in the email, and require the applicant explicitly enter this RV in the webpage. > - You haven't described how the email address is constructed for these > cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and > if and only if the domain contact is the same for all of the requested > domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it > would be inappropriate if hostm...@apex1.example could approve a request > for apex2.example, yet, as currently described, that seems to be possible, > in that both hostm...@apex1.example and hostm...@apex2.example will > receive the same Request ID to approve/reject the request. For *each* of the domains to be included in the certificate, a email for DCV purpose has to be chosen from the ones the system automatically lists: 1) Constructed emails, using admin@, administrator@, webmaster@, hostmaster@, or postmaster@ + apex domain. (method 3.2.2.4.4) 2) Result of the WHOIS lookup previously made, for the “technical contact”, or “administrative contact” (method 3.2.2.4.2). The WHOIS lookup is performed automatically by making a query to the whois service corresponding to the tld. This method can only be used when there is public information available and the registrar/WHOIS provider has not masked it, otherwise, this option is not available. We do not reuse the Random Value. Each DCV email receives an independent email with a unique RV. Following your example, let the domains be apex1.example, apex2.example, and apex3.example. It would show 3 dropdown lists (one for each domain) with the emails to choose form: · apex1.example: acceptable emails as listed above. - e.g. Chosen email is hostmaster @apex1.example · apex2.example: acceptable emails as listed above. - e.g. Chosen email is admin @apex2.example · apex3.example: acceptable emails as listed above. - e.g. Chosen email is webmaster @apex3.example 3 emails would be sent: · To hostmaster @apex1.example - containing request ID (or "order ID"), unique RV and download link for program. · To admin @apex2.example - containing a link with a RV unique to this domain. · To webmaster @apex3.example - containing a link with a RV unique to this domain. In NO case apex1.example receives the same random value as apex2.example. So hostm…@apex1.example could not approve a request for apex2.example or apex3.example. Maybe the term “request ID” was what caused confusion. It refers to an identifier of the certificate request itself (maybe I should have called it “order ID”), not the RV. We are working on supporting other DCV methods in the near future (by April), specifically .13, .14. since are the most similar and easier to integrate in our current system. Also studying the option of integrating method .7. Regards, Pablo _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
