Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Ben Wilson]

All,

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for the ANF Secure Server Root CA. See
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9).

The ANF Secure Server Root CA is operated by ANF AC, a Qualified Trust
Services Provider in the European Union and in operation since the late
1990s.

A previous application for other root CAs was filed in 2010. See
https://bugzilla.mozilla.org/show_bug.cgi?id=555156. During that process
it was decided that a new root should be submitted.

This current CA inclusion application has been tracked in the CCADB and in
Bugzilla–

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000501

https://bugzilla.mozilla.org/show_bug.cgi?id=1585951

This new root CA certificate was signed in 2019, and it is proposed for
inclusion with the websites bit and EV enabled.

Mozilla is considering approving ANF’s request. This email begins the
3-week comment period, after which, if no concerns are raised, we will
close the discussion and the request may proceed to the approval phase
(Step 10).

*Root Certificate Information:*

ANF Secure Server Root CA

crt.sh -
https://crt.sh/?q=FB8FEC759169B9106B1E511644C618C51304373F6C0643088D8BEFFD1B997599

Download -
http://www.anf.es/es/certificates-download/ANFSecureServerRootCA.cer



*CP/CPS:*

Current CP is Version 3.3.1 / January 8, 2021

https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_3_1.pdf

Current CPS is Version 31 / February 1, 2021

https://anf.es/pdf/Certification_Practices_Statement_v31.pdf

Repository location:

https://www.anf.es/en/repositorio-legal/



*ANF's 2021 BR Self-Assessment* (PDF) is located here:

https://bug1585951.bmoattachments.org/attachment.cgi?id=9208014

*Audits:*

The 2020 ETSI EN 319 411 audit is available here:
https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation-ANF-2020_12423_V4_Signed.pdf.aspx?lang=it-IT.


The audit observed that Bug 555156
<https://bugzilla.mozilla.org/show_bug.cgi?id=555156> included "Misissuance
of SSL OV Test Certificate".

*Incidents: *

The incident reports provided by ANF indicate the misissuance of
certificates under the previous CA hierarchy. See
https://bug555156.bmoattachments.org/attachment.cgi?id=9100493 and
https://bugzilla.mozilla.org/attachment.cgi?id=9098945. However, no
misissuances have been found under the ANF Secure Server Root CA, and the
issuing CA certificates passed technical tests.

Thus, this email begins a three-week public discussion period, which I’m
scheduling to close on or about 31-March-2021.

We encourage you to participate in the review and discussion.

A representative of ANF must promptly respond directly in the discussion
thread to all questions that are posted.

Sincerely yours,

Ben Wilson

Mozilla Root Store Program

[Andrey West Siberia]

Hello,
I can't find the test URIs for this root certificate...

[Ben Wilson]

Here you go:

https://testvalidsslev.anf.es
https://testrevokedsslev.anf.es
https://testexpiredsslev.anf.es

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Andrew Ayer]

On Wed, 10 Mar 2021 13:43:55 -0700
Ben Wilson via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> This is to announce the beginning of the public discussion phase of
> the Mozilla root CA inclusion process for the ANF Secure Server Root
> CA.

I'd like to draw attention to the first misissuance mentioned
in <https://bugzilla.mozilla.org/attachment.cgi?id=9098945> and
<https://bug555156.bmoattachments.org/attachment.cgi?id=9100493>.
Although this misissuance occurred under ANF's old hierarchy, that
hierarchy is/was trusted by Apple and Microsoft, and ANF was requesting
its inclusion in Mozilla, so the incident is relevant to understanding
how ANF operates a publicly-trusted certificate authority.

In 2019, ANF issued a server certificate
<https://crt.sh/?sha256=6C1F1CDA9E6BD20E300C84D3C54BABE5A79A7901E373C21DE0D63055F4935B52>
with a DNS name of cdcdcd. Obviously, they could not have possibly
validated domain control of this hostname, which is a serious failure
considering that domain validation is the most important task a
CA performs. However, their incident report doesn't mention domain
validation at all. They blamed the incident on human error by "junior
engineers" and their resolution was to implement a blocklist of words
that indicate a test certificate ("Test", "Testing", "Prueba"), provide
more training for junior engineers, and update their "Disciplinary
Measures and Sanctions document, in order to have this resources
available in case of infringement". None of these resolutions address
the root failure to perform domain validation. Had this incident
report been written several years earlier, it may have been excusable,
but by 2019 it was very clear to anyone following mdsp and CA incidents
that "human error" is not acceptable analysis and training is not an
adequate resolution.

Additionally, their incident report shows some pretty concerning
misunderstandings of PKI and the BRs:

1. A belief that the CABF's Test Certificate extension OID is meant for
testing their CA rather than a (now forbidden) domain validation method.

2. A belief that the CABF's Test Certificate extension OID is to be put
in the certificate policy extension rather than used as the ID for a
poison extension.

3. A conflation of the subject serial number and the certificate serial
number, stating that the subject serial number must contain 64 bits of
entropy.

Finally, note that the new hierarchy has issued zero end-entity
certificates known to CT, so the fact that the new hierarchy hasn't
misissued any certificates doesn't speak to the competence of ANF.
On the other hand, the history of misissuance in the old hierarchy,
ANF's misunderstandings of PKI, and the incredibly poor incident report
speak very poorly to ANF's competence and trustworthiness. There is
no indication that they've corrected the root cause of their failure to
perform domain validation, and no reason to believe that their
compliance problems won't reoccur under their new hierarchy.

When Mozilla trusts a CA, Mozilla is giving an assurance to its users
that they won't be harmed by the CA. 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. I do
not believe Mozilla can give assurance to their users that ANF is safe.
Therefore, this application should be rejected.

Regards,
Andrew

[Pablo Díaz]

Hello Andrew,

I am very aware that in the past the CA has made errors and misissuance, I fully understand the context and the seriousness of the matter. As CA we understand that it makes no sense to rely on "nothing serious ever happened", and the correct thing is to assume the importance of these errors, give explanations to the community and act to prevent them from happening again.

It is my purpose to gain the confidence of the community in ANF Autoridad de Certificación (ANF AC) and guarantee the operation of the CA in compliance, that is why I would like to take your intervention as an opportunity to give the pertinent explanations, comment on the substantial improvements applied in our PKI since then, and clarify those past bugs that remain confusing.

I completely agree that "Human error" is not an acceptable analysis, and "training improvement" is not the optimal solution. We have worked to apply as many automatic controls as possible to reduce any possible human error to a minimum, and the team of engineers who made those mistakes at that time are no longer in our organization. ANF AC made a profound change, both in human and technical resources.

We reviewed pretty much all the resources provided by Mozilla regarding frequent incidents and misissuances and the wiki pages dedicated to grouping incidents of specific CAs (which in many cases have led to their distrust), and finally we have established multiple automatic controls both in processing the request as in the moments prior to issuance. These controls, already applied and fully automatic, are as follows.

Regarding the domain:
• Automatic validation of the TLD is performed against IANNA’s Root Zone Database https://www.iana.org/domains/root/db to avoid Internal Names (BR 7.1.4.2.1)
• The FQDN must comply the “preferred name syntax” in RFC1034 modified by RFC1123.
• Domain and subdomain can only start with a letter or digit, end with a letter or digit. The only interior characters accepted are letters, digits and hyphen (so not underscore “_” - BR 7.1.4.2.1, or spaces “ “).
• Duplicate entries are not allowed (as we saw it happened at: https://bugzilla.mozilla.org/show_bug.cgi?id=1357067)
• Double automatic verification of CAA Records, at the time of formalization of the request and prior to the issuance.
• Automatic check against Google Safe Browsing List (GSB)
• Show warning and set aside for manual review in case of repeating 2 times a TLD registered by IANNA (com.com, net.net ...) (as we saw the case of suspicious com.com certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=1672409)
• In the case of Wildcard, both verification of the correct position of the asterisk (*) and suitability for the requested profile.
• If it contains more than 4 consonants in a row, which is unusual, shows a warning of potential typo is displayed.

Regarding the data of the subject, among others:
• To avoid typos of "geographic errors", we have standardized the values of stateOrProvinceName and localityName (locality whenever possible, given the magnitude) fields for Spain, and the countries of our main clients, using both official data and examples of certificates issued by other local CAs in those countries. This is also applied, in case of EV, to jurisdictionStateOrProvinceName and jurisdictionLocalityName fields.
• In the case of countryName being Spain, our main market, we have established automatic controls regarding the VAT number format (NIF), and a direct and automatic query to the official Spanish records to obtain the organization name as it is officially registered.
• In the case of countryName being Spain, automatic assignment of CategoryBusiness according to the VAT number format (to avoid incidents like this we saw here https://bugzilla.mozilla.org/show_bug.cgi?id=1600114). The first letter of VAT numbers in Spain indicates the legal type of the organization, so its easy to automate this classification.

Regarding domain validation, we are able to use the BR methods (3.2.2.4.2), (3.2.2.4.4) or (3.2.2.4.15). Measures have been applied to ensure that domain validation is not skipped:
• In the request process, emails built using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain are automatically listed. The random request confirmation code will be automatically sent to this email.
• In case of being multidomain, one of them is chosen to send the confirmation code and the rest, each one will be manually validated in the validation process (which also includes verification of documentation and other data) by our IRM staff (Issuance Reports Managers)
• Before confirming the issuance order, the IRM staff must indicate, for EACH domain, which domain validation method (of those indicated in ANF AC CP) was used, with current BR version number and attach files that provide evidence for this. Othewise it cannot proceed with issuance.

In addition to this, we have automatic pre-issuance lint using cablint, x509lint and zlint.

To reinforce the improvement of our controls, I subscribed to Bugzilla's CA Certificate Compliance and CA Certificate Root Program components to closely monitor bugs about mississuances and incidents other CAs included have and apply controls to avoid them.

Responding to the misunderstanding with the “Test certificates” that you pointed out, ANF AC CPS (since the update of December 5, 2019) indicates: “ANF AC does not issue SSL/TLS test certificates out of publicly trusted roots”. In that Bugzilla bug I clarified that, eventhough we were going to apply the measure as a poison extension, we investigated to find examples of this, and found one in a request for inclusion by Microsoft (which by then was as recently as some months ago) in which the OID was put in the certificate policies extesion. This reasoning was accepted by Mozilla as per https://wiki.mozilla.org/CA/Application_Verification, (and I quote Wayne Thayer in another thread) "a lack of comments indicates that the community is satisfied with the review that was performed on the inclusion request". As Ryan then told me, “if anything is confusing, out of expectation, or seems more permissive, it is important to raise these as concerns”, we should have raised this as concern before assuming it was OK and change our position, as it was definitely not OK. However, we also made clear no test certificates would be issued by Publicly Trusted Roots.

With the measures listed above, fully applied now, I can assure that what happened with the certificate issued for "cdcdcd" would not have been possible. In the request process it would have already been rejected. The automatic controls on the domain would have pointed out multiple errors, among others it does not comply with the “preferred name syntax”. The request for said certificate would not have proceeded in the first place.

This measures also prevent those compliance problems to reoccur under the new hierarchy ANF Secure Server Root. I believe that this should be taken into account to understand how ANF AC currently operates a publicly trusted certificate authority. We do not have lax control measures. I hope that the above shows the ability of ANF AC to learn and improve from the mistakes that were made, and to meet and try to exceed the minimum expectations.

I remain at your disposal to clarify any other aspect or give more clarifications to what is indicated in this email.

[Andrew Ayer]

On Fri, 12 Mar 2021 04:57:56 -0800 (PST)
Pablo D__az via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> [...]

>
> I completely agree that "Human error" is not an acceptable analysis,
> and "training improvement" is not the optimal solution. We have
> worked to apply as many automatic controls as possible to reduce any
> possible human error to a minimum, and the team of engineers who made
> those mistakes at that time are no longer in our organization.

The fact that this team of engineers is no longer in your organization
doesn't address the concerns; if anything, it raises more concerns.
The reason we reject human error as a root cause, which you don't seem
to understand because you mention the engineers, is that failures are
NOT the fault of humans who make mistakes. They're the fault of the
system which failed to prevent the mistakes.

The mention of the engineers, coupled with the note in the incident
report about "Disciplinary Measures and Sanctions", suggests that ANF
intends to use the threat of punishment to try to prevent mistakes.
Meanwhile, ANF is still relying on error-prone manual domain
validation, as we shall see below.

> [...]

>
> Regarding domain validation, we are able to use the BR methods
> (3.2.2.4.2), (3.2.2.4.4) or (3.2.2.4.15). Measures have been applied
> to ensure that domain validation is not skipped:

> * In the request

> process, emails built using 'admin', 'administrator', 'webmaster',
> 'hostmaster', or 'postmaster' + @ + apex domain are automatically
> listed. The random request confirmation code will be automatically
> sent to this email.

What is the process for verifying that the applicant knows the correct
Random Value?

> * In case of being multidomain, one of them is

> chosen to send the confirmation code and the rest, each one will be
> manually validated in the validation process (which also includes
> verification of documentation and other data) by our IRM staff
> (Issuance Reports Managers)

This alone should be grounds for rejecting the application, and shows
that your above claim that ANF has applied "as many automatic controls
as possible" is false. We've repeatedly seen how error-prone manual
domain validation processes are. CAs, especially those who have a
history of failure, should not be issuing certificates using manual
domain validation.

> * Before confirming the issuance order,

> the IRM staff must indicate, for EACH domain, which domain validation
> method (of those indicated in ANF AC CP) was used, with current BR
> version number and attach files that provide evidence for this.
> Othewise it cannot proceed with issuance.

In an automated system, it's unnecessary for staff to manually indicate
this, as the system knows which domain validation method was used.
What is the process for ensuring that staff do not report the incorrect
validation method, or report that domain validation was completed when
it really wasn't?

> In addition to this, we have automatic pre-issuance lint using
> cablint, x509lint and zlint.

While this is good practice for ensuring that RFC 5280-violating certificates
are not issued, it does not prevent certificates from being issued without
proper domain validation, so it's not responsive to the core concern of
ANF's failure to perform domain validation.

Although this response does highlight some good practices that ANF has
adopted, like preissuance linting and subscribing to the CA-related
components in Bugzilla, it ultimately reinforces the core concerns I
raised in my original post: the reliance on manual domain validation,
and an incident response philosophy that blames humans instead of
addressing root causes.

Regards,
Andrew

[Pablo Díaz]

> The reason we reject human error as a root cause, which you don't seem
> to understand because you mention the engineers, is that failures are
> NOT the fault of humans who make mistakes. They're the fault of the
> system which failed to prevent the mistakes.
> The mention of the engineers, coupled with the note in the incident
> report about "Disciplinary Measures and Sanctions", suggests that ANF
> intends to use the threat of punishment to try to prevent mistakes.

I believe that you have overlooked many of the reinforcement measures that I indicated in my previous email for the sake of your final conclusion. Measures that show that in ANF AC, we work so that our systems avoid the errors that humans could make, and that these would prevent errors that other included CAs have made (I gave some examples).

I pointed out several automated measures, however, the conclusion you reach is that we "intend to use the threat of punishment to try to prevent mistakes”...

The existence of said document “Disciplinary Measures and Sanctions” is not “threat of punishment”, it is a normative and legal obligation, by ETSI EN 319 401, whose REQ-7.2-05 indicates “Appropriate disciplinary sanctions shall be applied to personnel violating TSP's policies or procedures”; which refers to clause 7.2.3 of ISO/IEC 27002:2013 for guidance: "There should be a formal and communicated disciplinary process in place to take action against employees who have committed an information security breach."

Your interpretation that a “Disciplinary Measures and Sanctions” Policy is intended to intimidate our staff is far from reality. Contrary to that, this documented processes in an organization are intended to avoid arbitrariness and guarantee a unified criterion, which is known throughout the organization.
_________________________________________________________________

Regarding Domain Control Validation, I apologize for trying to be brief in my previous answer. I will go into more detail, so that it can be understood how ANF AC proceeds to validate the requests:

At the time of request, when indicating the domain or domains to be included in the certificate, the automated checks described in my previous email are performed (regarding correct format, posible errors, CAA Records, Google Safe Browsing list, ANF AC blocklist) to prevent an “invalid” request from proceeding. Because, it makes no sense to allow a request for an invalid domain to proceed, or for a domain with CAA RR containing unknown property tags with the Critical bit set, or with “issue” or “issuewild” that does not authorize issuance by ANF AC. Here, also a WHOIS lookup is made.

It is important, for the explanation further below, to indicate that in the request we also require the applicant's phone number.

Next, for each of the domains to be included, a drop-down email list is shown with the following options to choose from:
1) Constructed emails, using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' + @ + apex domain (which would be method 3.2.2.4.4)
2) Result of the WHOIS lookup previously made, for the “technical contact”, or “administrative contact” (which would be method 3.2.2.4.2). This is in case the content of said contact is in email format. If the content is protected by privacy it is not listed.

In the case of single-domain, when formalizing the request, two codes are sent via:
- Request confirmation email: Contains the request ID (numeric), a random alphanumeric code valid for 29 days, and a download link for “ANF Certificate Manager” program.
- SMS: Random code (code 2).

In “ANF Certificate Manager” the applicant must enter the request ID, the email code and the SMS code. The program then shows all the request information (applicant info, data of the subject, DNS to include in SAN…) and the applicant must give confirmation. Said request is then sent to ANF AC in order to validate the rest of the documentation (explained further below), and proceed, if favorable, to the issuance of the certificate.

NOTE: "ANF Certificate Manager" is a client desktop program that incorporates a tool so that the applicant can generate their key pair on their Windows PC. This makes it easier for the client to later download the issued certificate, and export to pfx if needed. Here I want to clarify that in NO case ANF AC generates the keys and returns them to the program, it is the program tool that generates the keys on the applicant's PC. (as I saw it was discussed at https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001949.html). We also allow the option for the user to provide CSR that was generated by their preferred means.

In case of multi-domain, it does not make sense to send N emails with instructions to download the program, since it only needs to be downloaded 1 time. Therefore, what the system does is: send the request confirmation email to one of the emails, and send an "additional" confirmation email to each email indicated for DVC purpose for each additional domain to include.

Said "additional" confirmation email, addressed to the domain administrator, informs them that [Applicant Data] has requested an SSL certificate for their domain [Domain] by [Request ID] request, and instructs them to access a link (valid for 29 days, the email indicates the expiration date) where they can manually confirm or reject the request by clicking Confirm/Reject buttons.

Evidence is collected as to whether the administrator of said domain confirmed or rejected, and it is received on the IRM platform. The IRM staff can see whether or not domain control was verified for each of the requested domains (they appear listed). If a DCV was rejected or was not verified, the request cannot proceed. Depending on the email that was used for DCV (chosen during the request), the BR method used is automatically recorded. The BR version used is set from the system, but is saved for each request.

In that same screen, IRM staff can see and manually verify the data and documentation of the organization and the applicant, and must attach evidence of identity verification. As, for example, in section 3.2.2.1. of the BRs several methods are allowed to verify the identity of the applicant; The IRM must select from a drop-down the method it has used (from those established in ANF AC CP) and attach evidence of it. I cannot find a possible way of automation for this, it must involve personnel trained in legal aspects, and it is unfortunately subject to potential human error.

Regards,
Pablo

[Ryan Sleevi]

On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Said "additional" confirmation email, addressed to the domain
> administrator, informs them that [Applicant Data] has requested an SSL
> certificate for their domain [Domain] by [Request ID] request, and
> instructs them to access a link (valid for 29 days, the email indicates the
> expiration date) where they can manually confirm or reject the request by
> clicking Confirm/Reject buttons.

Can you describe more here?

There are gaps here which seem to allow any number of insecure
implementations.

For example:
- 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)
- 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.

The reliance on 3.2.2.4.2 is also known to be dangerous (in that it relies
on human inspection or OCR of otherwise unstructured text), which is why
it's discouraged compared to other methods (like .7, .19, or .20, and if
using e-mail, .13, .14). It's unclear how you extract the emails from the
WHOIS results that you provide, and whether that's something the IRM
performs or whether that's somehow programmatically driven.

[Pablo Díaz]

> - 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

[Ben Wilson]

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-secur...@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.
>