On March 10, 2021, we began the public discussion period [Step 4 of the Mozilla Root Store CA Application Process <https://wiki.mozilla.org/CA/Application_Process>] for ANF’s inclusion request.
One commenter recounted some of ANF's certificate misissuance events and expressed concern that CAs trusted in the Mozilla program must provide "assurance to its users that they won't be harmed by the CA" and "a CA which has lax technical controls, a poor understanding of PKI, and an inability to learn from and improve when mistakes are made is at heightened risk of exploitation by malicious actors that would harm Mozilla users." ANF responded <https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/pC3tDsAtCAAJ> that it fully understood the context and seriousness of such matters. This was followed with additional concerns expressed by the commenter <https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/njDu-WUxCQAJ>, and additional responses from ANF <https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/l-ea6y15CQAJ> . Another community member asked about ANF's explanations of its domain validation procedures and possible gaps / insecure implementations in those domain validation processes. ANF responded <https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/LaxgswS9CQAJ> to those questions and provided clarifications about its use of additional mechanisms to address those potential gaps, including CAPTCHA, email address construction, and use of random values. Based on this review of the public discussion, I do not believe there are any open action items for ANF to complete under Steps 5-8 of the application process. This is notice that I am closing the public discussion period [Step 9] and that it is Mozilla’s intent to approve ANF’s request for inclusion [Step 10]. This begins a 7-day “last call” period (through April 8, 2021) for any final objections. Thanks, Ben On Wed, Mar 17, 2021 at 12:45 PM Pablo Díaz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > - 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
