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

[Ben Wilson via dev-security-policy]

On March 10, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store 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

that it fully understood the context and seriousness of such matters.  This
was followed with additional concerns expressed by the commenter
,
and additional responses from ANF

.

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

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 

Re: MOVING mozilla.dev.security.policy to dev-security-policy in Mozilla’s Google Workspace (formerly GSuite)

[Kathleen Wilson via dev-security-policy]

All,

I posted the first message to the new group, with subject "WELCOME to 
dev-security-policy".


If you do not receive the welcome message to the new group, you can 
subscribe to it by sending an email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben.


You can update your user settings and frequency of email messages via 
groups.google.com, or you can send an email to me and Ben to request 
that we update your settings in this new group.


Thanks,
Kathleen


On 3/25/21 9:55 AM, Kathleen Wilson wrote:

All,

This mozilla.dev.security.policy mailing list has been running on 
ancient custom-patched mailman software since the early Mozilla days. As 
many of you are aware, there are limitations and sometimes loss of data 
with the old configuration, so we are migrating this list to be hosted 
as a well-supported email-based Google Group under Mozilla's Google 
Workspace (formerly GSuite) account.


Currently this forum is accessed as follows:
  - Mailing List: dev-security-policy@lists.mozilla.org
  - Newsgroup: mozilla.dev.security.policy
  - Web: https://groups.google.com/g/mozilla.dev.security.policy
This list will be archived and changed to read-only on April 3, after 
which we will continue our conversations in the new list.


After the move, the access points will change to:
  - Mailing List: dev-security-pol...@mozilla.org
   -- dev-security-policy@lists.mozilla.org will automatically forward 
to the new mailing list

  - Group Name: dev-security-policy
  - Web: https://groups.google.com/a/mozilla.org/g/dev-security-policy
Note: Newsgroup access is deprecated and will no longer be an access point.

In the next week we will pre-populate the new group’s members list with 
the active users who subscribed to mozilla.dev.security.policy via 
lists.mozilla.org, and you will begin to receive email from the new 
dev-security-policy group as soon as messages are posted to it. You will 
then be able to update your user settings and frequency of email 
messages via groups.google.com, or you can send an email to me and Ben 
to request that we update your settings in this new group.


For mozilla.dev.security.policy we do not have visibility into 
subscribers from NNTP or Google Groups, so if you do not receive 
notifications from the new group, you may subscribe by sending email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben. This new 
group, dev-security-policy, is also public-facing via the web interface 
so you only need to subscribe to the new group if you intend to post 
messages or if you want to receive group conversations via email.


I will post another message here in mozilla.dev.security.policy when the 
new group is ready to use. At that point, we will archive this 
mozilla.dev.security.policy group such that no one will be able to post 
to this old group. Google has stated that data in this old group and the 
URLs to messages within this old group will remain as-is. From then on 
messages sent to dev-security-policy@lists.mozilla.org will be 
automatically forwarded to dev-security-pol...@mozilla.org.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy