MOVED mozilla.dev.security.policy to dev-security-policy

[Kathleen Wilson via dev-security-policy]

All,

This mozilla.dev.security.policy group has been moved to 
dev-security-policy in Mozilla’s Google Workspace (formerly GSuite).


New Access Points:
- 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.

This mozilla.dev.security.policy group is being archived and no more 
posts will be accepted in 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. Messages sent to dev-security-policy@lists.mozilla.org 
will be automatically forwarded to dev-security-pol...@mozilla.org.


We pre-populated the new group’s members list with the active users who 
subscribed to mozilla.dev.security.policy via lists.mozilla.org. If you 
have already been added to the new group as a member, then you should 
have received a message from the group. You can update your user 
settings and frequency of email messages via groups.google.com, or send 
an email to me and Ben.


If you have not received a message from the new dev-security-policy 
group, you may request to subscribe to the group by sending an email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben. This new 
group is also public-facing via the web interface, so you only need to 
join the group if you intend to post messages or if you want to receive 
group conversations via email.


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

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

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: Summary of Camerfirma's Compliance Issues

[Ryan Sleevi via dev-security-policy]

(Writing in a Google capacity)

In [1], we removed support in Camerfirma certificates, as previously
announced [2]. This included removing support for any subordinate CAs. As
announced, this was planned to roll out as part of the Chrome 90 release
schedule, scheduled to hit stable on 2021-04-06.

As with any CA removal, we’ve continued to examine ecosystem progress. When
appropriate, we've also reached out to specific organizations to understand
any challenges that might significantly impact our users. While we actively
discourage CAs and site operators from directly contacting us to request
exceptions, we do reach out to organizations that may significantly affect
a non-trivial number of users. This situation is particularly unique due to
the global pandemic, as several Portugese and Spanish government websites
related to COVID-19 are affected.

We've received confirmation from these organizations that they are on track
to migrate. These organizations have requested 1-2 additional weeks to
replace their certificates, beyond the three months since the original
announcement. Normally, we would not honor such requests, given the
industry standard expectations around certificate replacement being doable
in five days or less. However, the global pandemic has brought unique and
unprecedented challenges. Given the importance of these websites in helping
resolve this global health crisis, we’re inclined to provide that
additional migration support under these circumstances.

We plan to temporarily suspend the Camerfirma removal for at least the
first Chrome 90 release, to provide that additional time to migrate these
pandemic-related websites. Although we considered other technical
approaches, we believe this approach to be the least risky for this
situation. We’ll continue to work directly with these COVID-19 related
websites on their migration. We plan to remove trust no later than Chrome
91, but may remove it sooner, such as part of a Chrome 90 security update,
based on these migration efforts. This will not affect Chrome Beta, Dev,
and Canary channels, as they will continue to block certificates from the
Camerfirma hierarchy.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1173547
[2]
https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/iAUwcFioAQAJ

On Thu, Jan 28, 2021 at 10:39 PM Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Just to build on what Ryan said, and to clarify any confusion around the
> scope of Chrome’s action here - Chrome is no longer accepting Camerfirma
> certificates that are specifically used for *TLS server authentication* for
> websites.
>
> Our planned action is related to the certificates Chrome uses and
> verifies, which are only those used for TLS server authentication. This
> does include any type of certificate used in Chrome for TLS server
> authentication, including Qualified Website Authentication Certificates
> (QWACs) and certificates used to comply with the Revised Payment Services
> Directive (PSD2). However, it does not cover other use cases, such as TLS
> client certificates or the use of Qualified Certificates for digital
> signatures.
>
> In order to ensure Chrome’s response is comprehensive, the list of
> affected roots includes all of those operated by Camerfirma that have the
> technical capability to issue TLS server authentication certificates, even
> if those roots are not currently being used to issue TLS server
> authentication certificates. But please note that the changes we announced
> for Chrome will not impact the validity of these roots for other types of
> authentication, only current and future use of those roots for TLS server
> authentication in Chrome.
>
>
> On Monday, January 25, 2021 at 12:01:42 AM UTC-8, Ryan Sleevi wrote:
> > (Writing in a Google capacity)
> >
> > I personally want to say thanks to everyone who has contributed to this
> > discussion, who have reviewed or reported past incidents, and who have
> > continued to provide valuable feedback on current incidents. When
> > considering CAs and incidents, we really want to ensure we’re
> considering
> > all relevant information, as well as making sure we’ve got a correct
> > understanding of the details.
> >
> > After full consideration of the information available, and in order to
> > protect and safeguard Chrome users, certificates issued by AC Camerfirma
> SA
> > will no longer be accepted in Chrome, beginning with Chrome 90.
> >
> > This will be implemented via our existing mechanisms to respond to CA
> > incidents, via an integrated blocklist. Beginning with Chrome 90, users
> > that attempt to navigate to a website that uses a certificate that
> chains
> > to one of the roots detailed below will find that it is not considered
> > secure, with a message indicating that it has been revoked. Users and
> > enterprise administrators will not be able to bypass or override this
> > warning.
> >
> > This change will be 

Mozilla Root Store Policy MRSP 2.7.1 Update

[Ben Wilson via dev-security-policy]

All,

Version 2.7.1 of the Mozilla Root Store Policy (MRSP) is now saved in
Mozilla's GitHub repository with an effective date of May 1, 2021.
See https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
Here is the redline: https://github.com/mozilla/pkipolicy/pull/223/files

Soon we will publish it to
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
.

We are drafting a CA Communication and Survey to send out to CAs in the
root program within the next week.

Thanks,

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

Providing Auditor Qualifications (was Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications)

[Ben Wilson via dev-security-policy]

All,

Here, for your review and comment, is the final version of the wiki page
guidance on providing auditor qualifications. I appreciate the input we
received from ETSI and WebTrust audit groups on this current version.

https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications

Please also let me know if you have any questions.

Thanks,

Ben

On Fri, Mar 26, 2021 at 3:20 PM Ben Wilson  wrote:

> All,
> As discussed previously, here is a draft amendment to the Audit Statements
> wiki page for your review and comment:
>
> https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications
> Sincerely yours,
> Ben
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Prioritization of Root CA Inclusion Requests

[Ben Wilson via dev-security-policy]

For future reference, this is now posted here:
https://wiki.mozilla.org/CA/Prioritization.

On Wed, Mar 24, 2021 at 4:49 PM Ben Wilson  wrote:

> All,
>
> I'd like to have you review the prioritization proposal below, which will
> help us as we process CA inclusion requests. (
> https://wiki.mozilla.org/CA/Application_Process)
>
> Thanks,
>
> Ben
>
> ---
>
> Prioritization of CA Root Inclusion Requests will be based on the factors
> described below and use the P1-P5 Priority categories available in the
> Bugzilla system with our own priority categorization for the CA root
> inclusion program.
>
>-
>
>*P1 = High* (Applicant has good compliance history and is replacing an
>already-included root)
>
>
>-
>
>*P2 = Medium High* (Applicant is well-prepared and responsive, with a
>good history of policy compliance)
>
>
>-
>
>*P3 = Medium *(Applicant’s request and responsiveness are “average”,
>but demonstrates compliance with policies)
>
>
>-
>
>*P4 = Medium Low* (Applicant’s responsiveness and compliance history
>are “average”)
>
>
>-
>
>*P5 = Low *(Applicant has much work to do, is slow to respond to
>requests, or has not demonstrated full compliance with policies)
>
> Factors assessed in setting the above-referenced priorities, in order of
> importance, are:
>
> 1 - Alignment with Mozilla Manifesto -
> https://www.mozilla.org/en-US/about/manifesto/
>
> 2 - Compliance (Based on the compliance history of existing CA operators,
> and their responsiveness to issues)
> https://wiki.mozilla.org/CA/Incident_Dashboard
>
> 3 - Replacing Existing (Existing CA operators that are replacing an
> already-included root certificate)
> https://wiki.mozilla.org/CA/Certificate_Change_Process
>
> 4 -  Responsiveness/Complete and Timely (Applicant provides clear,
> complete, concise and timely responses to questions, comments, or concerns
> about their root inclusion request)
>
> 5 - Single-Purpose, Separate Roots (Hierarchies that are separated by
> root for a particular purpose)
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CA_Hierarchy
>
>
> 6 - CA Hierarchy Control (CA hierarchies comprised solely of CAs fully
> controlled by the applicant)
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates
>
>
> 7 - Completeness (Applicant completes all information in CCADB)
> https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case
>
> 8 - CPS Quality (Initially provided CP/CPS documents fully meet Mozilla’s
> Root Store Policy and the CAB Forum Baseline Requirements)
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS
>
>
> 9 - Updating Trust Bits or EV-Enablement of Already-Included Root
> Certificate (Existing CAs that are only requesting EV enablement or
> adding a trust bit to an already-included root certificate)
> https://wiki.mozilla.org/CA/Certificate_Change_Process#Enable_EV
>
> 10 - Ready (Detailed CP/CPS Review is complete and CA is “Ready for
> Discussion”)
> https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Job/Job Posting: Chrome Root Program

[Ryan Sleevi via dev-security-policy]

[Posting in a Google hat]

Several years ago [1], Kathleen opened a discussion about whether it would
be OK to post job opportunities here. While the discussion didn't come to a
firm conclusion, and there were those both for and against such postings, I
reached out to Ben and Kathleen to check that it would be OK before posting
this, and they shared that they were OK with it.

Emily (CC'd) was originally going to post this, but in light of [1], we
thought it might be better if I did. If you have any questions, you can
follow-up with Emily directly, and I'm always happy to connect you with
her, in the event you use a mail/newsgroup client that hides CCs here for
the message.

In case it's not obvious, this is the team I'm on here at Google. Given the
Chrome Root Program's goal [2] of continuing public collaboration here on
m.d.s.p., hopefully folks see this as directly relevant to this list :)

---

Chrome is hiring software engineers [3] and a TPM/PgM [4] interested in
security, PKI, applied crypto, and related topics in the Washington D.C.
area. These new hires will help build out Chrome's root program: managing
trust decisions in CAs, building and maintaining Chrome's certificate
verification and TLS stack, and building tooling and measurement software
for guiding policy decisions. This work is part of Chrome's Trusty
Transport team, with the full stack of HTTPS in scope, from BoringSSL to
TLS to the UI/UX of connection security. More broadly, the team is part of
the Chrome Trust and Safety org, which is growing the Washington D.C.
office rapidly this year, so there will be plenty of like-minded Chromies
around.

NOTE: The min qualifications listed in the software engineer posting are
exaggerated. We're hiring both senior and junior SWEs, so please apply if
you're interested, even if you don't meet the minimum qualifications listed.

---

[1]
https://groups.google.com/g/mozilla.dev.security.policy/c/dn0qEZrxbQA/m/h9ojtox6AgAJ
[2]
https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ
[3] https://careers.google.com/jobs/results/109182492218401478/
[4] https://careers.google.com/jobs/results/121728729358443206/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Update to Audit and Root Inclusion Cases March 25-29

[Kathleen Wilson via dev-security-policy]

All,

The CCADB update has been completed, and the "UNDER CONSTRUCTION" notice 
will be removed today.


There is still some cleanup that we will be doing, but you may proceed 
with using Audit Cases and Root Inclusion Cases now.


Please let me know if you run into any problems with the CCADB.

Thanks,
Kathleen


On 3/25/21 11:22 AM, Kathleen Wilson wrote:

All,

We will be applying updates to CCADB Audit Cases and Root Inclusion 
Cases starting tonight, March 25, and expected to be completed the 
afternoon of March 29.


We will post the following message on the CCADB home page while the 
updates are in progress.


--
UNDER CONSTRUCTION: Audit Cases and Root Inclusion Cases are being 
updated March 25 to March 29. Please avoid using them until this update 
had been completed. This message will be removed when the changes are done.

--

The goal of these updates is to extend Root Inclusion Cases to be usable 
by other root stores. After this update, both Apple and Mozilla will be 
able to use Root Inclusion Cases. There is a significant amount of code 
that is common to Audit Cases and Root Inclusion Cases, so Audit Cases 
will also be impacted during the update.


Please let me know if you have any questions about this, or run into 
other problems in the CCADB.


Thanks,
Kathleen



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

Re: Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

All,
As discussed previously, here is a draft amendment to the Audit Statements
wiki page for your review and comment:
https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications
Sincerely yours,
Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Update to Audit and Root Inclusion Cases March 25-29

[Kathleen Wilson via dev-security-policy]

All,

We will be applying updates to CCADB Audit Cases and Root Inclusion 
Cases starting tonight, March 25, and expected to be completed the 
afternoon of March 29.


We will post the following message on the CCADB home page while the 
updates are in progress.


--
UNDER CONSTRUCTION: Audit Cases and Root Inclusion Cases are being 
updated March 25 to March 29. Please avoid using them until this update 
had been completed. This message will be removed when the changes are done.

--

The goal of these updates is to extend Root Inclusion Cases to be usable 
by other root stores. After this update, both Apple and Mozilla will be 
able to use Root Inclusion Cases. There is a significant amount of code 
that is common to Audit Cases and Root Inclusion Cases, so Audit Cases 
will also be impacted during the update.


Please let me know if you have any questions about this, or run into 
other problems in the CCADB.


Thanks,
Kathleen

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

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

[Kathleen Wilson via dev-security-policy]

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

Prioritization of Root CA Inclusion Requests

[Ben Wilson via dev-security-policy]

All,

I'd like to have you review the prioritization proposal below, which will
help us as we process CA inclusion requests. (
https://wiki.mozilla.org/CA/Application_Process)

Thanks,

Ben

---

Prioritization of CA Root Inclusion Requests will be based on the factors
described below and use the P1-P5 Priority categories available in the
Bugzilla system with our own priority categorization for the CA root
inclusion program.

   -

   *P1 = High* (Applicant has good compliance history and is replacing an
   already-included root)


   -

   *P2 = Medium High* (Applicant is well-prepared and responsive, with a
   good history of policy compliance)


   -

   *P3 = Medium *(Applicant’s request and responsiveness are “average”, but
   demonstrates compliance with policies)


   -

   *P4 = Medium Low* (Applicant’s responsiveness and compliance history are
   “average”)


   -

   *P5 = Low *(Applicant has much work to do, is slow to respond to
   requests, or has not demonstrated full compliance with policies)

Factors assessed in setting the above-referenced priorities, in order of
importance, are:

1 - Alignment with Mozilla Manifesto -
https://www.mozilla.org/en-US/about/manifesto/

2 - Compliance (Based on the compliance history of existing CA operators,
and their responsiveness to issues)
https://wiki.mozilla.org/CA/Incident_Dashboard

3 - Replacing Existing (Existing CA operators that are replacing an
already-included root certificate)
https://wiki.mozilla.org/CA/Certificate_Change_Process

4 -  Responsiveness/Complete and Timely (Applicant provides clear,
complete, concise and timely responses to questions, comments, or concerns
about their root inclusion request)

5 - Single-Purpose, Separate Roots (Hierarchies that are separated by root
for a particular purpose)
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CA_Hierarchy

6 - CA Hierarchy Control (CA hierarchies comprised solely of CAs fully
controlled by the applicant)
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates


7 - Completeness (Applicant completes all information in CCADB)
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

8 - CPS Quality (Initially provided CP/CPS documents fully meet Mozilla’s
Root Store Policy and the CAB Forum Baseline Requirements)
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS


9 - Updating Trust Bits or EV-Enablement of Already-Included Root
Certificate (Existing CAs that are only requesting EV enablement or adding
a trust bit to an already-included root certificate)
https://wiki.mozilla.org/CA/Certificate_Change_Process#Enable_EV

10 - Ready (Detailed CP/CPS Review is complete and CA is “Ready for
Discussion”)
https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

dev-security list is coming to an end

[Daniel Veditz]

Mozilla's "mailman" servers, and the crazy mail/NNTP/WebForums mirroring,
are being decommissioned soon and this list will no longer work. Most such
lists are being migrated to https://discourse.mozilla.org for web-based
forums, but as there are already discussions on this topic there this list
is not being migrated as-is.

To continue Mozilla-related security discussions please continue on at

"web" forums:
https://discourse.mozilla.org/c/security/
https://discourse.mozilla.org/tags/c/firefox-development/privacy-and-security

"chat" on Matrix
https://chat.mozilla.org/#/room/#security:mozilla.org
(there are also dedicated desktop and mobile matrix clients that will work)

Thank you,
-Dan Veditz
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Support for EdDSA

[Daniel Veditz]

For NSS-specific development questions you should try in the
dev-tech-crypto mailing list, or the matrix chat at
https://chat.mozilla.org/#/room/#nss:mozilla.org

-Dan Veditz

On Thu, Mar 18, 2021 at 4:50 AM Rishabh Kumar via dev-security <
dev-security@lists.mozilla.org> wrote:

> Hello All,
>
> I am working on a GSOC proposal for Libreswan in which the authentication
> mechanism is extended to support EdDSA. Since the Libreswan is dependent on
> NSS for algorithm implementation it is necessary that NSS supports EdDSA.
>
> Does anybody  have any idea regarding the plans for adding EdDSA in the NSS
> library. I would be happy to contribute if you can describe the
> requirements for implementing EdDSA.
>
> Regards,
>
>
> --
> Rishabh Kumar
> M.Tech(RA)
> Department of Computer Science and Technology
> Indian Institute of Technology, Hyderabad
> E-mail ID:- cs19mtech11...@iith.ac.in
>
> --
>
>
> Disclaimer:- This footer text is to convey that this email is sent by one
> of the users of IITH. So, do not mark it as SPAM.
> ___
> dev-security mailing list
> dev-security@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: New intermediate certs and Audit Statements

[Kathleen Wilson via dev-security-policy]

On 3/24/21 5:32 AM, Rob Stradling wrote:

On 9th July 2019, Kathleen wrote:

I propose that to handle this situation, the CA may enter the

subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements.

Hi Kathleen.  CCADB now automatically shows the following message (when 
relevant) in red text at the top of each intermediate certificate page:

 "This certificate was created after the audit period of the current audit 
statement, so please make sure to include it in the CA's next periodic audit 
statement."

Do you still expect CAs to "use the Public Comment field to indicate that the new 
certificate will be included in the next audit statements"?
Or may we stop doing that now?

Thanks.



Rob, Thanks for bringing this up. I agree that it is not necessary to 
use the Public Comment field to indicate that the new certificate will 
be included in the next audit statements. CAs may stop doing that.


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

Re: New intermediate certs and Audit Statements

[Rob Stradling via dev-security-policy]

On 9th July 2019, Kathleen wrote:
> I propose that to handle this situation, the CA may enter the
subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements.

Hi Kathleen.  CCADB now automatically shows the following message (when 
relevant) in red text at the top of each intermediate certificate page:

"This certificate was created after the audit period of the current audit 
statement, so please make sure to include it in the CA's next periodic audit 
statement."

Do you still expect CAs to "use the Public Comment field to indicate that the 
new certificate will be included in the next audit statements"?
Or may we stop doing that now?

Thanks.


From: dev-security-policy  on 
behalf of Kathleen Wilson via dev-security-policy 

Sent: 09 July 2019 22:50
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: New intermediate certs and Audit Statements

All,

There is some confusion about disclosure of new intermediate certs that
are issued to subordinate CAs with currently valid audit statements.

Section 5.3.2 of Mozilla's Root Store Policy says: "If the CA has a
currently valid audit report at the time of creation of the certificate,
then the new certificate MUST appear on the CA's next periodic audit
reports."

I think it is reasonable to assume that the same policy applies to
subordinate CAs, such that if the subordinate CA has a currently valid
audit report at the time of creation of a new intermediate certificate,
then the new certificate MUST appear on the subordinate CA's next
periodic audit reports.

The confusion is about how to disclose such a new intermediate
certificate in the CCADB.

I propose that to handle this situation, the CA may enter the
subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements. (Also, a quick comparison of the cert's Valid-From
date and the audit period dates will indicate this situation.)

Please let me know if you foresee any problems with this approach.

Thanks,
Kathleen
___
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

Public Discussion of Asseco's Root Inclusion Request

[Ben Wilson via dev-security-policy]

Dear All,

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for the *Certum Trusted Root CA* and
the *Certum
EC-384 CA*.  See
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9).

These two (2) new root CA certificates were created in 2018 and are valid
until 2043. They are proposed for inclusion with the email trust bit, the
websites bit, and EV enabled.

The root CAs are run by an existing CA operator in the Mozilla Root Program
- Asseco Data Services (“Asseco”), part of the Asseco Group.

Asseco's CA inclusion application has been tracked in the CCADB and in
Bugzilla–

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

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

Mozilla is considering approving Asseco’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:*

*Certum Trusted Root CA *

crt.sh –

https://crt.sh/?q=FE7696573855773E37A95E7AD4D9CC96C30157C15D31765BA9B15704E1AE78FD

https://crt.sh/?id=2224039330

Download - http://repository.certum.pl/ctrca.pem

*Certum EC-384 CA *

crt.sh –

https://crt.sh/?q=6B328085625318AA50D173C98D8BDA09D57E27413D114CF787A0F5D06C030CF6

https://crt.sh/?id=2224044393

Download - https://repository.certum.pl/cec384ca.pem


*CP/CPS:*

Current CP is Version 4.5, dated 19-Feb-2020.

https://files.certum.eu/documents/repsitory/2-cert-policy/CCP-DK02-ZK01-CP-Cert-Serv-4.5.pdf

Current CPS is Version 6.9, dated 21-December-2020.

https://files.certum.eu/documents/repsitory/3-cert-pract-state/CCP-DK02-ZK02-CPS-Cert-6.9.pdf

My review comments to CPS version 6.9 can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1598577#c14.



Document repository location(s):

https://www.certum.eu/en/repository/

https://www.certum.pl/pl/repozytorium/


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

https://bugzilla.mozilla.org/attachment.cgi?id=993


*Audits:*

Asseco received favorable WebTrust audits (Standard, Baseline, and EV) from
Ernst & Young sp. z o.o. (E).  These were issued on May 18, 2020.  Asseco’s
most recently ended audit period ended on February 10, 2021, and Asseco
expects to receive audit letters for that audit period sometime in April
2021.

*Incidents: *

For your review, past incidents filed between 2018-2020, now closed,
involving Asseco include the following:

1433118 
Certificate
with compromised private key not revoked

1435770 
Non-BR-Compliant
Issuance - Debian Weak Keys

1451228  EV
certificate mis-issue

1495518 
Unallowed
key usage for EC public key (Key Encipherment)

1511459 
Corrupted
certificates

1518560  Use
of forbidden subjectPublicKeyInfo algorithm

1524195 
Invalid
dnsNames

1550575 
commonName
not from subjectAltName entries

1566586 
Overdue
Audit Statements 2019

1567062 
Inconsistent
disclosure of externally-operated intermediate

1598277  CA
certificates not listed in audit report

1600158 
Failure
to revoke intermediate certificates within the BR time period

1600301  EV
Certificates issued with wrong Business Category

1611458 
Invalid
value in SAN dNSName

1639502 
Incorrect
OCSP response encoding

1667684 
Failure
to provide a preliminary report within 24 hours.

1667986 
Invalid
stateOrProvinceName field

1668523 
Failure
to revoke within 5 days



*Test Results**:*

These CAs, and their associated test certificates, were checked for
revocation processing, misissuances, and EV compatibility, and they passed
those tests.


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



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

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

Hi Doug,
It means the same thing as in the BRs. I am processing this change on a
parallel track with adding language to the BRs (Ballot SC42) because
neither change is a done deal yet.  We'll leave it in for now, not to say
that we won't eventually remove it in a subsequent update.
Thanks,
Ben

On Fri, Mar 19, 2021 at 10:26 AM Ryan Sleevi  wrote:

> The S/MIME BRs are not yet a thing, while the current language covers such
> CAs (as a condition of Mozilla inclusion)
>
> On Fri, Mar 19, 2021 at 6:45 AM Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Thanks Ben.
>>
>>
>>
>> What’s the purpose of this statement:
>>
>> 5. verify that all of the information that is included in server
>> certificates remains current and correct at intervals of 825 days or less;
>>
>>
>>
>> The BRs limit data reuse to 825 days since March 2018 so I don’t think
>> this adds anything.  If it does mean something more than that, can you
>> update to make it more clear?
>>
>>
>>
>>
>>
>> From: Ben Wilson 
>> Sent: Thursday, March 18, 2021 2:53 PM
>> To: Doug Beattie 
>> Cc: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>>
>>
>>
>> I've edited the proposed subsection 5.1 and have left section 5 in for
>> now.  See
>>
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232
>>
>>
>>
>> On Tue, Mar 16, 2021 at 9:10 AM Ben Wilson > bwil...@mozilla.com> > wrote:
>>
>> That works, too.  Thoughts?
>>
>>
>>
>> On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie >  > wrote:
>>
>> Hi Ben,
>>
>> Regarding the redlined spec:
>> https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6
>>
>> Is this a meaningful statement given max validity is 398 days now?
>>5. verify that all of the information that is included in server
>> certificates remains current and correct at intervals of 825 days or less;
>> I think we can remove that and them move 5.1 to item 5
>>
>> I find the words for this requirement 5.1 unclear.
>>
>>   " 5.1. for server certificates issued on or after October 1, 2021,
>> verify each dNSName or IPAddress in a SAN or commonName at an interval of
>> 398 days or less;"
>>
>> Can we say:
>> "5.1. for server certificates issued on or after October 1, 2021, each
>> dNSName or IPAddress in a SAN or commonName MUST have been validated > accordance with the CABF Baseline Requirements?> within the prior 398 days.
>>
>>
>>
>> -Original Message-
>> From: dev-security-policy >  > On Behalf Of
>> Ben Wilson via dev-security-policy
>> Sent: Monday, March 8, 2021 6:38 PM
>> To: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org > mozilla-dev-security-pol...@lists.mozilla.org> >
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>>
>> All,
>>
>> Here is the currently proposed wording for subsection 5.1 of MRSP section
>> 2.1:
>>
>> " 5.1. for server certificates issued on or after October 1, 2021, verify
>> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
>> or less;"
>>
>> Ben
>>
>> On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi > r...@sleevi.com> > wrote:
>>
>> >
>> >
>> > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org > dev-security-policy@lists.mozilla.org> > wrote:
>> >
>> >> I think it makes sense to separate out the date for domain validation
>> >> expiration from the issuance of server certificates with previously
>> >> validated domain names, but agree with Ben that the timeline doesn’t
>> >> seem to need to be prolonged. What about something like this:
>> >>
>> >> 1. Domain name or IP address verifications performed on or after July
>> >> 1,
>> >> 2021 may be reused for a maximum of 398 days.
>> >> 2. Server certificates issued on or after September 1, 2021 must have
>> >> completed domain name or IP address verification within the preceding
>> >> 398 days.
>> >>
>> >> This effectively stretches the “cliff” out across ~6 months (now
>> >> through the end of August), which seems reasonable.
>> >>
>> >
>> > Yeah, that does sound reasonable.
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org > 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
>>
>
___
dev-security-policy mailing list

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ryan Sleevi via dev-security-policy]

The S/MIME BRs are not yet a thing, while the current language covers such
CAs (as a condition of Mozilla inclusion)

On Fri, Mar 19, 2021 at 6:45 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Ben.
>
>
>
> What’s the purpose of this statement:
>
> 5. verify that all of the information that is included in server
> certificates remains current and correct at intervals of 825 days or less;
>
>
>
> The BRs limit data reuse to 825 days since March 2018 so I don’t think
> this adds anything.  If it does mean something more than that, can you
> update to make it more clear?
>
>
>
>
>
> From: Ben Wilson 
> Sent: Thursday, March 18, 2021 2:53 PM
> To: Doug Beattie 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
>
>
> I've edited the proposed subsection 5.1 and have left section 5 in for
> now.  See
>
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232
>
>
>
> On Tue, Mar 16, 2021 at 9:10 AM Ben Wilson  bwil...@mozilla.com> > wrote:
>
> That works, too.  Thoughts?
>
>
>
> On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie   > wrote:
>
> Hi Ben,
>
> Regarding the redlined spec:
> https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6
>
> Is this a meaningful statement given max validity is 398 days now?
>5. verify that all of the information that is included in server
> certificates remains current and correct at intervals of 825 days or less;
> I think we can remove that and them move 5.1 to item 5
>
> I find the words for this requirement 5.1 unclear.
>
>   " 5.1. for server certificates issued on or after October 1, 2021,
> verify each dNSName or IPAddress in a SAN or commonName at an interval of
> 398 days or less;"
>
> Can we say:
> "5.1. for server certificates issued on or after October 1, 2021, each
> dNSName or IPAddress in a SAN or commonName MUST have been validated  accordance with the CABF Baseline Requirements?> within the prior 398 days.
>
>
>
> -Original Message-
> From: dev-security-policy   > On Behalf Of Ben
> Wilson via dev-security-policy
> Sent: Monday, March 8, 2021 6:38 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org  mozilla-dev-security-pol...@lists.mozilla.org> >
> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
> All,
>
> Here is the currently proposed wording for subsection 5.1 of MRSP section
> 2.1:
>
> " 5.1. for server certificates issued on or after October 1, 2021, verify
> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
> or less;"
>
> Ben
>
> On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  r...@sleevi.com> > wrote:
>
> >
> >
> > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org> > wrote:
> >
> >> I think it makes sense to separate out the date for domain validation
> >> expiration from the issuance of server certificates with previously
> >> validated domain names, but agree with Ben that the timeline doesn’t
> >> seem to need to be prolonged. What about something like this:
> >>
> >> 1. Domain name or IP address verifications performed on or after July
> >> 1,
> >> 2021 may be reused for a maximum of 398 days.
> >> 2. Server certificates issued on or after September 1, 2021 must have
> >> completed domain name or IP address verification within the preceding
> >> 398 days.
> >>
> >> This effectively stretches the “cliff” out across ~6 months (now
> >> through the end of August), which seems reasonable.
> >>
> >
> > Yeah, that does sound reasonable.
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org  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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Doug Beattie via dev-security-policy]

Thanks Ben.

 

What’s the purpose of this statement:

5. verify that all of the information that is included in server certificates 
remains current and correct at intervals of 825 days or less;

 

The BRs limit data reuse to 825 days since March 2018 so I don’t think this 
adds anything.  If it does mean something more than that, can you update to 
make it more clear?

 

 

From: Ben Wilson  
Sent: Thursday, March 18, 2021 2:53 PM
To: Doug Beattie 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name 
verification to 398 days

 

I've edited the proposed subsection 5.1 and have left section 5 in for now.  
See 

https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232
 

 

On Tue, Mar 16, 2021 at 9:10 AM Ben Wilson mailto:bwil...@mozilla.com> > wrote:

That works, too.  Thoughts?

 

On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

Hi Ben,

Regarding the redlined spec: 
https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6

Is this a meaningful statement given max validity is 398 days now? 
   5. verify that all of the information that is included in server 
certificates remains current and correct at intervals of 825 days or less;
I think we can remove that and them move 5.1 to item 5

I find the words for this requirement 5.1 unclear. 

  " 5.1. for server certificates issued on or after October 1, 2021, verify 
each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or 
less;"

Can we say:
"5.1. for server certificates issued on or after October 1, 2021, each dNSName 
or IPAddress in a SAN or commonName MUST have been validated  within the prior 398 days.



-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Ben 
Wilson via dev-security-policy
Sent: Monday, March 8, 2021 6:38 PM
To: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name 
verification to 398 days

All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify each 
dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

Ben

On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi mailto:r...@sleevi.com> > wrote:

>
>
> On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy < 
> dev-security-policy@lists.mozilla.org 
>  > wrote:
>
>> I think it makes sense to separate out the date for domain validation 
>> expiration from the issuance of server certificates with previously 
>> validated domain names, but agree with Ben that the timeline doesn’t 
>> seem to need to be prolonged. What about something like this:
>>
>> 1. Domain name or IP address verifications performed on or after July 
>> 1,
>> 2021 may be reused for a maximum of 398 days.
>> 2. Server certificates issued on or after September 1, 2021 must have 
>> completed domain name or IP address verification within the preceding 
>> 398 days.
>>
>> This effectively stretches the “cliff” out across ~6 months (now 
>> through the end of August), which seems reasonable.
>>
>
> Yeah, that does sound reasonable.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
 
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

I've edited the proposed subsection 5.1 and have left section 5 in for
now.  See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/d37d7a3865035c958c1cb139b949107665fee232

On Tue, Mar 16, 2021 at 9:10 AM Ben Wilson  wrote:

> That works, too.  Thoughts?
>
> On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie 
> wrote:
>
>> Hi Ben,
>>
>> Regarding the redlined spec:
>> https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6
>>
>> Is this a meaningful statement given max validity is 398 days now?
>>5. verify that all of the information that is included in server
>> certificates remains current and correct at intervals of 825 days or less;
>> I think we can remove that and them move 5.1 to item 5
>>
>> I find the words for this requirement 5.1 unclear.
>>
>>   " 5.1. for server certificates issued on or after October 1, 2021,
>> verify each dNSName or IPAddress in a SAN or commonName at an interval of
>> 398 days or less;"
>>
>> Can we say:
>> "5.1. for server certificates issued on or after October 1, 2021, each
>> dNSName or IPAddress in a SAN or commonName MUST have been validated > accordance with the CABF Baseline Requirements?> within the prior 398 days.
>>
>>
>>
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Monday, March 8, 2021 6:38 PM
>> To: mozilla-dev-security-policy <
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>>
>> All,
>>
>> Here is the currently proposed wording for subsection 5.1 of MRSP section
>> 2.1:
>>
>> " 5.1. for server certificates issued on or after October 1, 2021, verify
>> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
>> or less;"
>>
>> Ben
>>
>> On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  wrote:
>>
>> >
>> >
>> > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> I think it makes sense to separate out the date for domain validation
>> >> expiration from the issuance of server certificates with previously
>> >> validated domain names, but agree with Ben that the timeline doesn’t
>> >> seem to need to be prolonged. What about something like this:
>> >>
>> >> 1. Domain name or IP address verifications performed on or after July
>> >> 1,
>> >> 2021 may be reused for a maximum of 398 days.
>> >> 2. Server certificates issued on or after September 1, 2021 must have
>> >> completed domain name or IP address verification within the preceding
>> >> 398 days.
>> >>
>> >> This effectively stretches the “cliff” out across ~6 months (now
>> >> through the end of August), which seems reasonable.
>> >>
>> >
>> > Yeah, that does sound reasonable.
>> >
>> ___
>> 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

RE:Support for EdDSA

[Avas Flowers]

NOTICE: This email is not monitored. This email is used for communications tied to Avas Flowers Customer Support ticket system. If you require customer support and would like to create a ticket, please visit www.avasflowers.net/customersupport and select the option that best suits your needs.
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Support for EdDSA

[Rishabh Kumar via dev-security]

Hello All,

I am working on a GSOC proposal for Libreswan in which the authentication
mechanism is extended to support EdDSA. Since the Libreswan is dependent on
NSS for algorithm implementation it is necessary that NSS supports EdDSA.

Does anybody  have any idea regarding the plans for adding EdDSA in the NSS
library. I would be happy to contribute if you can describe the
requirements for implementing EdDSA.

Regards,


-- 
Rishabh Kumar
M.Tech(RA)
Department of Computer Science and Technology
Indian Institute of Technology, Hyderabad
E-mail ID:- cs19mtech11...@iith.ac.in

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

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

[Pablo Díaz via dev-security-policy]

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2021 Audit Reminder Emails
Date: Tue, 16 Mar 2021 19:02:12 + (GMT)

Mozilla: Audit Reminder
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239757

Standard Audit Period End Date: 2020-02-07
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239758

BR Audit Period End Date: 2020-02-07
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3**
   Hongkong Post Root CA 1**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239021

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239022

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239023

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   AC RAIZ FNMT-RCM SERVIDORES SEGUROS
   FNMT-RCM - SHA256
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

Standard Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
EV Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

EV Audit Period End Date: 2020-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA**
   TWCA Root Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238799

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238801

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189

Standard Audit Period End Date: 2020-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189
BR Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
Root Certificates:
   Certum Trusted Network CA 2
   Certum CA
   Certum Trusted Network CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239794

Standard Audit Period End Date: 2020-02-10
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239795

BR Audit Period End Date: 2020-02-10
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239796

EV Audit Period End Date: 2020-02-10
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden EV Root CA
Standard Audit: 

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

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy <
dev-security-policy@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 hostmaster@apex1.example could approve a request
for apex2.example, yet, as currently described, that seems to be possible,
in that both hostmaster@apex1.example and hostmaster@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Pablo Díaz via dev-security-policy]

> 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 

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

That works, too.  Thoughts?

On Tue, Mar 16, 2021 at 5:21 AM Doug Beattie 
wrote:

> Hi Ben,
>
> Regarding the redlined spec:
> https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6
>
> Is this a meaningful statement given max validity is 398 days now?
>5. verify that all of the information that is included in server
> certificates remains current and correct at intervals of 825 days or less;
> I think we can remove that and them move 5.1 to item 5
>
> I find the words for this requirement 5.1 unclear.
>
>   " 5.1. for server certificates issued on or after October 1, 2021,
> verify each dNSName or IPAddress in a SAN or commonName at an interval of
> 398 days or less;"
>
> Can we say:
> "5.1. for server certificates issued on or after October 1, 2021, each
> dNSName or IPAddress in a SAN or commonName MUST have been validated  accordance with the CABF Baseline Requirements?> within the prior 398 days.
>
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Monday, March 8, 2021 6:38 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
> All,
>
> Here is the currently proposed wording for subsection 5.1 of MRSP section
> 2.1:
>
> " 5.1. for server certificates issued on or after October 1, 2021, verify
> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
> or less;"
>
> Ben
>
> On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  wrote:
>
> >
> >
> > On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> I think it makes sense to separate out the date for domain validation
> >> expiration from the issuance of server certificates with previously
> >> validated domain names, but agree with Ben that the timeline doesn’t
> >> seem to need to be prolonged. What about something like this:
> >>
> >> 1. Domain name or IP address verifications performed on or after July
> >> 1,
> >> 2021 may be reused for a maximum of 398 days.
> >> 2. Server certificates issued on or after September 1, 2021 must have
> >> completed domain name or IP address verification within the preceding
> >> 398 days.
> >>
> >> This effectively stretches the “cliff” out across ~6 months (now
> >> through the end of August), which seems reasonable.
> >>
> >
> > Yeah, that does sound reasonable.
> >
> ___
> 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

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Doug Beattie via dev-security-policy]

Hi Ben,

Regarding the redlined spec: 
https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1?short_path=73f95f7#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6

Is this a meaningful statement given max validity is 398 days now? 
   5. verify that all of the information that is included in server 
certificates remains current and correct at intervals of 825 days or less;
I think we can remove that and them move 5.1 to item 5

I find the words for this requirement 5.1 unclear. 

  " 5.1. for server certificates issued on or after October 1, 2021, verify 
each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or 
less;"

Can we say:
"5.1. for server certificates issued on or after October 1, 2021, each dNSName 
or IPAddress in a SAN or commonName MUST have been validated  within the prior 398 days.



-Original Message-
From: dev-security-policy  On 
Behalf Of Ben Wilson via dev-security-policy
Sent: Monday, March 8, 2021 6:38 PM
To: mozilla-dev-security-policy 
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name 
verification to 398 days

All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify each 
dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

Ben

On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  wrote:

>
>
> On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I think it makes sense to separate out the date for domain validation 
>> expiration from the issuance of server certificates with previously 
>> validated domain names, but agree with Ben that the timeline doesn’t 
>> seem to need to be prolonged. What about something like this:
>>
>> 1. Domain name or IP address verifications performed on or after July 
>> 1,
>> 2021 may be reused for a maximum of 398 days.
>> 2. Server certificates issued on or after September 1, 2021 must have 
>> completed domain name or IP address verification within the preceding 
>> 398 days.
>>
>> This effectively stretches the “cliff” out across ~6 months (now 
>> through the end of August), which seems reasonable.
>>
>
> Yeah, that does sound reasonable.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Andrew Ayer via dev-security-policy]

On Fri, 12 Mar 2021 04:57:56 -0800 (PST)
Pablo D__az via dev-security-policy
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Pablo Díaz via dev-security-policy]

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, 

Re: Clarification request: ECC subCAs under RSA Root

[Peter Bowen via dev-security-policy]

On Thu, Mar 11, 2021 at 12:01 AM pfuen...--- via dev-security-policy
 wrote:
>
> In summary, my understanding is that we can ignore that illustrative control 
> of the Webtrust Criteria and that the community is cool with these 
> subordinations of CAs with stronger keys (same or different algorithm).

Illustrative controls in WebTrust are not the principles and criteria,
which are the requirements.  Illustrative controls are just examples
of things that CAs _might_ choose to do.  They might also choose to do
different things, which is fine as long as the things they do meet the
criteria.

As you read through the WebTrust Principles and Criteria for
Certification Authorities, you should also note that some principles
and some criteria are notated with "if supported" or "if applicable".
Not having controls that cover these is also usually fine, as long as
you disclose that you do not do them.  For example, many CAs in the
Mozilla program do not issue Integrated Circuit Cards (also called
"smart cards"), so WebTrust for CAs criteria 5.3 is not applicable;
instead the management assertion can simply state that the CA does not
issue ICCs.

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

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

[Andrew Ayer via dev-security-policy]

On Wed, 10 Mar 2021 13:43:55 -0700
Ben Wilson via dev-security-policy
 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  and
.
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

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Bruce,
The answer would be yes because we check the validity of the root CA
certificate and other CA certificates.
Ben



On Thu, Mar 11, 2021 at 10:33 AM Ben Wilson  wrote:

> Hi Bruce,
> I think the answer is yes. A CA certificate is no longer trusted once it
> has expired or been revoked (or added to OneCRL for subCAs) or removed
> (roots). But I'm double-checking on the case of certificates with validity
> periods that extend past the expiration of the root.
> Ben
>
> On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com
>> wrote:
>> > Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
>> keys.
>> > The intent was to cover this scenario. We are aware that CAs might
>> > generate 1000s of keys in a partition and then years later assign a few
>> of
>> > them as CA keys, others as OCSP responder keys, etc., and some might
>> never
>> > be used. Presumably each of the keys would have an identifier and the
>> CA
>> > operator would maintain a list of those key identifiers for each
>> partition.
>> > The goal is to have an audited chain of custody for the keys, which
>> could
>> > also be based on the physical and logical protection of the HSM that is
>> > holding them.
>> > Key lifecycle documentation would consist of a documented key
>> generation
>> > ceremony (where such documentation is reviewed by an auditor). Then,
>> > annually an auditor would review storage and access records for the
>> HSM(s)
>> > and the list of keys to see which ones had been used for CAs and which
>> ones
>> > had not. Then, as keys were destroyed (or if not, when the HSM is
>> zeroized
>> > at the end of the HSM's lifecycle), there would be an attestation of
>> key
>> > destruction that would be covered by an audit/auditor's statement.
>> > On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
>> > dev-secur...@lists.mozilla.org> wrote:
>> >
>>
>> One more question for clarification as I want to make sure we understand
>> how to get our practices updated to meet the Mozilla Policy. The
>> requirement states "until the CA certificate is no longer trusted by
>> Mozilla's root store." Can we confirm that a CA certificate is no longer
>> trusted by the Mozilla root store if 1) it has expired or 2) it has been
>> revoked and the OneCRL has been updated. Of course Mozilla may have other
>> ways to no longer trust a CA certificate.
>> ___
>> 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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Hi Bruce,
I think the answer is yes. A CA certificate is no longer trusted once it
has expired or been revoked (or added to OneCRL for subCAs) or removed
(roots). But I'm double-checking on the case of certificates with validity
periods that extend past the expiration of the root.
Ben

On Thu, Mar 11, 2021 at 7:28 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> > Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
> keys.
> > The intent was to cover this scenario. We are aware that CAs might
> > generate 1000s of keys in a partition and then years later assign a few
> of
> > them as CA keys, others as OCSP responder keys, etc., and some might
> never
> > be used. Presumably each of the keys would have an identifier and the CA
> > operator would maintain a list of those key identifiers for each
> partition.
> > The goal is to have an audited chain of custody for the keys, which
> could
> > also be based on the physical and logical protection of the HSM that is
> > holding them.
> > Key lifecycle documentation would consist of a documented key generation
> > ceremony (where such documentation is reviewed by an auditor). Then,
> > annually an auditor would review storage and access records for the
> HSM(s)
> > and the list of keys to see which ones had been used for CAs and which
> ones
> > had not. Then, as keys were destroyed (or if not, when the HSM is
> zeroized
> > at the end of the HSM's lifecycle), there would be an attestation of key
> > destruction that would be covered by an audit/auditor's statement.
> > On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
>
> One more question for clarification as I want to make sure we understand
> how to get our practices updated to meet the Mozilla Policy. The
> requirement states "until the CA certificate is no longer trusted by
> Mozilla's root store." Can we confirm that a CA certificate is no longer
> trusted by the Mozilla root store if 1) it has expired or 2) it has been
> revoked and the OneCRL has been updated. Of course Mozilla may have other
> ways to no longer trust a CA certificate.
> ___
> 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

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

[Ben Wilson via dev-security-policy]

Here you go:

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

On Thu, Mar 11, 2021 at 6:38 AM Andrey West Siberia via dev-security-policy
 wrote:

> Hello,
> I can't find the test URIs for this root certificate...
> ___
> 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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Bruce via dev-security-policy]

On Saturday, March 6, 2021 at 11:17:53 PM UTC-5, bwi...@mozilla.com wrote:
> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys. 
> The intent was to cover this scenario. We are aware that CAs might 
> generate 1000s of keys in a partition and then years later assign a few of 
> them as CA keys, others as OCSP responder keys, etc., and some might never 
> be used. Presumably each of the keys would have an identifier and the CA 
> operator would maintain a list of those key identifiers for each partition. 
> The goal is to have an audited chain of custody for the keys, which could 
> also be based on the physical and logical protection of the HSM that is 
> holding them. 
> Key lifecycle documentation would consist of a documented key generation 
> ceremony (where such documentation is reviewed by an auditor). Then, 
> annually an auditor would review storage and access records for the HSM(s) 
> and the list of keys to see which ones had been used for CAs and which ones 
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized 
> at the end of the HSM's lifecycle), there would be an attestation of key 
> destruction that would be covered by an audit/auditor's statement.
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 

One more question for clarification as I want to make sure we understand how to 
get our practices updated to meet the Mozilla Policy. The requirement states 
"until the CA certificate is no longer trusted by Mozilla's root store." Can we 
confirm that a CA certificate is no longer trusted by the Mozilla root store if 
1) it has expired or 2) it has been revoked and the OneCRL has been updated. Of 
course Mozilla may have other ways to no longer trust a CA certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Andrey West Siberia via dev-security-policy]

Hello,
I can't find the test URIs for this root certificate...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Wanko Clemens via dev-security-policy]

Dear Ben, Dear Kahtleen,

 

we suppose, there are no other changes intendent then apart from what you say 
below? 

If the rest of section 3.2 remains as it is, the specific matter of the ETSI 
auditor qualification would be addressed through the referrer back to BRG 
section 8.2. It would then read like this, which is okay for us: 

 

"3.2 Auditors

In normal circumstances, Mozilla requires that audits MUST be performed by a 
Qualified Auditor, as defined in the Baseline Requirements section 8.2.

A Qualified Auditor MUST have relevant IT Security experience, or have audited 
a number of CAs, and be independent. Each Audit Report MUST be accompanied by 
documentation provided to Mozilla of the audit team qualifications sufficient 
for Mozilla to determine the competence, experience, and independence of the 
auditor."

 

Otherwise a link to the Wiki would be necessary for clear definition of the 
details for the auditor qualification. 

 

Apart from that: is it also intended to change section 3.1.4?

 

All the best 

Clemens

 

-Ursprüngliche Nachricht-
Von: mozilla.dev.security.pol...@googlegroups.com 
 Im Auftrag von Ben Wilson
Gesendet: Dienstag, 9. März 2021 00:31
An: mozilla-dev-security-policy 
Betreff: EXT: Re: Policy 2.7.1: MRSP Issue #192: Require information about 
auditor qualifications in the audit report

 

All,

Kathleen and I discussed the language of this proposal and have modified it for 
MRSP section 3.2 as follows:  "A Qualified Auditor MUST have relevant IT 
Security experience, or have audited a number of CAs, and be independent.

Each Audit Report MUST be accompanied by documentation provided to Mozilla of 
the audit team qualifications sufficient for Mozilla to determine the 
competence, experience, and independence of the auditor."

Ben

 

 

On Thu, Feb 18, 2021 at 11:27 AM Ben Wilson <  
bwil...@mozilla.com> wrote:

 

> All,

> 

> I have edited the proposed resolution of Issue #192 

>  5fa760555c1eabb81bd7914ee>

> as follows:

> 

> Subsection 3 of MRSP Section 3.1.4. would read:

> 

> "The publicly-available documentation relating to each audit MUST 

> contain at least the following clearly-labelled information: ...

> 

> 3. name of the lead auditor and qualifications of the team performing 

> the audit, as required by section 3.2; ..."

> 

> Section 3.2 would read:

> 

> "A Qualified Auditor MUST have relevant IT Security experience, or 

> have audited a number of CAs, and be independent and not conflicted. 

> People have competence, partnerships and corporations do not. Each 

> Audit Report MUST be accompanied by documentation provided to Mozilla 

> of the audit team qualifications 

> <  
> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications>

> sufficient for Mozilla to determine the competence, experience, and 

> independence of the Qualified Auditor."

> 

> The wiki page linked above will provide further details on how to 

> submit documentation of the audit team's qualifications (which may be 

> separate from the audit letter itself).

> 

> Ben

> 

> 

>  5fa760555c1eabb81bd7914ee>

> 

> 

> 

> On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy < 

>   
> dev-security-policy@lists.mozilla.org> wrote:

> 

>> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:

>> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:

>> > > Apologies for belaboring the point, but I think we might be 

>> > > talking

>> past

>> > > eachother.

>> > >

>> > > You originally stated “The only place I am aware that lists the 

>> > > audit partner in a comparable world is the signing audit partner 

>> > > on public company audits in the US, which is available on the SEC 

>> > > website.” I

>> gave

>> > > two separate examples of such, and you responded to one (FPKI) by

>> saying

>> > > the report was not public (even when it is made available 

>> > > publicly),

>> and

>> > > the other I didn’t see a response to.

>> > >

>> > > This might feel like nit-picking, but I think this is a rather

>> serious

>> > > point to work through, because I don’t think you’re fully

>> communicating

>> > > what you judge to be a “comparable world”, as it appears you are

>> dismissing

>> > > these examples.

>> > >

>> > > I can think of several possible dimensions you might be thinking 

>> > > are relevant, but rather than assume, I’m hoping you can expand 

>> > > with a

>> few

>> > > simple questions. Some admittedly seem basic, but I don’t want to

>> take

>> > > anything for granted here.

>> > >

>> > > 1) Are you/the WTTF familiar with these audit schemes?

>> > >

>> > > 2) Are you aware of schemes 

Re: Clarification request: ECC subCAs under RSA Root

[pfuen...--- via dev-security-policy]

OK. Thanks for your answers.

In summary, my understanding is that we can ignore that illustrative control of 
the Webtrust Criteria and that the community is cool with these subordinations 
of CAs with stronger keys (same or different algorithm).

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

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ben Wilson via dev-security-policy]

Thanks, Ryan
I'll work on incorporating your suggestions into the draft we're working on.
Ben

On Wed, Mar 10, 2021 at 9:10 AM Ryan Sleevi  wrote:

>
>
> On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> #139 resolved - Audits are required even if no longer issuing, until CA
>> certificate is revoked, expired, or removed.
>>
>> See
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
>>
>
> I'm assuming you're OK with this, but just wanting to make sure it's
> explicit:
>
> In the scenario where the CA destroys the private key, they may still have
> outstanding certificates that work in Mozilla products. If Mozilla is
> relying on infrastructure provided by that CA (e.g. OCSP, CRL), the CA no
> longer has an obligation to audit that infrastructure.
>
> I suspect that the idea is that if/when a CA destroys the private key,
> that the expectation is Mozilla will promptly remove/revoke the root, but
> just wanted to call out that there is a gap between the operational life
> cycle of a CA (e.g. providing revocation services) and the private key
> lifecycle.
>
> If this isn't intended, then removing the "or until all copies" should
> resolve this, but of course, open up new discussion.
>
>
>> #221 resolved - Wrong hyperlink for “material change” in MRSP section 8
>>
>> Replace hyperlink with “there is a change in the CA's operations that
>> could
>> significantly affect a CA's ability to comply with the requirements of
>> this
>> Policy.”
>>
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057
>
>
> Since "significantly" is highly subjective, and can lead the CA to not
> disclosing, what would be the impact of just dropping the word? That is,
> "that could affect a CA's ability to comply". There's still an element of
> subjectivity here, for sure, but it encourages CAs to over-disclose, rather
> than under-disclose, as the current language does.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

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

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
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Clarification request: ECC subCAs under RSA Root

[Tim Hollebeek via dev-security-policy]

I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI.  Even there, it often causes
more problems than it solves.  I've spent more of my life dealing with the
fallout from rules like this than I care to admit.

It makes more sense when you have a complex asymmetric or symmetric system
with different strength keys protecting the distribution of symmetric keys
with different strengths, and you want to make sure the keys being
distributed actually have the intended strength, instead of being somewhat
weaker due to potential attacks on weak links in the distribution system.
One of the ways of simplifying that complexity is to enforce various
uniformity requirements on the chains.  This helps prevent accidentally
using an encryption key that was distributed with a weaker key, and thinking
that it has full strength.

It's important to remember that TLS keys are real-time online authentication
keys, generally with relatively short lifetimes (relative to many typical
KMSs!), and the goal is to meet the minimum authentication strength goal at
the time the connection is being built.  Whether one or more keys is a bit
stronger than necessary doesn't hurt anything in the same way that it can
for encryption keys.  And as the two previous people have noted, mixed
chains can be extremely useful in various interoperability and
transition/upgrade scenarios.  So rules like these can actually reduce
cryptoagility by unnecessarily eliminating perfectly viable options, and
reducing cryptoagility is the exact opposite of what we should be trying to
accomplish.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, March 10, 2021 11:00 AM
> To: pfuen...@gmail.com 
> Cc: Mozilla 
> Subject: Re: Clarification request: ECC subCAs under RSA Root
> 
> I agree with Corey that this is problematic, and wouldn't even call it a
best
> practice/good practice.
> 
> I appreciate the goal in the abstract - which is to say, don't do more
work than
> necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles
*if*
> there's no other reason for it), but as Corey points out, there are times
where
> it's both necessary and good to have such chains.
> 
> On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > > My understanding is that neither the BRs or any Root Program require
> > that that subordinate CA key be weaker or equal in strength to the
> > issuing CA's key.
> > >
> > > Additionally, such a requirement would prohibit cross-signs where a
> > "legacy" root with a smaller key size would certify a new root CA with
> > a stronger key. For that reason, this illustrative control seems
problematic.
> > >
> >
> > Thanks, Corey.
> > I also see it problematic, but I've been seeing other root programs
(i.e.
> > Spanish Government) enforcing this rule, so I'd like to understand if
> > it's a "best practice" or a rule, and, in particular, if it's rule to
> > be respected for TLS-oriented hierarchies.
> > P
> > ___
> > 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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> #139 resolved - Audits are required even if no longer issuing, until CA
> certificate is revoked, expired, or removed.
>
> See
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
>

I'm assuming you're OK with this, but just wanting to make sure it's
explicit:

In the scenario where the CA destroys the private key, they may still have
outstanding certificates that work in Mozilla products. If Mozilla is
relying on infrastructure provided by that CA (e.g. OCSP, CRL), the CA no
longer has an obligation to audit that infrastructure.

I suspect that the idea is that if/when a CA destroys the private key, that
the expectation is Mozilla will promptly remove/revoke the root, but just
wanted to call out that there is a gap between the operational life cycle
of a CA (e.g. providing revocation services) and the private key lifecycle.

If this isn't intended, then removing the "or until all copies" should
resolve this, but of course, open up new discussion.


> #221 resolved - Wrong hyperlink for “material change” in MRSP section 8
>
> Replace hyperlink with “there is a change in the CA's operations that could
> significantly affect a CA's ability to comply with the requirements of this
> Policy.”
>
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fbe04aa64f931940af967ed90ab98aa95789f057


Since "significantly" is highly subjective, and can lead the CA to not
disclosing, what would be the impact of just dropping the word? That is,
"that could affect a CA's ability to comply". There's still an element of
subjectivity here, for sure, but it encourages CAs to over-disclose, rather
than under-disclose, as the current language does.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Clarification request: ECC subCAs under RSA Root

[Ryan Sleevi via dev-security-policy]

I agree with Corey that this is problematic, and wouldn't even call it a
best practice/good practice.

I appreciate the goal in the abstract - which is to say, don't do more work
than necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting
cycles *if* there's no other reason for it), but as Corey points out, there
are times where it's both necessary and good to have such chains.

On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > My understanding is that neither the BRs or any Root Program require
> that that subordinate CA key be weaker or equal in strength to the issuing
> CA's key.
> >
> > Additionally, such a requirement would prohibit cross-signs where a
> "legacy" root with a smaller key size would certify a new root CA with a
> stronger key. For that reason, this illustrative control seems problematic.
> >
>
> Thanks, Corey.
> I also see it problematic, but I've been seeing other root programs (i.e.
> Spanish Government) enforcing this rule, so I'd like to understand if it's
> a "best practice" or a rule, and, in particular, if it's rule to be
> respected for TLS-oriented hierarchies.
> P
> ___
> 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

Re: Clarification request: ECC subCAs under RSA Root

[pfuen...--- via dev-security-policy]

> My understanding is that neither the BRs or any Root Program require that 
> that subordinate CA key be weaker or equal in strength to the issuing CA's 
> key. 
> 
> Additionally, such a requirement would prohibit cross-signs where a "legacy" 
> root with a smaller key size would certify a new root CA with a stronger key. 
> For that reason, this illustrative control seems problematic. 
> 

Thanks, Corey. 
I also see it problematic, but I've been seeing other root programs (i.e. 
Spanish Government) enforcing this rule, so I'd like to understand if it's a 
"best practice" or a rule, and, in particular, if it's rule to be respected for 
TLS-oriented hierarchies.
P
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Clarification request: ECC subCAs under RSA Root

[Corey Bonnell via dev-security-policy]

My understanding is that neither the BRs or any Root Program require that that 
subordinate CA key be weaker or equal in strength to the issuing CA's key.

Additionally, such a requirement would prohibit cross-signs where a "legacy" 
root with a smaller key size would certify a new root CA with a stronger key. 
For that reason, this illustrative control seems problematic.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On 
Behalf Of pfuen...--- via dev-security-policy
Sent: Wednesday, March 10, 2021 4:17 AM
To: Mozilla 
Subject: Clarification request: ECC subCAs under RSA Root

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) 
of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:

4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity 
period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public 
key length to be certified by a CA is less than or equal to that of the CA’s 
private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and 
have a key size in accordance with the CA’s CP and/or CPS.


My reading of this criteria is that it's not possible to have a subordinate 
with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, 
so if I read the above criteria in terms of crypto strength, I get the 
impression that this is nor allowed. But I don't know if this is an appropriate 
interpretation of the rules.

Can anyone help me to see the light?

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Clarification request: ECC subCAs under RSA Root

[pfuen...--- via dev-security-policy]

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) 
of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:

4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity 
period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public 
key length to be certified by a CA is less than or equal to that of the CA’s 
private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and 
have a key size in accordance with the CA’s CP and/or CPS.


My reading of this criteria is that it's not possible to have a subordinate 
with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, 
so if I read the above criteria in terms of crypto strength, I get the 
impression that this is nor allowed. But I don't know if this is an appropriate 
interpretation of the rules.

Can anyone help me to see the light?

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

Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ben Wilson via dev-security-policy]

All,


Below are the summaries of the proposed resolutions of the issues slated to
be addressed by version 2.7.1 of the Mozilla Root Store Policy.


A full redline of the proposed changes can be seen here by clicking on the
"Files changed" tab:
https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.7.1


I intend to close public discussion on the proposed changes sometime next
week. That will be followed by finalizing anything that needs to be
addressed, Mozilla internal reviews, and a CA Communication and survey.


Thanks for your contributions.


Sincerely yours,


Ben


--


#130 resolved - updates required to current audit versions

References to updated audit criteria are found here:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/b62ae60d18625e3df3f78033f8b9b51be18379ff


#139 resolved - Audits are required even if no longer issuing, until CA
certificate is revoked, expired, or removed.

See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35


#147 resolved - Require EV audits for certificates capable of issuing EV
certificates – Clarify that EV audits are required for all intermediate
certificates that are technically capable of issuing EV certificates, even
when not currently issuing EV certificates.

Resolved with hyperlink to:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

#152 resolved - Add EV Audit exception for Policy Constraints – leaf
certificates do not receive EV treatment unless signed by an intermediate
CA with EV OID or anyPolicy OID, therefore they can be excluded from EV
audits.

Resolved with hyperlink to:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

#153 resolved – Cradle-to-Grave Contiguous Audits – Specify the audits that
are required from Root key generation ceremony until expiration or removal
from Mozilla’s root store.

Resolved with:

“Full-surveillance period-of-time audits MUST be conducted and updated
audit information provided no less frequently than annually from the time
of CA key pair generation until the CA certificate is no longer trusted by
Mozilla's root store or until all copies of the CA private key have been
completely destroyed, as evidenced by a Qualified Auditor's key destruction
report, whichever occurs sooner. This cradle-to-grave audit requirement
applies equally to subordinate CAs as it does to root CAs. Successive
period-of-time audits MUST be contiguous (no gaps).”

https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d


#154 closed/removed - Require Management Assertions to list Non-compliance
– Add to MRSP section 2.4 “If being audited to the WebTrust criteria, the
Management Assertion letter MUST include all known incidents that occurred
or were still open/unresolved at any time during the audit period.”

https://github.com/mozilla/pkipolicy/issues/154#issuecomment-793124154

#173 resolved - Strengthen requirement for newly included roots to meet all
past and present requirements – Add language to MRSP section 7.1 so that it
is clear that before being included CAs must comply and have complied with
past and present Mozilla Root Store Policy and Baseline Requirements.

Section “Before being included, CAs MUST provide evidence that their CA
certificates fully comply with the current Mozilla Root Store Requirements
and Baseline Requirements, and have continually, from the time of CA
private key creation, complied with the then-current Mozilla Root Store
Policy and Baseline Requirements.”

https://github.com/BenWilson-Mozilla/pkipolicy/commit/0d72d9be5acca17ada34cf7e380741e27ee84e55


#186 resolved - Clarify MRSP section 5.3 Requirement to Disclose
Self-signed Certificates – Clarify that self-signed certificates with the
same key pair as an existing root meets MRSP section 5.3’s definition of an
intermediate certificate that must be disclosed in the CCADB

Resolved with:

"Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate
Program MUST disclose in the CCADB all non-technically constrained CA
certificates they issue that chain up to that CA certificate trusted in
Mozilla’s CA Certificate Program. This applies to all non-technically
constrained CA certificates, including those that are self-signed,
doppelgänger, reissued, or cross-signed."

See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b


#187 resolved - Require disclosure of incidents in Audit Reports –  To MRSP
section 3.1.4 “The publicly-available documentation relating to each audit
MUST contain at least the following clearly-labelled information: “ add
“11. all incidents (as defined in section 2.4) …”

Resolved with:

“11. all incidents (as defined in section 2.4) disclosed by the CA,
discovered by the auditor, or reported by a third party, that, at any time
during the audit period, occurred or were open in Bugzilla;”

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

All,
We are going to postpone the resolution of this Issue #218 and the addition
of language to address the "Full CRL" until MRSP version 2.8.
Thanks for your input thus far.
Ben

On Thu, Feb 25, 2021 at 10:59 AM Ben Wilson  wrote:

> As placeholder in the Mozilla Root Store Policy, I'm proposing the
> following sentence for section 6.1 - "A CA MUST ensure that it populates
> the CCADB with the appropriate 'full CRL' in the CCADB revocation
> information field pertaining to certificates issued by the CA
>  for each
> intermediate CA technically capable of issuing server certificates." (The
> hyperlink isn't active yet until we have the CCADB language and
> implementation clarified, per Kathleen's recent email and responses
> thereto.)Here it is on GitHub -
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48.
> Caveat - other browsers, such as Apple, will likely have more encompassing
> implementation requirements for when to populate these "full CRL" fields.
>
> On Mon, Jan 25, 2021 at 10:16 AM Aaron Gable 
> wrote:
>
>> I think that an explicit carve-out for time-scoped CRLs is a very good
>> idea.
>>
>> In the case that this change to the MRSP is adopted, I suspect that LE
>> would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or
>> even 6 hours of issuance. We would pick a small interval such that we could
>> guarantee that each CRL would still be a reasonable size even in the face
>> of a mass revocation event.
>>
>> Producing CRLs at that rate, it would be very valuable to be able to
>> gracefully age CRLs out once there is no possibility for a revocation
>> status update for any certificate in their scope.
>>
>> Aaron
>>
>> On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> All,
>>>
>>> Another suggestion came in for clarification that hasn't been raised on
>>> the
>>> list yet, so I'll try and explain the scenario here.
>>>
>>> Normally, a CA must publish and update its CRLs until the end of the CA
>>> certificate's expiration. However, I think that some CAs partition their
>>> CRLs based on issuance time, e.g., all certificates issued during January
>>> 2021. And all of those certificates would expire after the applicable
>>> validity period.  I think CAs don't continue to regenerate or reissue
>>> those
>>> types of partitioned CRLs which only contain certificates that have
>>> expired.  So maybe we need to add an express exception that allows CAs to
>>> omit those obsolete CRLs from the JSON file -- as long as the JSON file
>>> contains the equivalent of  a "full and complete" CRL.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>> On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling  wrote:
>>>
>>> > Hi Ben.
>>> >
>>> > > *A CA technically capable of issuing server certificates MUST ensure
>>> > that
>>> > > the CCADB field "Full CRL Issued By This CA" contains either the URL
>>> for
>>> > > the full and complete CRL or the URL for the JSON file containing all
>>> > URLs
>>> > > for CRLs that when combined are the equivalent of the full and
>>> complete
>>> > CRL*
>>> >
>>> > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL
>>> > Issued By This CA" and "the URL for the JSON file" as 2 separate
>>> fields in
>>> > the CCADB.  CAs would then be expected to fill in one field or the
>>> other,
>>> > but not both.  Is that possible?
>>> >
>>> > To ensure that these JSON files can be programmatically parsed, I
>>> suggest
>>> > specifying the requirement a bit more strictly.  Something like this:
>>> >   "...or the URL for a file that contains only a JSON Array, whose
>>> > elements are URLs of DER encoded CRLs that when combined are the
>>> equivalent
>>> > of a full and complete CRL"
>>> >
>>> > > I propose that this new CCADB field be populated in all situations
>>> where
>>> > the CA is enabled for server certificate issuance.
>>> >
>>> > Most Root Certificates are "enabled for server certificate issuance".
>>> > Obviously CAs shouldn't issue leaf certs directly from roots, but
>>> > nonetheless the technical capability does exist.  However, currently
>>> CAs
>>> > can't edit Root Certificate records in the CCADB, which makes
>>> populating
>>> > these new field(s) "in all situations" rather hard.
>>> >
>>> > Since OneCRL covers revocations of intermediate certs, may I suggest
>>> that
>>> > CAs should only be required to populate these new field(s) in
>>> intermediate
>>> > certificate records (and not in root certificate records)?
>>> >
>>> > Relatedly, "A CA technically capable of...that the CCADB field" seems
>>> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
>>> > Similar language elsewhere in the policy (section 5.3.2) says "All
>>> > certificates that are capable of being used to..." (rather than "All
>>> > CAs...").
>>> >
>>> > 

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

All,

Here is the currently proposed wording for subsection 5.1 of MRSP section
2.1:

" 5.1. for server certificates issued on or after October 1, 2021, verify
each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
or less;"

Ben

On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi  wrote:

>
>
> On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I think it makes sense to separate out the date for domain validation
>> expiration from the issuance of server certificates with previously
>> validated domain names, but agree with Ben that the timeline doesn’t seem
>> to need to be prolonged. What about something like this:
>>
>> 1. Domain name or IP address verifications performed on or after July 1,
>> 2021 may be reused for a maximum of 398 days.
>> 2. Server certificates issued on or after September 1, 2021 must have
>> completed domain name or IP address verification within the preceding 398
>> days.
>>
>> This effectively stretches the “cliff” out across ~6 months (now through
>> the end of August), which seems reasonable.
>>
>
> Yeah, that does sound reasonable.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

All,
Kathleen and I discussed the language of this proposal and have modified it
for MRSP section 3.2 as follows:  "A Qualified Auditor MUST have relevant
IT Security experience, or have audited a number of CAs, and be independent.
Each Audit Report MUST be accompanied by documentation provided to Mozilla
of the audit team qualifications sufficient for Mozilla to determine the
competence, experience, and independence of the auditor."
Ben


On Thu, Feb 18, 2021 at 11:27 AM Ben Wilson  wrote:

> All,
>
> I have edited the proposed resolution of Issue #192
> 
> as follows:
>
> Subsection 3 of MRSP Section 3.1.4. would read:
>
> "The publicly-available documentation relating to each audit MUST contain
> at
> least the following clearly-labelled information: ...
>
> 3. name of the lead auditor and qualifications of the team performing the
> audit, as required by section 3.2;
> ..."
>
> Section 3.2 would read:
>
> "A Qualified Auditor MUST have relevant IT Security experience, or have
> audited a number of CAs, and be independent and not conflicted. People
> have competence, partnerships and corporations do not. Each Audit Report
> MUST be accompanied by documentation provided to Mozilla of the audit team
> qualifications
> 
> sufficient for Mozilla to determine the competence, experience, and
> independence of the Qualified Auditor."
>
> The wiki page linked above will provide further details on how to submit
> documentation of the audit team's qualifications (which may be separate
> from the audit letter itself).
>
> Ben
>
>
> 
>
>
>
> On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:
>> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:
>> > > Apologies for belaboring the point, but I think we might be talking
>> past
>> > > eachother.
>> > >
>> > > You originally stated “The only place I am aware that lists the audit
>> > > partner in a comparable world is the signing audit partner on public
>> > > company audits in the US, which is available on the SEC website.” I
>> gave
>> > > two separate examples of such, and you responded to one (FPKI) by
>> saying
>> > > the report was not public (even when it is made available publicly),
>> and
>> > > the other I didn’t see a response to.
>> > >
>> > > This might feel like nit-picking, but I think this is a rather
>> serious
>> > > point to work through, because I don’t think you’re fully
>> communicating
>> > > what you judge to be a “comparable world”, as it appears you are
>> dismissing
>> > > these examples.
>> > >
>> > > I can think of several possible dimensions you might be thinking are
>> > > relevant, but rather than assume, I’m hoping you can expand with a
>> few
>> > > simple questions. Some admittedly seem basic, but I don’t want to
>> take
>> > > anything for granted here.
>> > >
>> > > 1) Are you/the WTTF familiar with these audit schemes?
>> > >
>> > > 2) Are you aware of schemes that require disclosing the relevant
>> skills and
>> > > experience of the audit team to the client? (E.g. as done by BSI C5
>> audits
>> > > under ISAE 3000)
>> > >
>> > > 3) Are you aware of such reports naming multiple parties for the use
>> of the
>> > > report (e.g. as done by FPKI audits)
>> > >
>> > > 4) Are you aware of schemes in which a supplier requires a vendor to
>> be
>> > > audited, and ensures that the customer of supplier are able to access
>> such
>> > > audits as part of their reliance upon supplier? (Note, this doesn’t
>> have to
>> > > be limited to ISMS systems)
>> > >
>> > > I’m trying to understand what, given the prevalence of these
>> practices,
>> > > makes these instances *not* a comparable world, since it seems that
>> helps
>> > > move closer to solutions.
>> > Ryan, I hope you are not suggesting I am dodging you points. That would
>> be absurd. Let me use different words as comparable world seems to be
>> tripping you up. You are not providing a general/public distribution
>> example to make your point so it is baseless. You are using a restricted
>> opinion from EY and neither Ryan Sleevi nor Google are listed as the two
>> intended users. The closest I have seen to support your desire to name
>> individual auditors is in public company audit reports, which are housed on
>> the SEC website. To be clear, of your two examples, one is an opinion,
>> which is restricted, and the other represents the guidelines. Perhaps you
>> have seen a public/general distribution report from your second opinion as
>> I do not see it in this thread. I am aware, as mentioned previously, of the
>> Federal PKI program desiring to know more about team 

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

Kathleen and I edited the proposed language (
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a69aa03fb92d1b0c3f74fd560dffefdeed934b45)
to now read:

"The publicly-available documentation relating to each audit MUST contain
at least the following clearly-labelled information:
...
11. all incidents (as defined in section 2.4) disclosed by the CA,
discovered by the auditor, or reported by a third party, that, at any time
during the audit period, occurred or were open in Bugzilla;"

Additional guidance will be provided here:
https://wiki.mozilla.org/CA/Audit_Statements and/or here:
https://wiki.mozilla.org/CA/Responding_To_An_Incident



On Mon, Feb 15, 2021 at 11:47 AM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, February 12, 2021 at 10:27:11 AM UTC-6, Ben Wilson wrote:
> > I'm fine with that suggestion.
> > On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote:
> > > > 11. all incidents (as defined in section 2.4), including those
> reported
> > > in
> > > > Bugzilla, that were:
> > > > * disclosed by the CA or discovered by the auditor, and
> > > > * unresolved at any time during the audit period;
> > > >
> > > > The idea is that all "incidents" must be reported if they were
> > > "unresolved"
> > > > - which would include those that occurred or were open - at any time
> > > during
> > > > the audit period.
> > > >
> > >
> > > Wouldn't it be clearer to non-native English speakers to avoid the
> nuance
> > > associated with "unresolved at any time" needing to imply both those
> that
> > > occurred or those that were still open?
> > >
> > > Why not amend the language to just say:
> > >
> > > 11. all incidents (as defined in section 2.4), including those
> reported in
> > > Bugzilla, that:
> > > * were disclosed by the CA or discovered by the auditor, and
> > > * occurred or were open at any time during the audit period;
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> This wording works from a WebTrust perspective as well.  Thanks!
> ___
> 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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Also, I neglected to mention it before, but this issue is also related to
Issue #173.  While section 7.1 already states that CAs must provide
evidence of CA compliance from "creation," the Issue #173 proposal is that
section 7.1 be amended to say, "Before being included, CAs MUST provide
evidence that their CA certificates fully comply with the current Mozilla
Root Store Requirements and Baseline Requirements*, and have continually,
from the time of CA private key creation, complied with the then-current
Mozilla Root Store Policy and Baseline Requirements*."  I don't believe I
received any comments on that language. See
https://groups.google.com/g/mozilla.dev.security.policy/c/DChXLJrMwag/m/uGpEqiEcBgAJ


On Sat, Mar 6, 2021 at 9:17 PM Ben Wilson  wrote:

> Thanks, Bruce, for raising the issue of pre-generated, yet unassigned
> keys. The intent was to cover this scenario.  We are aware that CAs might
> generate 1000s of keys in a partition and then years later assign a few of
> them as CA keys, others as OCSP responder keys, etc., and some might never
> be used. Presumably each of the keys would have an identifier and the CA
> operator would maintain a list of those key identifiers for each partition.
> The goal is to have an audited chain of custody for the keys, which could
> also be based on the physical and logical protection of the HSM that is
> holding them.
> Key lifecycle documentation would consist of a documented key generation
> ceremony (where such documentation is reviewed by an auditor). Then,
> annually an auditor would review storage and access records for the HSM(s)
> and the list of keys to see which ones had been used for CAs and which ones
> had not. Then, as keys were destroyed (or if not, when the HSM is zeroized
> at the end of the HSM's lifecycle), there would be an attestation of key
> destruction that would be covered by an audit/auditor's statement.
>
>
> On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com
>> wrote:
>> > I haven't seen any response to my question about whether there is still
>> a
>> > concern over the language "as evidenced by a Qualified Auditor's key
>> > destruction report".
>> > I did add "This cradle-to-grave audit requirement applies equally to
>> > subordinate CAs as it does to root CAs" to address the scenarios that
>> were
>> > raised.
>> > So I am going to assume that this issue is resolved and that we can
>> move
>> > this proposed change forward.
>> > See
>> >
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d
>>
>> Ben, sorry for the late input.
>>
>> We are onboard with the cradle-to-grave audit as we have experience
>> auditing non-functioning CAs before they go into production and after they
>> have stopped issuing certificates. However, I think there might be an issue
>> in the requirement with the start and stop time of cradle-to-grave.
>>
>> At the beginning, I think that CAs will generate one or many keys, but
>> will not assign them to CAs. The gap period could be days to years. Since
>> the requirement says "from the time of CA key pair generation", do we want
>> an audit of an unassigned key? Or should the audit start once the key has
>> been assigned and the CA certificate has been generated?
>>
>> At the end, subordinate CA certificate(s) may be revoked or may expire.
>> Once the certificate(s) are revoked or expired, is this a reasonable time
>> to stop auditing the CA as trust has been removed? Of course if the
>> certificates are not revoked or expired, then all copies of the keys should
>> be destroyed to stop the audit. However, I think the best practice should
>> be that certificates should be revoked/expired at time of key destruction.
>> ___
>> 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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys.
The intent was to cover this scenario.  We are aware that CAs might
generate 1000s of keys in a partition and then years later assign a few of
them as CA keys, others as OCSP responder keys, etc., and some might never
be used. Presumably each of the keys would have an identifier and the CA
operator would maintain a list of those key identifiers for each partition.
The goal is to have an audited chain of custody for the keys, which could
also be based on the physical and logical protection of the HSM that is
holding them.
Key lifecycle documentation would consist of a documented key generation
ceremony (where such documentation is reviewed by an auditor). Then,
annually an auditor would review storage and access records for the HSM(s)
and the list of keys to see which ones had been used for CAs and which ones
had not. Then, as keys were destroyed (or if not, when the HSM is zeroized
at the end of the HSM's lifecycle), there would be an attestation of key
destruction that would be covered by an audit/auditor's statement.


On Fri, Mar 5, 2021 at 9:46 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com
> wrote:
> > I haven't seen any response to my question about whether there is still
> a
> > concern over the language "as evidenced by a Qualified Auditor's key
> > destruction report".
> > I did add "This cradle-to-grave audit requirement applies equally to
> > subordinate CAs as it does to root CAs" to address the scenarios that
> were
> > raised.
> > So I am going to assume that this issue is resolved and that we can move
> > this proposed change forward.
> > See
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d
>
> Ben, sorry for the late input.
>
> We are onboard with the cradle-to-grave audit as we have experience
> auditing non-functioning CAs before they go into production and after they
> have stopped issuing certificates. However, I think there might be an issue
> in the requirement with the start and stop time of cradle-to-grave.
>
> At the beginning, I think that CAs will generate one or many keys, but
> will not assign them to CAs. The gap period could be days to years. Since
> the requirement says "from the time of CA key pair generation", do we want
> an audit of an unassigned key? Or should the audit start once the key has
> been assigned and the CA certificate has been generated?
>
> At the end, subordinate CA certificate(s) may be revoked or may expire.
> Once the certificate(s) are revoked or expired, is this a reasonable time
> to stop auditing the CA as trust has been removed? Of course if the
> certificates are not revoked or expired, then all copies of the keys should
> be destroyed to stop the audit. However, I think the best practice should
> be that certificates should be revoked/expired at time of key destruction.
> ___
> 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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Matt Palmer via dev-security-policy]

On Fri, Mar 05, 2021 at 08:46:26AM -0800, Bruce via dev-security-policy wrote:
> At the beginning, I think that CAs will generate one or many keys, but
> will not assign them to CAs.  The gap period could be days to years. 
> Since the requirement says "from the time of CA key pair generation", do
> we want an audit of an unassigned key?  Or should the audit start once the
> key has been assigned and the CA certificate has been generated?

I think it's reasonable that keys that are bound to CA certificates have an
unbroken history of audits demonstrating that the key has always been
managed in a way that minimises the chances of disclosure, along with
evidence that the key being bound was initially generated in a secure manner
(good RNG, etc).

- Matt

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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Bruce via dev-security-policy]

On Thursday, February 25, 2021 at 2:30:52 PM UTC-5, bwi...@mozilla.com wrote:
> I haven't seen any response to my question about whether there is still a 
> concern over the language "as evidenced by a Qualified Auditor's key 
> destruction report". 
> I did add "This cradle-to-grave audit requirement applies equally to 
> subordinate CAs as it does to root CAs" to address the scenarios that were 
> raised. 
> So I am going to assume that this issue is resolved and that we can move 
> this proposed change forward. 
> See 
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d

Ben, sorry for the late input.

We are onboard with the cradle-to-grave audit as we have experience auditing 
non-functioning CAs before they go into production and after they have stopped 
issuing certificates. However, I think there might be an issue in the 
requirement with the start and stop time of cradle-to-grave. 

At the beginning, I think that CAs will generate one or many keys, but will not 
assign them to CAs. The gap period could be days to years. Since the 
requirement says "from the time of CA key pair generation", do we want an audit 
of an unassigned key? Or should the audit start once the key has been assigned 
and the CA certificate has been generated?

At the end, subordinate CA certificate(s) may be revoked or may expire. Once 
the certificate(s) are revoked or expired, is this a reasonable time to stop 
auditing the CA as trust has been removed? Of course if the certificates are 
not revoked or expired, then all copies of the keys should be destroyed to stop 
the audit. However, I think the best practice should be that certificates 
should be revoked/expired at time of key destruction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2021 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 2 Mar 2021 15:00:24 + (GMT)


CA Owner: SECOM Trust Systems CO., LTD.
   - Certificate Name: JPRS Organization Validation Authority - G3
SHA-256 Fingerprint: 
21C066332D6B92DD9A253E2637684A5BC3E31357F863BED7A2F98C8459A33B62

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Domain Validation Authority - G3
SHA-256 Fingerprint: 
659B7A518C6C9EB18AA1EB35AEBA7A0247817B898C1FA1840F97D2877D9A20E4

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

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



CA Owner: AC Camerfirma, S.A.
   - Certificate Name: InfoCert Organization Validation CA 3
SHA-256 Fingerprint: 
247A6D807FF164031E0EB22CA85DE329A3A4E6603DBC6203F0C6E282A9C9EA84

Standard Audit Period End Date (mm/dd/): 11/27/2019
BR Audit Period End Date (mm/dd/): 11/27/2019

   - Certificate Name: Intesa Sanpaolo Organization Validation CA
SHA-256 Fingerprint: 
27CDD699DE15EE88A05BB10ED9DF2FC5E4CA25B5FDD42988963A38EC8940D55A

Standard Audit Period End Date (mm/dd/): 11/28/2019
BR Audit Period End Date (mm/dd/): 11/28/2019




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

Re: Public Discussion for Inclusion of e-commerce monitoring's GLOBALTRUST 2020 Root

[Ben Wilson via dev-security-policy]

On February 4, 2021, the public discussion period [Step 4 of the Mozilla
Root Store CA Application Process
] began on e-commerce
monitoring’s inclusion request.

No questions or concerns have been raised and there are no open action
items for e-commerce monitoring 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 e-commerce monitoring’s request for
inclusion [Step 10].

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

On Mon, Feb 22, 2021 at 1:51 PM Ben Wilson  wrote:

> Just a reminder that discussion is ongoing and scheduled to close this
> Friday, 26-Feb-2021.
>
> On Thu, Feb 4, 2021 at 4:39 PM Ben Wilson  wrote:
>
>> This is to announce the beginning of the public discussion phase (
>> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps
>> 4 through 9)) of the Mozilla root CA inclusion process for e-commerce
>> monitoring GmbH’s GLOBALTRUST 2020 Root CA.
>>
>> e-commerce monitoring operates as "GlobalTrust", which was previously
>> operated by Austrian Society for Data Protection - Arge Daten. According
>> to the Applicant, Arge-Daten was the owner of the older "GlobalTrust"
>> roots, which are not part of this application. This application has been
>> tracked in the CCADB and in Bugzilla -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1627552.
>>
>> e-commerce monitoring’s GLOBALTRUST 2020 Root is proposed for inclusion
>> with the websites trust bit (with EV) and the email trust bit.
>>
>> Mozilla is considering approving e-commerce monitoring’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).
>>
>> *A Summary of Information Gathered and Verified appears here in this
>> CCADB case:*
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0568
>>
>> *Root Certificate Information:*
>>
>> GLOBALTRUST 2020 Root
>>
>> crt.sh -
>> https://crt.sh/?q=9A296A5182D1D451A2E37F439B74DAAFA267523329F90F9A0D2007C334E23C9A
>>
>>
>> Download - http://service.globaltrust.eu/static/globaltrust-2020.crt
>>
>>
>> *CP/CPS:*
>>
>> Current CP is Version 2.0h / 15th January 2021
>>
>> http://service.globaltrust.eu/static/globaltrust-certificate-policy.pdf
>>
>> Current CPS is Version 2.0h / 15th January 2021
>>
>>
>> http://service.globaltrust.eu/static/globaltrust-certificate-practice-statement.pdf
>>
>> Repository location:   https://globaltrust.eu/certificate-policy/
>>
>> *BR Self-Assessment* (PDF) is located here:
>>
>> https://bugzilla.mozilla.org/attachment.cgi?id=9138392
>>
>>
>> *Audits:*
>>
>> 2020 audits are attached to Bug # 1627552
>>  and include the
>> Key Generation Report, the EV Readiness Audit, and the ETSI Audit
>> Attestation, which covered the period from 06/11/2019 until 04/01/2020. The
>> next audit is due 04/01/2021.
>>
>> No misissuances were found under this root, and all subordinate
>> certificates passed technical tests satisfactorily.
>>
>> Again, this email begins a three-week public discussion period, which I’m
>> scheduling to close on or about 26-February-2021.
>>
>> Sincerely yours,
>>
>> Ben Wilson
>>
>> Mozilla Root Program
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

On Fri, Feb 26, 2021 at 5:18 PM Ryan Sleevi  wrote:

> I do believe it's problematic for the OCSP and CRL versions of the
> repository to be out of sync, but also agree this is an area that is useful
> to clarify. To that end, I filed
> https://github.com/cabforum/servercert/issues/252 to make sure we don't
> lose track of this for the BRs.
>

Thanks! I like that bug, and commented on it to provide a little more
clarity for how the question arose in my mind and what language we might
want to update. It sounds like maybe what we want is language to the effect
that, if a CA is publishing both OCSP and CRLs, then a certificate is not
considered Revoked until it shows up as Revoked in both revocation
mechanisms. (And it must be Revoked within 24 hours.)

We'll make sure our parallel CRL infrastructure re-issues CRLs
close-to-immediately after a certificate in that shard's scope is revoked,
just as we do for OCSP today.

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

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

On Fri, Feb 26, 2021 at 6:01 PM Aaron Gable  wrote:

> On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi  wrote:
>
>> You can still do parallel signing. I was trying to account for that
>> explicitly with the notion of the “pre-reserved” set of URLs. However, that
>> also makes an assumption I should have been more explicit about: whether
>> the expectation is “you declare, then fill, CRLs”, or whether it’s
>> acceptable to “fill, then declare, CRLs”. I was trying to cover the former,
>> but I don’t think there is any innate prohibition on the latter, and it was
>> what I was trying to call out in the previous mail.
>>
>> I do take your point about deterministically, because the process I’m
>> describing is implicitly assuming you have a work queue (e.g. pub/sub, go
>> channel, etc), in which certs to revoke go in, and one or more CRL signers
>> consume the queue and produce CRLs. The order of that consumption would be
>> non-deterministic, but it very much would be parallelizable, and you’d be
>> in full control over what the work unit chunks were sized at.
>>
>> Right, neither of these are required if you can “produce, then declare”.
>> From the client perspective, a consuming party cannot observe any
>> meaningful difference from the “declare, then produce” or the “produce,
>> then declare”, since in both cases, they have to wait for the CRL to be
>> published on the server before they can consume. The fact that they know
>> the URL, but the content is stale/not yet updated (I.e. the declare then
>> produce scenario) doesn’t provide any advantages. Ostensibly, the “produce,
>> then declare” gives greater advantage to the client/root program, because
>> then they can say “All URLs must be correct at time of declaration” and use
>> that to be able to quantify whether or not the CA met their timeline
>> obligations for the mass revocation event.
>>
>
> I think we managed to talk slightly past each other, but we're well into
> the weeds of implementation details so it probably doesn't matter much :)
> The question in my mind was not "can there be multiple CRL signers
> consuming revocations from the queue?"; but rather "assuming there are
> multiple CRL signers consuming revocations from the queue, what
> synchronization do they have to do to ensure that multiple signers don't
> decide the old CRL is full and allocate new ones at the same time?". In the
> world where every certificate is pre-allocated to a CRL shard, no such
> synchronization is necessary at all.
>

Oh, I meant they could be signing independent CRLs (e.g. each has an IDP
with a prefix indicating which shard-generator is running), and at the end
of the queue-draining ceremony, you see what CRLs each worker created, and
add those to the JSON. So you could have multiple "small" CRLs (one or more
for each worker, depending on how you manage things), allowing them to
process revocations wholly independently. This, of course, relies again on
the assumption that the cRLDP is not baked into the certificate, which
enables you to have maximum flexibility in how CRL URLs are allocated and
sharded, provided the sum union of all of their contents reflects the CA's
state.


> This conversation does raise a different question in my mind. The Baseline
> Requirements do not have a provision that requires that a CRL be re-issued
> within 24 hours of the revocation of any certificate which falls within its
> scope. CRLs and OCSP responses for Intermediate CAs are clearly required to
> receive updates within 24 hours of the revocation of a relevant certificate
> (sections 4.9.7 and 4.9.10 respectively), but no such requirement appears
> to exist for end-entity CRLs. The closest is the requirement that
> subscriber certificates be revoked within 24 hours after certain conditions
> are met, but the same structure exists for the conditions under which
> Intermediate CAs must be revoked, suggesting that the BRs believe there is
> a difference between revoking a certificate and *publishing* that
> revocation via OCSP or CRLs. Is this distinction intended by the root
> programs, and does anyone intend to change this status quo as more emphasis
> is placed on end-entity CRLs?
>
> Or more bluntly: in the presence of OCSP and CRLs being published side by
> side, is it expected that the CA MUST re-issue a sharded end-entity CRL
> within 24 hours of revoking a certificate in its scope, or may the CA wait
> to re-issue the CRL until its next 7-day re-issuance time comes up as
> normal?
>

I recall this came up in the past (with DigiCert, [1]), in which
"revocation" was enacted by setting a flag in a database (or perhaps that
was an *extra* incident, with a different CA), but not through the actual
publication and propagation of that revocation information from DigiCert's
systems through the CDN. The issue at the time was with respect to
4.9.1.1's requirements of whether or "SHALL revoke" is a matter of merely a
server-side bit, or whether it's the actual publication of that 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi  wrote:

> You can still do parallel signing. I was trying to account for that
> explicitly with the notion of the “pre-reserved” set of URLs. However, that
> also makes an assumption I should have been more explicit about: whether
> the expectation is “you declare, then fill, CRLs”, or whether it’s
> acceptable to “fill, then declare, CRLs”. I was trying to cover the former,
> but I don’t think there is any innate prohibition on the latter, and it was
> what I was trying to call out in the previous mail.
>
> I do take your point about deterministically, because the process I’m
> describing is implicitly assuming you have a work queue (e.g. pub/sub, go
> channel, etc), in which certs to revoke go in, and one or more CRL signers
> consume the queue and produce CRLs. The order of that consumption would be
> non-deterministic, but it very much would be parallelizable, and you’d be
> in full control over what the work unit chunks were sized at.
>
> Right, neither of these are required if you can “produce, then declare”.
> From the client perspective, a consuming party cannot observe any
> meaningful difference from the “declare, then produce” or the “produce,
> then declare”, since in both cases, they have to wait for the CRL to be
> published on the server before they can consume. The fact that they know
> the URL, but the content is stale/not yet updated (I.e. the declare then
> produce scenario) doesn’t provide any advantages. Ostensibly, the “produce,
> then declare” gives greater advantage to the client/root program, because
> then they can say “All URLs must be correct at time of declaration” and use
> that to be able to quantify whether or not the CA met their timeline
> obligations for the mass revocation event.
>

I think we managed to talk slightly past each other, but we're well into
the weeds of implementation details so it probably doesn't matter much :)
The question in my mind was not "can there be multiple CRL signers
consuming revocations from the queue?"; but rather "assuming there are
multiple CRL signers consuming revocations from the queue, what
synchronization do they have to do to ensure that multiple signers don't
decide the old CRL is full and allocate new ones at the same time?". In the
world where every certificate is pre-allocated to a CRL shard, no such
synchronization is necessary at all.

This conversation does raise a different question in my mind. The Baseline
Requirements do not have a provision that requires that a CRL be re-issued
within 24 hours of the revocation of any certificate which falls within its
scope. CRLs and OCSP responses for Intermediate CAs are clearly required to
receive updates within 24 hours of the revocation of a relevant certificate
(sections 4.9.7 and 4.9.10 respectively), but no such requirement appears
to exist for end-entity CRLs. The closest is the requirement that
subscriber certificates be revoked within 24 hours after certain conditions
are met, but the same structure exists for the conditions under which
Intermediate CAs must be revoked, suggesting that the BRs believe there is
a difference between revoking a certificate and *publishing* that
revocation via OCSP or CRLs. Is this distinction intended by the root
programs, and does anyone intend to change this status quo as more emphasis
is placed on end-entity CRLs?

Or more bluntly: in the presence of OCSP and CRLs being published side by
side, is it expected that the CA MUST re-issue a sharded end-entity CRL
within 24 hours of revoking a certificate in its scope, or may the CA wait
to re-issue the CRL until its next 7-day re-issuance time comes up as
normal?

Agreed - I do think having a well-tested, reliable path for programmatic
> update is an essential property to mandating the population. My hope and
> belief, however, is that this is fairly light-weight and doable.
>

 Thanks, I look forward to hearing more about what this will look like.

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

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

On Fri, Feb 26, 2021 at 1:46 PM Aaron Gable  wrote:

> If we leave out the "new url for each re-issuance of a given CRL" portion
> of the design (or offer both url-per-thisUpdate and
> static-url-always-pointing-at-the-latest), then we could in fact include
> CRLDP urls in the certificates using the rolling time-based shards model.
> And frankly we may want to do that in the near future: maintaining both CRL
> *and* OCSP infrastructure when the BRs require only one or the other is an
> unnecessary expense, and turning down our OCSP infrastructure would
> constitute a significant savings, both in tangible bills and in engineering
> effort.
>

This isn’t quite correct. You MUST support OCSP for EE certs. It is only
optional for intermediates. So you can’t really contemplate turning down
the OCSP side, and that’s intentional, because clients use OCSP, rather
than CRLs, as the fallback mechanism for when the aggregated-CRLs fail.

I think it would be several years off before we could practically talk
about removing the OCSP requirement, once much more reliable CRL profiles
are in place, which by necessity would also mean profiling the acceptable
sharding algorithms.

Further, under today’s model, while you COULD place the CRLDP within the
certificate, that seems like it would only introduce additional cost and
limitation without providing you benefit. This is because major clients
won’t fetch the CRLDP for EE certs (especially if OCSP is present, which
the BRs MUST/REQUIRE). You would end up with some clients querying (such as
Java, IIRC), so you’d be paying for bandwidth, especially in your mass
revocation scenario, that would largely be unnecessary compared to the
status quo.

Thus, in my mind, the dynamic sharding idea you outlined has two major
> downsides:
> 1) It requires us to maintain our parallel OCSP infrastructure
> indefinitely, and
>

To the above, I think this should be treated as a foregone conclusion in
today’s requirements. So I think mostly the discussion here focuses on #2,
which is really useful.

2) It is much less resilient in the face of a mass revocation event.
>
> Fundamentally, we need our infrastructure to be able to handle the
> revocation of 200M certificates in 24 hours without any difference from how
> it handles the revocation of one certificate in the same period. Already
> having certificates pre-allocated into CRL shards means that we can
> deterministically sign many CRLs in parallel.
>

You can still do parallel signing. I was trying to account for that
explicitly with the notion of the “pre-reserved” set of URLs. However, that
also makes an assumption I should have been more explicit about: whether
the expectation is “you declare, then fill, CRLs”, or whether it’s
acceptable to “fill, then declare, CRLs”. I was trying to cover the former,
but I don’t think there is any innate prohibition on the latter, and it was
what I was trying to call out in the previous mail.

I do take your point about deterministically, because the process I’m
describing is implicitly assuming you have a work queue (e.g. pub/sub, go
channel, etc), in which certs to revoke go in, and one or more CRL signers
consume the queue and produce CRLs. The order of that consumption would be
non-deterministic, but it very much would be parallelizable, and you’d be
in full control over what the work unit chunks were sized at.

>
> Dynamically assigning certificates to CRLs as they are revoked requires
> taking a lock to determine if a new CRL needs to be created or not, and
> then atomically creating a new one. Or it requires a separate,
> not-operation-as-normal process to allocate a bunch of new CRLs, assign
> certs to them, and then sign those in parallel. Neither of these --
> dramatically changing not just the quantity but the *quality* of the
> database access, nor introducing additional processes -- is acceptable in
> the face of a mass revocation event.
>

Right, neither of these are required if you can “produce, then declare”.
From the client perspective, a consuming party cannot observe any
meaningful difference from the “declare, then produce” or the “produce,
then declare”, since in both cases, they have to wait for the CRL to be
published on the server before they can consume. The fact that they know
the URL, but the content is stale/not yet updated (I.e. the declare then
produce scenario) doesn’t provide any advantages. Ostensibly, the “produce,
then declare” gives greater advantage to the client/root program, because
then they can say “All URLs must be correct at time of declaration” and use
that to be able to quantify whether or not the CA met their timeline
obligations for the mass revocation event.

In any case, I think this conversation has served the majority of its
> purpose. This discussion has led to several ideas that would allow us to
> update our JSON document only when we create new shards (which will still
> likely be every 6 to 24 hours), as opposed to on every re-issuance of a
> 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

Thanks for the reminder that CCADB automatically dereferences URLs for
archival purposes, and for the info about existing automation! I don't
personally have CCADB credentials, so all of my knowledge of it is based on
what I've learned from others at LE and from this list.

If we leave out the "new url for each re-issuance of a given CRL" portion
of the design (or offer both url-per-thisUpdate and
static-url-always-pointing-at-the-latest), then we could in fact include
CRLDP urls in the certificates using the rolling time-based shards model.
And frankly we may want to do that in the near future: maintaining both CRL
*and* OCSP infrastructure when the BRs require only one or the other is an
unnecessary expense, and turning down our OCSP infrastructure would
constitute a significant savings, both in tangible bills and in engineering
effort.

Thus, in my mind, the dynamic sharding idea you outlined has two major
downsides:
1) It requires us to maintain our parallel OCSP infrastructure
indefinitely, and
2) It is much less resilient in the face of a mass revocation event.

Fundamentally, we need our infrastructure to be able to handle the
revocation of 200M certificates in 24 hours without any difference from how
it handles the revocation of one certificate in the same period. Already
having certificates pre-allocated into CRL shards means that we can
deterministically sign many CRLs in parallel.

Dynamically assigning certificates to CRLs as they are revoked requires
taking a lock to determine if a new CRL needs to be created or not, and
then atomically creating a new one. Or it requires a separate,
not-operation-as-normal process to allocate a bunch of new CRLs, assign
certs to them, and then sign those in parallel. Neither of these --
dramatically changing not just the quantity but the *quality* of the
database access, nor introducing additional processes -- is acceptable in
the face of a mass revocation event.

In any case, I think this conversation has served the majority of its
purpose. This discussion has led to several ideas that would allow us to
update our JSON document only when we create new shards (which will still
likely be every 6 to 24 hours), as opposed to on every re-issuance of a
shard. We'd still greatly prefer that CCADB be willing to
accept-and-dereference a URL to a JSON document, as it would allow our
systems to have fewer dependencies and fewer failure modes, but understand
that our arguments may not be persuasive enough :)

If Mozilla et al. do go forward with this proposal as-is, I'd like to
specifically request that CCADB surfaces an API to update this field before
any root programs require that it be populated, and does so with sufficient
lead time for development against the API to occur.

Thanks again,
Aaron

On Fri, Feb 26, 2021 at 8:47 AM Ryan Sleevi  wrote:

>
>
> On Fri, Feb 26, 2021 at 5:49 AM Rob Stradling  wrote:
>
>> > We already have automation for CCADB. CAs can and do use it for
>> disclosure of intermediates.
>>
>> Any CA representatives that are surprised by this statement might want to
>> go and read the "CCADB Release Notes" (click the hyperlink when you
>> login to the CCADB).  That's the only place I've seen the CCADB API
>> "announced".
>>
>> > Since we're talking Let's Encrypt, the assumption here is that the CRL
>> URLs
>> > will not be present within the crlDistributionPoints of the
>> certificates,
>> > otherwise, this entire discussion is fairly moot, since those
>> > crlDistributionPoints can be obtained directly from Certificate T
>> ransparency.
>>
>> AIUI, Mozilla is moving towards requiring that the CCADB holds all CRL
>> URLs, even the ones that also appear in crlDistributionPoints extensions.
>> Therefore, I think that this entire discussion is not moot at all.
>>
>
> Rob,
>
> I think you misparsed, but that's understandable, because I worded it
> poorly. The discussion is mooted by whether or not the CA includes the
> cRLDP within the certificate itself - i.e. that the CA has to allocate the
> shard at issuance time and that it's fixed for the lifetime of the
> certificate. That's not a requirement - EEs don't need cRLDPs - and so
> there's no inherent need to do static assignment, nor does it sound like LE
> is looking to go that route, since it would be incompatible with the design
> they outlined. Because of this, the dynamic sharding discussed seems
> significantly _less_ complex, both for producers and for consumers of this
> data, than the static sharding-and-immutability scheme proposed.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 25, 2021 at 7:55 PM Clint Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think it makes sense to separate out the date for domain validation
> expiration from the issuance of server certificates with previously
> validated domain names, but agree with Ben that the timeline doesn’t seem
> to need to be prolonged. What about something like this:
>
> 1. Domain name or IP address verifications performed on or after July 1,
> 2021 may be reused for a maximum of 398 days.
> 2. Server certificates issued on or after September 1, 2021 must have
> completed domain name or IP address verification within the preceding 398
> days.
>
> This effectively stretches the “cliff” out across ~6 months (now through
> the end of August), which seems reasonable.
>

Yeah, that does sound reasonable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

On Fri, Feb 26, 2021 at 5:49 AM Rob Stradling  wrote:

> > We already have automation for CCADB. CAs can and do use it for
> disclosure of intermediates.
>
> Any CA representatives that are surprised by this statement might want to
> go and read the "CCADB Release Notes" (click the hyperlink when you login
> to the CCADB).  That's the only place I've seen the CCADB API "announced".
>
> > Since we're talking Let's Encrypt, the assumption here is that the CRL
> URLs
> > will not be present within the crlDistributionPoints of the certificates,
> > otherwise, this entire discussion is fairly moot, since those
> > crlDistributionPoints can be obtained directly from Certificate T
> ransparency.
>
> AIUI, Mozilla is moving towards requiring that the CCADB holds all CRL
> URLs, even the ones that also appear in crlDistributionPoints extensions.
> Therefore, I think that this entire discussion is not moot at all.
>

Rob,

I think you misparsed, but that's understandable, because I worded it
poorly. The discussion is mooted by whether or not the CA includes the
cRLDP within the certificate itself - i.e. that the CA has to allocate the
shard at issuance time and that it's fixed for the lifetime of the
certificate. That's not a requirement - EEs don't need cRLDPs - and so
there's no inherent need to do static assignment, nor does it sound like LE
is looking to go that route, since it would be incompatible with the design
they outlined. Because of this, the dynamic sharding discussed seems
significantly _less_ complex, both for producers and for consumers of this
data, than the static sharding-and-immutability scheme proposed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Rob Stradling via dev-security-policy]

> We already have automation for CCADB. CAs can and do use it for disclosure of 
> intermediates.

Any CA representatives that are surprised by this statement might want to go 
and read the "CCADB Release Notes" (click the hyperlink when you login to the 
CCADB).  That's the only place I've seen the CCADB API "announced".

> Since we're talking Let's Encrypt, the assumption here is that the CRL URLs
> will not be present within the crlDistributionPoints of the certificates,
> otherwise, this entire discussion is fairly moot, since those
> crlDistributionPoints can be obtained directly from Certificate Transparency.

AIUI, Mozilla is moving towards requiring that the CCADB holds all CRL URLs, 
even the ones that also appear in crlDistributionPoints extensions.  Therefore, 
I think that this entire discussion is not moot at all.

Ben's placeholder text:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 26 February 2021 06:02
To: Aaron Gable 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 
; Kathleen Wilson 

Subject: Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs 
Issued By This CA

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On Thu, Feb 25, 2021 at 8:21 PM Aaron Gable  wrote:

> If I may, I believe that the problem is less that it is a reference (which
> is true of every URL stored in CCADB), and more that it is a reference to
> an unsigned object.
>

While that's a small part, it really is as I said: the issue of being a
reference. We've already had this issue with the other URL fields, and thus
there exists logic to dereference and archive those URLs within CCADB.
Issues like audit statements, CP, and CPSes are all things that are indeed
critical to understanding the posture of a CA over time, and so actually
having those materials in something stable and maintained (without a
dependence on the CA) is important.  It's the lesson from those
various past failure modes that had Google very supportive of the non-URL
based approach, putting the JSON directly in CCADB, rather than forcing yet
another "update-and-fetch" system.. You're absolutely correct
that the "configured by CA" element has the nice property of being assured
that the change came from the CA themselves, without requiring signing, but
I wouldn't want to reduce the concern to just that.

* I'm not aware of any other automation system with write-access to CCADB
> (I may be very wrong!), and I imagine there would need to be some sort of
> further design discussion with CCADB's maintainers about what it means to
> give write credentials to an automated system, what sorts of protections
> would be necessary around those credentials, how to scope those credentials
> as narrowly as possible, and more.
>

We already have automation for CCADB. CAs can and do use it for disclosure
of intermediates.


> * I'm not sure CCADB's maintainers want updates to it to be in the
> critical path of ongoing issuance, as opposed to just in the critical path
> for beginning issuance with a new issuer.
>

Without wanting to sound dismissive, whether or not it's in a critical path
of updating is the CA's choice on their design. I understand that there are
designs that could put it there, I think the question is whether it's
reasonable for the CA to have done that in the first place, which is why
it's important to drill down into these concerns. I know you merely
qualified it as undesirable, rather than actually being a blocker, and I
appreciate that, but I do think some of these concerns are perhaps less
grounded or persuasive than others :)

Taking a step back here, I think there's been a fundamental design error in
your proposed design, and I think that it, combined with the (existing)
automation, may make much of this not actually be the issue you anticipate.

Since we're talking Let's Encrypt, the assumption here is that the CRL URLs
will not be present within the crlDistributionPoints of the certificates,
otherwise, this entire discussion is fairly moot, since those
crlDistributionPoints can be obtained directly from Certificate
Transparency.

The purpose of this field is to help discover CRLs that are otherwise not
discoverable (e.g. from CT), but this also means that these CRLs do not
suffer from the same design limitations of PKI. Recall that there's nothing
intrinsic to a CRL that expresses its sharding algorithm (ignoring, for a
second, reasonCodes within the IDP extension). The only observability that
an external (not-the-CA) party has, whether the Subscriber or the RP, is
merely that "the CRL DP for this certificate is different from the CRLDP
for that certificate". It is otherwise opaque how the CA used it, even if
through a large enough corpus from CT, 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 25, 2021 at 8:21 PM Aaron Gable  wrote:

> If I may, I believe that the problem is less that it is a reference (which
> is true of every URL stored in CCADB), and more that it is a reference to
> an unsigned object.
>

While that's a small part, it really is as I said: the issue of being a
reference. We've already had this issue with the other URL fields, and thus
there exists logic to dereference and archive those URLs within CCADB.
Issues like audit statements, CP, and CPSes are all things that are indeed
critical to understanding the posture of a CA over time, and so actually
having those materials in something stable and maintained (without a
dependence on the CA) is important.  It's the lesson from those
various past failure modes that had Google very supportive of the non-URL
based approach, putting the JSON directly in CCADB, rather than forcing yet
another "update-and-fetch" system.. You're absolutely correct
that the "configured by CA" element has the nice property of being assured
that the change came from the CA themselves, without requiring signing, but
I wouldn't want to reduce the concern to just that.

* I'm not aware of any other automation system with write-access to CCADB
> (I may be very wrong!), and I imagine there would need to be some sort of
> further design discussion with CCADB's maintainers about what it means to
> give write credentials to an automated system, what sorts of protections
> would be necessary around those credentials, how to scope those credentials
> as narrowly as possible, and more.
>

We already have automation for CCADB. CAs can and do use it for disclosure
of intermediates.


> * I'm not sure CCADB's maintainers want updates to it to be in the
> critical path of ongoing issuance, as opposed to just in the critical path
> for beginning issuance with a new issuer.
>

Without wanting to sound dismissive, whether or not it's in a critical path
of updating is the CA's choice on their design. I understand that there are
designs that could put it there, I think the question is whether it's
reasonable for the CA to have done that in the first place, which is why
it's important to drill down into these concerns. I know you merely
qualified it as undesirable, rather than actually being a blocker, and I
appreciate that, but I do think some of these concerns are perhaps less
grounded or persuasive than others :)

Taking a step back here, I think there's been a fundamental design error in
your proposed design, and I think that it, combined with the (existing)
automation, may make much of this not actually be the issue you anticipate.

Since we're talking Let's Encrypt, the assumption here is that the CRL URLs
will not be present within the crlDistributionPoints of the certificates,
otherwise, this entire discussion is fairly moot, since those
crlDistributionPoints can be obtained directly from Certificate
Transparency.

The purpose of this field is to help discover CRLs that are otherwise not
discoverable (e.g. from CT), but this also means that these CRLs do not
suffer from the same design limitations of PKI. Recall that there's nothing
intrinsic to a CRL that expresses its sharding algorithm (ignoring, for a
second, reasonCodes within the IDP extension). The only observability that
an external (not-the-CA) party has, whether the Subscriber or the RP, is
merely that "the CRL DP for this certificate is different from the CRLDP
for that certificate". It is otherwise opaque how the CA used it, even if
through a large enough corpus from CT, you can infer the algorithm from the
pattern. Further, when such shards are being used, you can observe that a
given CRL that you have (whose provenance may be unknown) can be known
whether or not it covers a given certificate by matching the CRLDP of the
cert against the IDP of the CRL.  We're talking about a scenario in which
the certificate lacks a CRLDP, and so there's no way to know that, indeed,
a given CRL "covers" the certificate unambiguously. The only thing we have
is the CRL having an IDP, because if it didn't, it'd have to be a full CRL,
and then you'd be back to only having one URL to worry about.

Because of all of this, it means that the consumers of this JSON are
expected to combine all of the CRLs present, union all the revoked serials,
and be done with it. However, it's that unioning that I think you've
overlooked here in working out your math. In the "classic" PKI sense (i.e.
CRLDP present), the CA has to plan for revocation for the lifetime of the
certificate, it's fixed when the certificate is created, and it's immutable
once created. Further, changes in revocation frequency mean you need to
produce new versions of that specific CRL. However, the scenario we're
discussing, in which these CRLs are unioned, you're entirely flexible at
all points in time for how you balance your CRLs. Further, in the 'ideal'
case (no revocations), you need only produce a single empty CRL. There's no
need to produce an 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

Similarly, snipping and replying to portions of your message below:

On Thu, Feb 25, 2021 at 12:52 PM Ryan Sleevi  wrote:

> Am I understanding your proposal correctly that "any published JSON
> document be valid for a certain period of time" effectively means that each
> update of the JSON document also gets a distinct URL (i.e. same as the
> CRLs)?
>

No, the (poorly expressed) idea is this: suppose you fetch our
rapidly-changing document and get version X. Over the next five minutes,
you fetch every CRL URL in that document. But during that same five
minutes, we've published versions X+1 and X+2 of that JSON document at that
same URL. There should be a guarantee that, as long as you fetch the CRLs
in your document "fast enough" (for some to-be-determined value of "fast"),
all of those URLs will still be valid (i.e. not return a 404 or similar),
*even though* some of them are not referenced by the most recent version of
the JSON document.

This may seem like a problem that arises only in our rapidly-changing JSON
version of things. But I believe it should be a concern even in the system
as proposed by Kathleen: when a CA updates the JSON array contained in
CCADB, how long does a consumer of CCADB have to get a snapshot of the
contents of the previous set of URLs? To posit an extreme hypothetical, can
a CA hide misissuance of a CRL by immediately hosting their fixed CRL at a
new URL and updating their CCADB JSON list to include that new URL instead?
Not to put too fine a point on it, but I believe that this sort of
hypothetical is the underlying worry about having the JSON list live
outside CCADB where it can be changed on a whim, but I'm not sure that
having the list live inside CCADB without any requirements on the validity
of the URLs inside it provides significantly more auditability.

The issue I see with the "URL stored in CCADB" is that it's a reference,
> and the dereferencing operation (retrieving the URL) puts the onus on the
> consumer (e.g. root stores) and can fail, or result in different content
> for different parties, undetectably.
>

If I may, I believe that the problem is less that it is a reference (which
is true of every URL stored in CCADB), and more that it is a reference to
an unsigned object. URLs directly to CRLs don't have this issue, because
the CRL is signed. And storing the JSON array directly doesn't have this
issue, because it is implicitly signed by the credentials of the user who
signed in to CCADB to modify it. One possible solution here would be to
require that the JSON document be signed by the same CA certificate which
issued all of the CRLs contained in it. I don't think I like this solution,
but it is within the possibility space.


> If there is an API that allows you to modify the JSON contents directly
> (e.g. a CCADB API call you could make with an OAuth token), would that
> address your concern?
>

If Mozilla and the other stakeholders in CCADB decide to go with this
thread's proposal as-is, then I suspect that yes, we would develop
automation to talk to CCADB's API in exactly this way. This is undesired
from our perspective for a variety of reasons:
* I'm not aware of a well-maintained Go library for interacting with the
Salesforce API.
* I'm not aware of any other automation system with write-access to CCADB
(I may be very wrong!), and I imagine there would need to be some sort of
further design discussion with CCADB's maintainers about what it means to
give write credentials to an automated system, what sorts of protections
would be necessary around those credentials, how to scope those credentials
as narrowly as possible, and more.
* I'm not sure CCADB's maintainers want updates to it to be in the critical
path of ongoing issuance, as opposed to just in the critical path for
beginning issuance with a new issuer.

I think the question was with respect to the frequency of change of those
> documents.
>

Frankly, I think the least frequent creation of a new time-sharded CRL we
would be willing to do is once every 24 hours (that's still >60MB per CRL
in the worst case). That's going to require automation no matter what.


> There is one thing you mentioned that's also non-obvious to me, because I
> would expect you already have to deal with this exact issue with respect to
> OCSP, which is "overwriting files is a dangerous operation prone to many
> forms of failure". Could you expand more about what some of those
> top-concerns are? I ask, since, say, an OCSP Responder is frequently
> implemented as "Spool /ocsp/:issuerDN/:serialNumber", with the CA
> overwriting :serialNumber whenever they produce new responses. It sounds
> like you're saying that common design pattern may be problematic for y'all,
> and I'm curious to learn more.
>

Sure, happy to expand. For those following along at home, this last bit is
relatively off-topic compared to the other sections above, so skip if you
feel like it :)

OCSP consists of hundreds of millions of small entries. Thus our 

The Ace Care Center Team has received your request []

[Ace Care Center via dev-security-policy]

……..

Please do not reply to this email.

……..

 

Hello from the Ace Care Center Team!

  

Thank you for your recent request. Because of added safety measures for our 
employees due to Coronavirus and increased call center traffic, there may be 
delays in response time. Please know that we are working as quickly as possible 
during these challenging circumstances.

 

Sincerely,

Ace Care Center Team

Helpful is our Business – Caring is our Commitment

 

 

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

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Clint Wilson via dev-security-policy]

I think it makes sense to separate out the date for domain validation 
expiration from the issuance of server certificates with previously validated 
domain names, but agree with Ben that the timeline doesn’t seem to need to be 
prolonged. What about something like this:

1. Domain name or IP address verifications performed on or after July 1, 2021 
may be reused for a maximum of 398 days.
2. Server certificates issued on or after September 1, 2021 must have completed 
domain name or IP address verification within the preceding 398 days.

This effectively stretches the “cliff” out across ~6 months (now through the 
end of August), which seems reasonable.

Cheers!
-Clint

> On Feb 25, 2021, at 11:40 AM, Ben Wilson via dev-security-policy 
>  wrote:
> 
> Yes - I think we could focus on the domain validations themselves and allow
> domain validations to be reused for 398 days (maybe even from December 6,
> 2019), and then combine that with certificate issuance, but I'm not sure I
> like pushing this out to Feb 1, 2022 or even Oct. 1, 2021.  Maybe someone
> else on the list has a suggested formula?
> 
> On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie 
> wrote:
> 
>> Ben,
>> 
>> I'd prefer that we tie this to a date related to when the domain
>> validations are done, or perhaps 2 statements.  As it stands (and as others
>> have commented), on July 1 all customers will immediately need to validate
>> all domains that were done between 825 and 397 days ago, so a huge number
>> all at once for web site owners and for CAs.
>> 
>> I'd prefer that it says " Domain validations performed from July 1, 2021
>> may be reused for a maximum of 398 days ".  I understand that this
>> basically kick the can down the road for an extra year and that may not be
>> acceptable, so, maybe we specify 2 dates:
>> 
>> 1)  Domain validations performed on or after July 1, 2021 may be reused
>> for a maximum of 398 days.
>> 
>> 2)  for server certificates issued on or after Feb 1, 2022, each dNSName
>> or IPAddress in a SAN must have been validated within the prior 398 days
>> 
>> Is that a compromise you could consider?
>> 
>> Doug
>> 
>> 
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Thursday, February 25, 2021 2:08 PM
>> To: Mozilla 
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>> 
>> All,
>> 
>> I continue to move this Issue #206 forward with a proposed change to
>> section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or
>> section 4.2.1 of the CA/B Forum's Baseline Requirements).
>> 
>> Currently, I am still contemplating adding a subsection 5.1 to MRSP section
>> 2.1 that would read,
>> " 5.1. for server certificates issued on or after July 1, 2021, verify
>> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
>> or less;"
>> 
>> See draft language here
>> 
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3
>> 
>> 
>> Ben
>> 
>> On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson  wrote:
>> 
>>> All,
>>> 
>>> I have started a similar, simultaneous discussion with the CA/Browser
>>> Forum, in order to gain traction.
>>> 
>>> 
>>> 
>>> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/00238
>>> 2.html
>>> 
>>> Ben
>>> 
>>> On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley
>>> 
>>> wrote:
>>> 
 Should this limit on reuse also apply to s/MIME? Right now, the 825
 day limit in Mozilla policy only applies to TLS certs with email
 verification of s/MIME being allowed for infinity time.  The first
 draft of the language looked like it may change this while the newer
 language puts back the TLS limitation. If it's not addressed in this
 update, adding clarification on domain verification reuse for SMIME
 would be a good improvement on the existing policy.
 
 -Original Message-
 From: dev-security-policy
 
 On Behalf Of Ben Wilson via dev-security-policy
 Sent: Wednesday, December 2, 2020 2:22 PM
 To: Ryan Sleevi 
 Cc: Doug Beattie ; Mozilla <
 mozilla-dev-security-pol...@lists.mozilla.org>
 Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain
 name verification to 398 days
 
 See my responses inline below.
 
 On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
 
> 
> 
> On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> See responses inline below:
>> 
>> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie
>> >> 
>> wrote:
>> 
>>> Hi Ben,
>>> 
>>> For now I won’t comment on the 398 day limit or the date which
>>> you
>> propose
>>> this to take effect (July 1, 2021), but on the ability of CAs to
>>> re-use domain validations completed prior to 1 July for 

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 25, 2021 at 2:29 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'd prefer that we tie this to a date related to when the domain
> validations are done, or perhaps 2 statements.  As it stands (and as others
> have commented), on July 1 all customers will immediately need to validate
> all domains that were done between 825 and 397 days ago, so a huge number
> all at once for web site owners and for CAs.
>

Isn't this only true if CAs use this discussion period to do nothing?

That is, can't CAs today (or even months ago) have started to more
frequently revalidate their customers, refreshing old validations, helping
transition customers to automated methods, etc?

That is, is the scenario you described inherently bad, or just a
consequence of CA inaction? And is the goal to have zero impact, or, which
your proposal seems to acknowledge, do we agree that some impact is both
reasonable and acceptable, and the only difference would be the degree?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

Hugely useful! Thanks for sharing - this is incredibly helpful.

I've snipped a good bit, just to keep the thread small, and have some
further questions inline.

On Thu, Feb 25, 2021 at 2:15 PM Aaron Gable  wrote:

> I believe that there is an argument to be made here that this plan
> increases the auditability of the CRLs, rather than decreases it. Root
> programs could require that any published JSON document be valid for a
> certain period of time, and that all CRLs within that document remain
> available for that period as well. Or even that historical versions of CRLs
> remain available until every certificate they cover has expired (which is
> what we intend to do anyway). Researchers can crawl our history of CRLs and
> examine revocation events in more detail than previously available.
>

So I think unpacking this a little: Am I understanding your proposal
correctly that "any published JSON document be valid for a certain period
of time" effectively means that each update of the JSON document also gets
a distinct URL (i.e. same as the CRLs)? I'm not sure if that's what you
meant, because it would still mean regularly updating CCADB whenever your
shard-set changes (which seems to be the concern), but at the same time, it
would seem that any validity requirement imposes on you a lower-bound for
how frequently you can change or introduce new shards, right?

The issue I see with the "URL stored in CCADB" is that it's a reference,
and the dereferencing operation (retrieving the URL) puts the onus on the
consumer (e.g. root stores) and can fail, or result in different content
for different parties, undetectably. If it was your proposal to change to
distinct URLs, that issue would still unfortunately exist.

If there is an API that allows you to modify the JSON contents directly
(e.g. a CCADB API call you could make with an OAuth token), would that
address your concern? It would allow CCADB to still canonically record the
change history and contents, facilitating that historic research. It would
also facilitate better compliance tracking - since we know policies like
"could require that any published JSON" don't really mean anything in
practice for a number of CAs, unless the requirements are also monitored
and enforced.


> Regardless, even without statically-pathed, timestamped CRLs, I believe
> that the merits of rolling time-based shards are sufficient to be a strong
> argument in favor of dynamic JSON documents.
>

Right, I don't think there's any fundamental opposition to that. I'm very
much in favor of time-sharded CRLs over hash-sharded CRLs, for exactly the
reasons you highlight. I think the question was with respect to the
frequency of change of those documents (i.e. how often you introduce new
shards, and how those shards are represented).

There is one thing you mentioned that's also non-obvious to me, because I
would expect you already have to deal with this exact issue with respect to
OCSP, which is "overwriting files is a dangerous operation prone to many
forms of failure". Could you expand more about what some of those
top-concerns are? I ask, since, say, an OCSP Responder is frequently
implemented as "Spool /ocsp/:issuerDN/:serialNumber", with the CA
overwriting :serialNumber whenever they produce new responses. It sounds
like you're saying that common design pattern may be problematic for y'all,
and I'm curious to learn more.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

Yes - I think we could focus on the domain validations themselves and allow
domain validations to be reused for 398 days (maybe even from December 6,
2019), and then combine that with certificate issuance, but I'm not sure I
like pushing this out to Feb 1, 2022 or even Oct. 1, 2021.  Maybe someone
else on the list has a suggested formula?

On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie 
wrote:

> Ben,
>
> I'd prefer that we tie this to a date related to when the domain
> validations are done, or perhaps 2 statements.  As it stands (and as others
> have commented), on July 1 all customers will immediately need to validate
> all domains that were done between 825 and 397 days ago, so a huge number
> all at once for web site owners and for CAs.
>
> I'd prefer that it says " Domain validations performed from July 1, 2021
> may be reused for a maximum of 398 days ".  I understand that this
> basically kick the can down the road for an extra year and that may not be
> acceptable, so, maybe we specify 2 dates:
>
> 1)  Domain validations performed on or after July 1, 2021 may be reused
> for a maximum of 398 days.
>
> 2)  for server certificates issued on or after Feb 1, 2022, each dNSName
> or IPAddress in a SAN must have been validated within the prior 398 days
>
> Is that a compromise you could consider?
>
> Doug
>
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, February 25, 2021 2:08 PM
> To: Mozilla 
> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
> All,
>
> I continue to move this Issue #206 forward with a proposed change to
> section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or
> section 4.2.1 of the CA/B Forum's Baseline Requirements).
>
> Currently, I am still contemplating adding a subsection 5.1 to MRSP section
> 2.1 that would read,
> " 5.1. for server certificates issued on or after July 1, 2021, verify
> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days
> or less;"
>
> See draft language here
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3
>
>
> Ben
>
> On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson  wrote:
>
> > All,
> >
> > I have started a similar, simultaneous discussion with the CA/Browser
> > Forum, in order to gain traction.
> >
> > 
> >
> > https://lists.cabforum.org/pipermail/servercert-wg/2020-December/00238
> > 2.html
> >
> > Ben
> >
> > On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley
> > 
> > wrote:
> >
> >> Should this limit on reuse also apply to s/MIME? Right now, the 825
> >> day limit in Mozilla policy only applies to TLS certs with email
> >> verification of s/MIME being allowed for infinity time.  The first
> >> draft of the language looked like it may change this while the newer
> >> language puts back the TLS limitation. If it's not addressed in this
> >> update, adding clarification on domain verification reuse for SMIME
> >> would be a good improvement on the existing policy.
> >>
> >> -Original Message-
> >> From: dev-security-policy
> >> 
> >> On Behalf Of Ben Wilson via dev-security-policy
> >> Sent: Wednesday, December 2, 2020 2:22 PM
> >> To: Ryan Sleevi 
> >> Cc: Doug Beattie ; Mozilla <
> >> mozilla-dev-security-pol...@lists.mozilla.org>
> >> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain
> >> name verification to 398 days
> >>
> >> See my responses inline below.
> >>
> >> On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
> >>
> >> >
> >> >
> >> > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
> >> > dev-security-policy@lists.mozilla.org> wrote:
> >> >
> >> >> See responses inline below:
> >> >>
> >> >> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie
> >> >>  >> >> >
> >> >> wrote:
> >> >>
> >> >> > Hi Ben,
> >> >> >
> >> >> > For now I won’t comment on the 398 day limit or the date which
> >> >> > you
> >> >> propose
> >> >> > this to take effect (July 1, 2021), but on the ability of CAs to
> >> >> > re-use domain validations completed prior to 1 July for their
> >> >> > full
> >> >> > 825 re-use period.  I'm assuming that the 398 day limit is only
> >> >> > for those domain validated on or after 1 July, 2021.  Maybe that
> >> >> > is your intent, but the wording is not clear (it's never been
> >> >> > all that
> >> >> > clear)
> >> >> >
> >> >>
> >> >> Yes. (I agree that the wording is currently unclear and can be
> >> >> improved, which I'll work on as discussion progresses.)  That is
> >> >> the intent - for certificates issued beginning next July--new
> >> >> validations would be valid for
> >> >> 398 days, but existing, reused validations would be sunsetted and
> >> >> could be used for up to 825 days (let's say, until Oct. 1, 2023,
> >> >> which I'd advise against, given the benefits of freshness provided
> >> >> by re-performing methods in BR 3.2.2.4 and BR 3.2.2.5).
> >> 

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

I haven't seen any response to my question about whether there is still a
concern over the language "as evidenced by a Qualified Auditor's key
destruction report".
I did add "This cradle-to-grave audit requirement applies equally to
subordinate CAs as it does to root CAs" to address the scenarios that were
raised.
So I am going to assume that this issue is resolved and that we can move
this proposed change forward.
See
https://github.com/BenWilson-Mozilla/pkipolicy/commit/c8bdb949020634b1f8fa31bc060229c600fe6f9d

On Fri, Feb 12, 2021 at 11:16 AM Ben Wilson  wrote:

> All,
>
> The proposed change currently reads,
>
> "Full-surveillance period-of-time audits MUST be conducted and updated
> audit information provided no less frequently than annually from the time
> of CA key pair generation until the CA certificate is no longer trusted by
> Mozilla's root store or until all copies of the CA private key have been
> completely destroyed, as evidenced by a Qualified Auditor's key destruction
> report, whichever occurs sooner. This cradle-to-grave audit requirement
> applies equally to subordinate CAs as it does to root CAs. Successive
> period-of-time audits MUST be contiguous (no gaps)."
> But is the argument that I should also add something along these
> lines--"This cradle-to-grave audit requirement applies equally to ...,  *and
> an audit would be required for all subordinate CAs until their private keys
> have been completely destroyed as well*."?  Is that still the issue
> here?  Or has it already been resolved with the language further above?
>
> Thanks,
>
> Ben
>
> On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson  wrote:
>
>> I agree that we should add language that makes it more clear that the key
>> destruction exception for audit only applies to the CA certificates whose
>> key has been destroyed.  I'm also hoping that a CAO wouldn't destroy a Root
>> CA key if there were still valid subordinate CAs that the CAO might need to
>> revoke.
>>
>> On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> On 2020-11-05 22:43, Tim Hollebeek wrote:
>>> > So, I'd like to drill down a bit more into one of the cases you
>>> discussed.
>>> > Let's assume the following:
>>> >
>>> > 1. The CAO [*] may or may not have requested removal of the CAC, but
>>> removal
>>> > has not been completed.  The CAC is still trusted by at least one
>>> public
>>> > root program.
>>> >
>>> > 2. The CAO has destroyed the CAK for that CAC.
>>> >
>>> > The question we've been discussing internally is whether destruction
>>> alone
>>> > should be sufficient to get you out of audits, and we're very skeptical
>>> > that's desirable.
>>> >
>>> > The problem is that destruction of the CAK does not prevent issuance by
>>> > subCAs, so issuance is still possible.  There is also the potential
>>> > possibility of undisclosed subCAs or cross relationships to consider,
>>> > especially since some of these cases are likely to be shutdown
>>> scenarios for
>>> > legacy, poorly managed hierarchies.  Removal may be occurring
>>> *precisely*
>>> > because there are doubts about the history, provenance, or scope of
>>> previous
>>> > operations and audits.
>>> >
>>> > We're basically questioning whether there are any scenarios where
>>> allowing
>>> > someone to escape audits just because they destroyed the key is likely
>>> to
>>> > lead to good outcomes as opposed to bad ones.  If there aren't
>>> reasonable
>>> > scenarios where it is necessary to be able to remove CACs from audit
>>> scope
>>> > through key destruction while they are still trusted by Mozilla, it's
>>> > probably best to require audits as long as the CACs are in scope for
>>> > Mozilla.
>>> >
>>> > Alternatively, if there really are cases where this needs to be done,
>>> it
>>> > would be wise to craft language that limits this exception to those
>>> > scenarios.
>>> >
>>>
>>> I believe that destruction of the Root CA Key should only end audit
>>> requirements for the corresponding Root CA itself, not for any of its
>>> still trusted SubCAs.
>>>
>>> One plausible (but hypothetical) sequence of events is this:
>>>
>>> 1. Begin Root ceremony with Auditors present.
>>>
>>> 1.1 Create Root CA Key pair
>>> 1.2 Sign Root CA SelfCert
>>> 1.3 Create 5 SubCA Key pairs
>>> 1.4 Sign 5 SubCA pre-certificates
>>> 1.5 Request CT Log entries for the 5 SubCA pre-certificates
>>> 1.6 Sign 5 SubCA certificates with embedded CTs
>>> 1.7 Sign, but do not publish a set of post-dated CRLs for various
>>> contingencies
>>> 1.8 Sign, but do not publish a set of post-dated revocation OCSP
>>> responses for those contingencies
>>> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation
>>> OCSP responses confirming that the SubCAs have not been revoked on each
>>> date during their validity.
>>> 1.10 Destroy Root CA Key pair.
>>>
>>> 2. Initiate audited storage of the unreleased CRL and OCSP signatures.
>>>
>>> 3. End Root 

RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Doug Beattie via dev-security-policy]

Ben,

I'd prefer that we tie this to a date related to when the domain validations 
are done, or perhaps 2 statements.  As it stands (and as others have 
commented), on July 1 all customers will immediately need to validate all 
domains that were done between 825 and 397 days ago, so a huge number all at 
once for web site owners and for CAs.

I'd prefer that it says " Domain validations performed from July 1, 2021 may be 
reused for a maximum of 398 days ".  I understand that this basically kick the 
can down the road for an extra year and that may not be acceptable, so, maybe 
we specify 2 dates:

1)  Domain validations performed on or after July 1, 2021 may be reused for a 
maximum of 398 days.

2)  for server certificates issued on or after Feb 1, 2022, each dNSName or 
IPAddress in a SAN must have been validated within the prior 398 days

Is that a compromise you could consider?

Doug


-Original Message-
From: dev-security-policy  On 
Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, February 25, 2021 2:08 PM
To: Mozilla 
Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name 
verification to 398 days

All,

I continue to move this Issue #206 forward with a proposed change to section 
2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or section 
4.2.1 of the CA/B Forum's Baseline Requirements).

Currently, I am still contemplating adding a subsection 5.1 to MRSP section
2.1 that would read,
" 5.1. for server certificates issued on or after July 1, 2021, verify each 
dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;"

See draft language here
https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3


Ben

On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson  wrote:

> All,
>
> I have started a similar, simultaneous discussion with the CA/Browser 
> Forum, in order to gain traction.
>
> 
>
> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/00238
> 2.html
>
> Ben
>
> On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley 
> 
> wrote:
>
>> Should this limit on reuse also apply to s/MIME? Right now, the 825 
>> day limit in Mozilla policy only applies to TLS certs with email 
>> verification of s/MIME being allowed for infinity time.  The first 
>> draft of the language looked like it may change this while the newer 
>> language puts back the TLS limitation. If it's not addressed in this 
>> update, adding clarification on domain verification reuse for SMIME 
>> would be a good improvement on the existing policy.
>>
>> -Original Message-
>> From: dev-security-policy 
>> 
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Wednesday, December 2, 2020 2:22 PM
>> To: Ryan Sleevi 
>> Cc: Doug Beattie ; Mozilla < 
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain 
>> name verification to 398 days
>>
>> See my responses inline below.
>>
>> On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
>>
>> >
>> >
>> > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < 
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> See responses inline below:
>> >>
>> >> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie 
>> >> > >> >
>> >> wrote:
>> >>
>> >> > Hi Ben,
>> >> >
>> >> > For now I won’t comment on the 398 day limit or the date which 
>> >> > you
>> >> propose
>> >> > this to take effect (July 1, 2021), but on the ability of CAs to 
>> >> > re-use domain validations completed prior to 1 July for their 
>> >> > full
>> >> > 825 re-use period.  I'm assuming that the 398 day limit is only 
>> >> > for those domain validated on or after 1 July, 2021.  Maybe that 
>> >> > is your intent, but the wording is not clear (it's never been 
>> >> > all that
>> >> > clear)
>> >> >
>> >>
>> >> Yes. (I agree that the wording is currently unclear and can be 
>> >> improved, which I'll work on as discussion progresses.)  That is 
>> >> the intent - for certificates issued beginning next July--new 
>> >> validations would be valid for
>> >> 398 days, but existing, reused validations would be sunsetted and 
>> >> could be used for up to 825 days (let's say, until Oct. 1, 2023, 
>> >> which I'd advise against, given the benefits of freshness provided 
>> >> by re-performing methods in BR 3.2.2.4 and BR 3.2.2.5).
>> >>
>> >
>> > Why? I have yet to see a compelling explanation from a CA about why 
>> > "grandfathering" old validations is good, and as you note, it 
>> > undermines virtually every benefit that is had by the reduction 
>> > until
>> 2023.
>> >
>>
>> I am open to the idea of cutting off the tail earlier, at let's say, 
>> October 1, 2022, or earlier (see below).  I can work on language that 
>> does that.
>>
>>
>> >
>> > Ben, could you explain the rationale why this is better than the 
>> > simpler, clearer, and immediately beneficial for Mozilla users of 
>> > requiring new validations be 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

Sure, happy to provide more details! The fundamental issue here is the
scale at which Let's Encrypt issues, and the automated nature by which
clients interact with Let's Encrypt.

LE currently has 150M certificates active, all (as of March 1st) signed by
the same issuer certificate, R3. In the event of a mass revocation, that
means a CRL with 150M entries in it. At an average of 38 bytes per entry in
a CRL, that means nearly 6GB worth of CRL. Passing around a single 6GB file
isn't good for reliability (it's much better to fail-and-retry downloading
one of a hundred 60MB files than fail-and-retry a single 6GB file), so
sharding seems like an operational necessity.

Even without a LE-initiated mass revocation event, one of our large
integrators (such as a hosting provider with millions of domains) could
decide for any reason to revoke every single certificate we have issued to
them. We need to be resilient to these kinds of events.

Once we've decided that sharding is necessary, the next question is "static
or dynamic sharding?". It's easy to imagine a world in which we usually
have only one or two CRL shards, but dynamically scale that number up to
keep individual CRL sizes small if/when revocation rises sharply. There are
a lot of "interesting" (read: difficult) engineering problems here, and
we've decided not to go the dynamic route, but even if we did it would
obviously require being able to change the list of URLs in the JSON array
on the fly.

For static sharding, we would need to constantly maintain a large set of
small CRLs, such that even in the worst case no individual CRL would become
too large. I see two main approaches: maintaining a fully static set of
shards into which our certificates are bucketed, or maintaining rolling
time-based shards (much like CT shards).

Maintaining a static set of shards has the primary advantage of "working
like CRLs usually work". A given CRL has a scope (e.g. "all certs issued by
R3 whose serial number is equal to 1 mod 500"), it has a nextUpdate, and a
new CRL with the same scope will be re-issued at the same path before that
nextUpdate is reached. However, it makes re-sharding difficult. If Let's
Encrypt's issuance rises enough that we want to have 1000 shards instead of
500, we'll have to re-shard every cert, re-issue every CRL, and update the
list of URLs in the JSON. And if we're updating the list, we should have
standards around how that list is updated and how its history is stored,
and then we'd prefer that those standards allow for rapid updates.

The alternative is to have rolling time-based shards. In this case, every X
hours we would create a new CRL, and every certificate we issue over the
next period would belong to that CRL. Similar to the above, these CRLs have
nice scopes: "all certs issued by R3 between AA:BB and XX:YY"). When every
certificate in one of these time-based shards has expired, we can simply
stop re-issuing it. This has the advantage of solving the resharding
problem: if we want to make our CRLs smaller, we just increase the
frequency at which we initialize a new one, and 90 days later we've fully
switched over to the new size. It has the disadvantage from your
perspective of requiring us to add a new URL to the JSON array every period
(and we get to drop an old URL from the array every period as well).

So why would we want to put each CRL re-issuance at a new path, and update
our JSON even more frequently? Because we have reason to believe that
various root programs will soon seek CRL re-issuance on the order of every
6 hours, not every 7 days as currently required; we will have many shards;
and overwriting files is a dangerous operation prone to many forms of
failure. Our current plan is to surface CRLs at paths like
`/crls/:issuerID/:shardID/:thisUpdate.der`, so that we never have to
overwrite a file. Similarly, our JSON document can always be written to a
new file, and the path in CCADB can point to a simple handler which always
serves the most recent file. Additionally, this means that anyone in
possession of one of our JSON documents can fetch all the CRLs listed in it
and get a *consistent* view of our revocation information as of that time.

I believe that there is an argument to be made here that this plan
increases the auditability of the CRLs, rather than decreases it. Root
programs could require that any published JSON document be valid for a
certain period of time, and that all CRLs within that document remain
available for that period as well. Or even that historical versions of CRLs
remain available until every certificate they cover has expired (which is
what we intend to do anyway). Researchers can crawl our history of CRLs and
examine revocation events in more detail than previously available.

Regardless, even without statically-pathed, timestamped CRLs, I believe
that the merits of rolling time-based shards are sufficient to be a strong
argument in favor of dynamic JSON documents.

I hope this helps and that I 

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

All,

I continue to move this Issue #206 forward with a proposed change to
section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or
section 4.2.1 of the CA/B Forum's Baseline Requirements).

Currently, I am still contemplating adding a subsection 5.1 to MRSP section
2.1 that would read,
" 5.1. for server certificates issued on or after July 1, 2021, verify each
dNSName or IPAddress in a SAN or commonName at an interval of 398 days or
less;"

See draft language here
https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3


Ben

On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson  wrote:

> All,
>
> I have started a similar, simultaneous discussion with the CA/Browser
> Forum, in order to gain traction.
>
> 
>
> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/002382.html
>
> Ben
>
> On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley 
> wrote:
>
>> Should this limit on reuse also apply to s/MIME? Right now, the 825 day
>> limit in Mozilla policy only applies to TLS certs with email verification
>> of s/MIME being allowed for infinity time.  The first draft of the language
>> looked like it may change this while the newer language puts back the TLS
>> limitation. If it's not addressed in this update, adding clarification on
>> domain verification reuse for SMIME would be a good improvement on the
>> existing policy.
>>
>> -Original Message-
>> From: dev-security-policy 
>> On Behalf Of Ben Wilson via dev-security-policy
>> Sent: Wednesday, December 2, 2020 2:22 PM
>> To: Ryan Sleevi 
>> Cc: Doug Beattie ; Mozilla <
>> mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
>> verification to 398 days
>>
>> See my responses inline below.
>>
>> On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
>>
>> >
>> >
>> > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> See responses inline below:
>> >>
>> >> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie
>> >> > >> >
>> >> wrote:
>> >>
>> >> > Hi Ben,
>> >> >
>> >> > For now I won’t comment on the 398 day limit or the date which you
>> >> propose
>> >> > this to take effect (July 1, 2021), but on the ability of CAs to
>> >> > re-use domain validations completed prior to 1 July for their full
>> >> > 825 re-use period.  I'm assuming that the 398 day limit is only for
>> >> > those domain validated on or after 1 July, 2021.  Maybe that is
>> >> > your intent, but the wording is not clear (it's never been all that
>> >> > clear)
>> >> >
>> >>
>> >> Yes. (I agree that the wording is currently unclear and can be
>> >> improved, which I'll work on as discussion progresses.)  That is the
>> >> intent - for certificates issued beginning next July--new validations
>> >> would be valid for
>> >> 398 days, but existing, reused validations would be sunsetted and
>> >> could be used for up to 825 days (let's say, until Oct. 1, 2023,
>> >> which I'd advise against, given the benefits of freshness provided by
>> >> re-performing methods in BR 3.2.2.4 and BR 3.2.2.5).
>> >>
>> >
>> > Why? I have yet to see a compelling explanation from a CA about why
>> > "grandfathering" old validations is good, and as you note, it
>> > undermines virtually every benefit that is had by the reduction until
>> 2023.
>> >
>>
>> I am open to the idea of cutting off the tail earlier, at let's say,
>> October 1, 2022, or earlier (see below).  I can work on language that does
>> that.
>>
>>
>> >
>> > Ben, could you explain the rationale why this is better than the
>> > simpler, clearer, and immediately beneficial for Mozilla users of
>> > requiring new validations be conducted on-or-after 1 July 2021? Any CA
>> > that had concerns would have ample time to ensure there is a fresh
>> > domain validation before then, if they were concerned.
>> >
>>
>> I don't have anything yet in particular with regard to a
>> pros-cons/benefits-analysis-supported rationale, except that I expect
>> push-back from SSL/TLS certificate subscribers and from CAs on their
>> behalf. You're right, CAs could take the time between now and July 1st to
>> obtain 398-day validations, but my concern is with the potential push-back.
>>
>> Also, as I mentioned before, I am interested in proposing this as a
>> ballot in the CA/Browser Forum and seeing where it goes. I realize that
>> this issue might come with added baggage from the history surrounding the
>> validity-period changes that were previously defeated in the Forum, but it
>> would still be good to see it adopted there first. Nonetheless, this issue
>> is more than ripe enough to be resolved here by Mozilla as well.
>>
>>
>>
>> >
>> > Doug, could you explain more about why it's undesirable to do that?
>> >
>> >
>> >> >
>> >> > Could you consider changing it to read more like this (feel free to
>> >> > edit as needed):
>> >> >
>> >> > CAs may re-use 

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

As placeholder in the Mozilla Root Store Policy, I'm proposing the
following sentence for section 6.1 - "A CA MUST ensure that it populates
the CCADB with the appropriate 'full CRL' in the CCADB revocation
information field pertaining to certificates issued by the CA
 for each
intermediate CA technically capable of issuing server certificates." (The
hyperlink isn't active yet until we have the CCADB language and
implementation clarified, per Kathleen's recent email and responses
thereto.)Here it is on GitHub -
https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48.
Caveat - other browsers, such as Apple, will likely have more encompassing
implementation requirements for when to populate these "full CRL" fields.

On Mon, Jan 25, 2021 at 10:16 AM Aaron Gable  wrote:

> I think that an explicit carve-out for time-scoped CRLs is a very good
> idea.
>
> In the case that this change to the MRSP is adopted, I suspect that LE
> would scope CRLs by notAfter quite tightly, with perhaps one CRL per 24 or
> even 6 hours of issuance. We would pick a small interval such that we could
> guarantee that each CRL would still be a reasonable size even in the face
> of a mass revocation event.
>
> Producing CRLs at that rate, it would be very valuable to be able to
> gracefully age CRLs out once there is no possibility for a revocation
> status update for any certificate in their scope.
>
> Aaron
>
> On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> All,
>>
>> Another suggestion came in for clarification that hasn't been raised on
>> the
>> list yet, so I'll try and explain the scenario here.
>>
>> Normally, a CA must publish and update its CRLs until the end of the CA
>> certificate's expiration. However, I think that some CAs partition their
>> CRLs based on issuance time, e.g., all certificates issued during January
>> 2021. And all of those certificates would expire after the applicable
>> validity period.  I think CAs don't continue to regenerate or reissue
>> those
>> types of partitioned CRLs which only contain certificates that have
>> expired.  So maybe we need to add an express exception that allows CAs to
>> omit those obsolete CRLs from the JSON file -- as long as the JSON file
>> contains the equivalent of  a "full and complete" CRL.
>>
>> Thoughts?
>>
>> Thanks,
>> Ben
>>
>>
>> On Wed, Jan 13, 2021 at 8:57 AM Rob Stradling  wrote:
>>
>> > Hi Ben.
>> >
>> > > *A CA technically capable of issuing server certificates MUST ensure
>> > that
>> > > the CCADB field "Full CRL Issued By This CA" contains either the URL
>> for
>> > > the full and complete CRL or the URL for the JSON file containing all
>> > URLs
>> > > for CRLs that when combined are the equivalent of the full and
>> complete
>> > CRL*
>> >
>> > As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL
>> > Issued By This CA" and "the URL for the JSON file" as 2 separate fields
>> in
>> > the CCADB.  CAs would then be expected to fill in one field or the
>> other,
>> > but not both.  Is that possible?
>> >
>> > To ensure that these JSON files can be programmatically parsed, I
>> suggest
>> > specifying the requirement a bit more strictly.  Something like this:
>> >   "...or the URL for a file that contains only a JSON Array, whose
>> > elements are URLs of DER encoded CRLs that when combined are the
>> equivalent
>> > of a full and complete CRL"
>> >
>> > > I propose that this new CCADB field be populated in all situations
>> where
>> > the CA is enabled for server certificate issuance.
>> >
>> > Most Root Certificates are "enabled for server certificate issuance".
>> > Obviously CAs shouldn't issue leaf certs directly from roots, but
>> > nonetheless the technical capability does exist.  However, currently CAs
>> > can't edit Root Certificate records in the CCADB, which makes populating
>> > these new field(s) "in all situations" rather hard.
>> >
>> > Since OneCRL covers revocations of intermediate certs, may I suggest
>> that
>> > CAs should only be required to populate these new field(s) in
>> intermediate
>> > certificate records (and not in root certificate records)?
>> >
>> > Relatedly, "A CA technically capable of...that the CCADB field" seems
>> > wrong.  CCADB "CA Owner" records don't/won't contain the new field(s).
>> > Similar language elsewhere in the policy (section 5.3.2) says "All
>> > certificates that are capable of being used to..." (rather than "All
>> > CAs...").
>> >
>> > Technically-constrained intermediate certs don't have to be disclosed to
>> > CCADB, but "in all situations where the CA is enabled for server
>> > certificate issuance" clearly includes technically-constrained
>> > intermediates.  How would a CA populate the "Full CRL Issued By This CA"
>> > field for a technically-constrained intermediate cert that has
>> > (legitimately) not been 

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Obviously this plan may have changed due to other off-list conversations,
> but I would like to express a strong preference for the original plan. At
> the scale at which Let's Encrypt issues, it is likely that our JSON array
> will contain on the order of 1000 CRL URLs, and will add a new one (and age
> out an entirely-expired one) every 6 hours or so. I am not aware of any
> existing automation which updates CCADB at that frequency.
>
> Further, from a resiliency perspective, we would prefer that the CRLs we
> generate live at fully static paths. Rather than overwriting CRLs with new
> versions when they are re-issued prior to their nextUpdate time, we would
> leave the old (soon-to-be-expired) CRL in place, offer its replacement at
> an adjacent path, and update the JSON to point at the replacement. This
> process would have us updating the JSON array on the order of minutes, not
> hours.


This seems like a very inefficient design choice, and runs contrary to how
CRLs are deployed by, well, literally anyone using CRLs as specified, since
the URL is fixed within the issued certificate.

Could you share more about the design of why? Both for the choice to use
sharded CRLs (since that is the essence of the first concern), and the
motivation to use fixed URLs.

We believe that earlier "URL to a JSON array..." approach makes room for
> significantly simpler automation on the behalf of CAs without significant
> loss of auditability. I believe it may be helpful for the CCADB field
> description (or any upcoming portion of the MRSP which references it) to
> include specific requirements around the cache lifetime of the JSON
> document and the CRLs referenced within it.


Indirectly, you’ve highlighted exactly why the approach you propose loses
auditability. Using the URL-based approach puts the onus on the consumer to
try and detect and record changes, introduces greater operational risks
that evade detection (e.g. stale caches on the CAs side for the content of
that URL), and encourages or enables designs that put greater burden on
consumers.

I don’t think this is suggested because of malice, but I do think it makes
it significantly easier for malice to go undetected, for accurate historic
information to be hidden or made too complex to maintain.

This is already a known and, as of recent, studied problem with CRLs [1].
Unquestionably, you are right for highlighting and emphasizing that this
constrains and limits how CAs perform certain operations. You highlight it
as a potential bug, but I’d personally been thinking about it as a
potential feature. To figure out the disconnect, I’m hoping you could
further expand on the “why” of the design factors for your proposed design.

Additionally, it’d be useful to understand how you would suggest CCADB
consumers maintain an accurate, CA attested log of changes. Understanding
such changes is an essential part of root program maintenance, and it does
seem reasonable to expect CAs to need to adjust to provide that, rather
than give up on the goal.

[1]
https://arxiv.org/abs/2102.04288

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

Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Aaron Gable via dev-security-policy]

Hi Kathleen,

It was my impression from earlier discussions
 that
the plan was for the new CCADB field to contain a URL which points to a
document containing only a JSON array of partitioned CRL URLs, rather than
the new CCADB field containing such an array directly.

Obviously this plan may have changed due to other off-list conversations,
but I would like to express a strong preference for the original plan. At
the scale at which Let's Encrypt issues, it is likely that our JSON array
will contain on the order of 1000 CRL URLs, and will add a new one (and age
out an entirely-expired one) every 6 hours or so. I am not aware of any
existing automation which updates CCADB at that frequency.

Further, from a resiliency perspective, we would prefer that the CRLs we
generate live at fully static paths. Rather than overwriting CRLs with new
versions when they are re-issued prior to their nextUpdate time, we would
leave the old (soon-to-be-expired) CRL in place, offer its replacement at
an adjacent path, and update the JSON to point at the replacement. This
process would have us updating the JSON array on the order of minutes, not
hours.

We believe that earlier "URL to a JSON array..." approach makes room for
significantly simpler automation on the behalf of CAs without significant
loss of auditability. I believe it may be helpful for the CCADB field
description (or any upcoming portion of the MRSP which references it) to
include specific requirements around the cache lifetime of the JSON
document and the CRLs referenced within it.

Thanks,
Aaron

On Wed, Feb 24, 2021 at 12:36 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> As previously discussed, there is a section on root and intermediate
> certificate pages in the CCADB called ‘Pertaining to Certificates Issued
> by this CA’, and it currently has one field called 'Full CRL Issued By
> This CA'.
>
> Proposal: Add field called 'JSON Array of Partitioned CRLs Issued By
> This CA'
>
> Description of this proposed field:
> When there is no full CRL for certificates issued by this CA, provide a
> JSON array whose elements are URLs of partitioned, DER-encoded CRLs that
> when combined are the equivalent of a full CRL. The JSON array may omit
> obsolete partitioned CRLs whose scopes only include expired certificates.
>
> Example:
>
> [
>"http://cdn.example/crl-1.crl;,
>"http://cdn.example/crl-2.crl;
> ]
>
>
>
> Additionally, I propose adding a new section to
> https://www.ccadb.org/cas/fields called “Revocation Information”.
>
> The proposed draft for this new section is here:
>
> https://docs.google.com/document/d/1uVK0h4q5BSrFv6e86f2SwR5m2o9Kl1km74vG4HnkABw/edit?usp=sharing
>
>
> I will appreciate your input on this proposal.
>
> Thanks,
> Kathleen
>
>
> ___
> 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

CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Kathleen Wilson via dev-security-policy]

All,

As previously discussed, there is a section on root and intermediate 
certificate pages in the CCADB called ‘Pertaining to Certificates Issued 
by this CA’, and it currently has one field called 'Full CRL Issued By 
This CA'.


Proposal: Add field called 'JSON Array of Partitioned CRLs Issued By 
This CA'


Description of this proposed field:
When there is no full CRL for certificates issued by this CA, provide a 
JSON array whose elements are URLs of partitioned, DER-encoded CRLs that 
when combined are the equivalent of a full CRL. The JSON array may omit 
obsolete partitioned CRLs whose scopes only include expired certificates.


Example:

[
  "http://cdn.example/crl-1.crl;,
  "http://cdn.example/crl-2.crl;
]



Additionally, I propose adding a new section to 
https://www.ccadb.org/cas/fields called “Revocation Information”.


The proposed draft for this new section is here:
https://docs.google.com/document/d/1uVK0h4q5BSrFv6e86f2SwR5m2o9Kl1km74vG4HnkABw/edit?usp=sharing


I will appreciate your input on this proposal.

Thanks,
Kathleen


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

Re: Public Discussion for Inclusion of e-commerce monitoring's GLOBALTRUST 2020 Root

[Ben Wilson via dev-security-policy]

Just a reminder that discussion is ongoing and scheduled to close this
Friday, 26-Feb-2021.

On Thu, Feb 4, 2021 at 4:39 PM Ben Wilson  wrote:

> This is to announce the beginning of the public discussion phase (
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps
> 4 through 9)) of the Mozilla root CA inclusion process for e-commerce
> monitoring GmbH’s GLOBALTRUST 2020 Root CA.
>
> e-commerce monitoring operates as "GlobalTrust", which was previously
> operated by Austrian Society for Data Protection - Arge Daten. According
> to the Applicant, Arge-Daten was the owner of the older "GlobalTrust"
> roots, which are not part of this application. This application has been
> tracked in the CCADB and in Bugzilla -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1627552.
>
> e-commerce monitoring’s GLOBALTRUST 2020 Root is proposed for inclusion
> with the websites trust bit (with EV) and the email trust bit.
>
> Mozilla is considering approving e-commerce monitoring’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).
>
> *A Summary of Information Gathered and Verified appears here in this CCADB
> case:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0568
>
> *Root Certificate Information:*
>
> GLOBALTRUST 2020 Root
>
> crt.sh -
> https://crt.sh/?q=9A296A5182D1D451A2E37F439B74DAAFA267523329F90F9A0D2007C334E23C9A
>
>
> Download - http://service.globaltrust.eu/static/globaltrust-2020.crt
>
>
> *CP/CPS:*
>
> Current CP is Version 2.0h / 15th January 2021
>
> http://service.globaltrust.eu/static/globaltrust-certificate-policy.pdf
>
> Current CPS is Version 2.0h / 15th January 2021
>
>
> http://service.globaltrust.eu/static/globaltrust-certificate-practice-statement.pdf
>
> Repository location:   https://globaltrust.eu/certificate-policy/
>
> *BR Self-Assessment* (PDF) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9138392
>
>
> *Audits:*
>
> 2020 audits are attached to Bug # 1627552
>  and include the
> Key Generation Report, the EV Readiness Audit, and the ETSI Audit
> Attestation, which covered the period from 06/11/2019 until 04/01/2020. The
> next audit is due 04/01/2021.
>
> No misissuances were found under this root, and all subordinate
> certificates passed technical tests satisfactorily.
>
> Again, this email begins a three-week public discussion period, which I’m
> scheduling to close on or about 26-February-2021.
>
> Sincerely yours,
>
> Ben Wilson
>
> Mozilla Root Program
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

All,

I have edited the proposed resolution of Issue #192

as follows:

Subsection 3 of MRSP Section 3.1.4. would read:

"The publicly-available documentation relating to each audit MUST contain
at
least the following clearly-labelled information: ...

3. name of the lead auditor and qualifications of the team performing the
audit, as required by section 3.2;
..."

Section 3.2 would read:

"A Qualified Auditor MUST have relevant IT Security experience, or have
audited a number of CAs, and be independent and not conflicted. People have
competence, partnerships and corporations do not. Each Audit Report MUST be
accompanied by documentation provided to Mozilla of the audit team
qualifications

sufficient for Mozilla to determine the competence, experience, and
independence of the Qualified Auditor."

The wiki page linked above will provide further details on how to submit
documentation of the audit team's qualifications (which may be separate
from the audit letter itself).

Ben





On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:
> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:
> > > Apologies for belaboring the point, but I think we might be talking
> past
> > > eachother.
> > >
> > > You originally stated “The only place I am aware that lists the audit
> > > partner in a comparable world is the signing audit partner on public
> > > company audits in the US, which is available on the SEC website.” I
> gave
> > > two separate examples of such, and you responded to one (FPKI) by
> saying
> > > the report was not public (even when it is made available publicly),
> and
> > > the other I didn’t see a response to.
> > >
> > > This might feel like nit-picking, but I think this is a rather serious
> > > point to work through, because I don’t think you’re fully
> communicating
> > > what you judge to be a “comparable world”, as it appears you are
> dismissing
> > > these examples.
> > >
> > > I can think of several possible dimensions you might be thinking are
> > > relevant, but rather than assume, I’m hoping you can expand with a few
> > > simple questions. Some admittedly seem basic, but I don’t want to take
> > > anything for granted here.
> > >
> > > 1) Are you/the WTTF familiar with these audit schemes?
> > >
> > > 2) Are you aware of schemes that require disclosing the relevant
> skills and
> > > experience of the audit team to the client? (E.g. as done by BSI C5
> audits
> > > under ISAE 3000)
> > >
> > > 3) Are you aware of such reports naming multiple parties for the use
> of the
> > > report (e.g. as done by FPKI audits)
> > >
> > > 4) Are you aware of schemes in which a supplier requires a vendor to
> be
> > > audited, and ensures that the customer of supplier are able to access
> such
> > > audits as part of their reliance upon supplier? (Note, this doesn’t
> have to
> > > be limited to ISMS systems)
> > >
> > > I’m trying to understand what, given the prevalence of these
> practices,
> > > makes these instances *not* a comparable world, since it seems that
> helps
> > > move closer to solutions.
> > Ryan, I hope you are not suggesting I am dodging you points. That would
> be absurd. Let me use different words as comparable world seems to be
> tripping you up. You are not providing a general/public distribution
> example to make your point so it is baseless. You are using a restricted
> opinion from EY and neither Ryan Sleevi nor Google are listed as the two
> intended users. The closest I have seen to support your desire to name
> individual auditors is in public company audit reports, which are housed on
> the SEC website. To be clear, of your two examples, one is an opinion,
> which is restricted, and the other represents the guidelines. Perhaps you
> have seen a public/general distribution report from your second opinion as
> I do not see it in this thread. I am aware, as mentioned previously, of the
> Federal PKI program desiring to know more about team members, but that is
> not listed in a non-restricted report, in a public/general distribution
> format.
>
> I can click on the URL and read it.  This seems to be the very definition
> of public, even if the audit report says it is not for reliance upon by the
> general public. I fully appreciate that this may be a technicality in the
> world of auditing, but it is very confusing to those of us who are less
> familiar.
>
> > Jeff
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Re: Questions About DigiCert .onion Certificate SubjectPublicKey Hash

[Ryan Sleevi via dev-security-policy]

This is already tracked as https://github.com/cabforum/servercert/issues/190
and is waiting the completion of SC41v2 in the CA/Browser Forum Server
Certificate Working Group before working on (along with a cluster of
related .onion fixes)

On Thu, Feb 18, 2021 at 12:05 PM SXIA via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
>
> As required by CABForum guidelines, CAs must include the hash of an ASN.1
> SubjectPublicKey of the .onion service. For example,
> https://crt.sh/?id=3526088262 shows the SHA256 of the public key of
> archivev3qli37bju4rlh27glh24lljyezwxf4pokmrdbpefjlcrp5id.onion is
> 08afa9604f4cd74a1a867f3ffcf61faacdb19785a9d4c378f72a54503f73dd65
>
> Since this a v3 address, it is not difficult to extract the public key
> from .onion domain. Below is the hexdump of hs_ed25519_public_key
>
> 3d 3d 20 65 64 32 35 35  31 39 76 31 2d 70 75 62
> 6c 69 63 3a 20 74 79 70  65 30 20 3d 3d 00 00 00
> 04 44 74 54 95 dc 16 8d  fc 29 a7 22 b3 eb e6 59
> f5 c5 ad 38 26 6d 72 f1  ee 53 22 30 bc 85 4a c5
>
> So the public key (32 bytes long) is just the last two lines of the
> hexdump, and we can generate the public_key.pem from it, which is
>
> -BEGIN PUBLIC KEY-
> MCowBQYDK2VwAyEABER0VJXcFo38Kacis+vmWfXFrTgmbXLx7lMiMLyFSsU=
> -END PUBLIC KEY-
>
> We can also convert it to DER ($ openssl pkey -pubin -outform DER -out
> public_key.der), and here comes the problem: I tried to hash the DER file,
> and I got 141dcca6fea50f1c9f12c7150ca157a8e6e7bf7e79a6eb6f592a6235ab57ce23,
> which is different from what I see in DigiCert's certificate. Any ideas why
> this happened?
>
> Also, since the support of v2 .onion address will be removed from the Tor
> code base on July 15th, 2021 and v3 .onion address contains the full public
> key, I think it is meaningless to have 2.23.140.1.31 extension after that.
>
> Best,
> Xia
> ___
> 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

Questions About DigiCert .onion Certificate SubjectPublicKey Hash

[SXIA via dev-security-policy]

Hello,

As required by CABForum guidelines, CAs must include the hash of an ASN.1 
SubjectPublicKey of the .onion service. For example, 
https://crt.sh/?id=3526088262 shows the SHA256 of the public key of 
archivev3qli37bju4rlh27glh24lljyezwxf4pokmrdbpefjlcrp5id.onion is 
08afa9604f4cd74a1a867f3ffcf61faacdb19785a9d4c378f72a54503f73dd65

Since this a v3 address, it is not difficult to extract the public key from 
.onion domain. Below is the hexdump of hs_ed25519_public_key

3d 3d 20 65 64 32 35 35  31 39 76 31 2d 70 75 62
6c 69 63 3a 20 74 79 70  65 30 20 3d 3d 00 00 00
04 44 74 54 95 dc 16 8d  fc 29 a7 22 b3 eb e6 59
f5 c5 ad 38 26 6d 72 f1  ee 53 22 30 bc 85 4a c5

So the public key (32 bytes long) is just the last two lines of the hexdump, 
and we can generate the public_key.pem from it, which is

-BEGIN PUBLIC KEY-
MCowBQYDK2VwAyEABER0VJXcFo38Kacis+vmWfXFrTgmbXLx7lMiMLyFSsU=
-END PUBLIC KEY-

We can also convert it to DER ($ openssl pkey -pubin -outform DER -out 
public_key.der), and here comes the problem: I tried to hash the DER file, and 
I got 141dcca6fea50f1c9f12c7150ca157a8e6e7bf7e79a6eb6f592a6235ab57ce23, which 
is different from what I see in DigiCert's certificate. Any ideas why this 
happened?

Also, since the support of v2 .onion address will be removed from the Tor code 
base on July 15th, 2021 and v3 .onion address contains the full public key, I 
think it is meaningless to have 2.23.140.1.31 extension after that.

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of February 2021 Audit Reminder Emails
Date: Tue, 16 Feb 2021 20:01:02 + (GMT)


Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3
   Hongkong Post Root CA 1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239021

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239022

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239023

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   FNMT-RCM - SHA256
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

Standard Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238799

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238801

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189

Standard Audit Period End Date: 2020-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189
BR Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden EV Root CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238851

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238852

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238853

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Amazon Trust Services
Root Certificates:
   Amazon Root CA 3
   Amazon Root CA 2
   Amazon Root CA 1
   Amazon Root CA 4
   Starfield Services Root Certificate Authority - G2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239088

Standard Audit Period End Date: 2020-01-15
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239089

BR Audit Period End Date: 2020-01-15
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239090

EV Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA**
   Buypass Class 3 Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Watson Ladd via dev-security-policy]

On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote:
> On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote: 
> > Apologies for belaboring the point, but I think we might be talking past 
> > eachother. 
> > 
> > You originally stated “The only place I am aware that lists the audit 
> > partner in a comparable world is the signing audit partner on public 
> > company audits in the US, which is available on the SEC website.” I gave 
> > two separate examples of such, and you responded to one (FPKI) by saying 
> > the report was not public (even when it is made available publicly), and 
> > the other I didn’t see a response to. 
> > 
> > This might feel like nit-picking, but I think this is a rather serious 
> > point to work through, because I don’t think you’re fully communicating 
> > what you judge to be a “comparable world”, as it appears you are dismissing 
> > these examples. 
> > 
> > I can think of several possible dimensions you might be thinking are 
> > relevant, but rather than assume, I’m hoping you can expand with a few 
> > simple questions. Some admittedly seem basic, but I don’t want to take 
> > anything for granted here. 
> > 
> > 1) Are you/the WTTF familiar with these audit schemes? 
> > 
> > 2) Are you aware of schemes that require disclosing the relevant skills and 
> > experience of the audit team to the client? (E.g. as done by BSI C5 audits 
> > under ISAE 3000) 
> > 
> > 3) Are you aware of such reports naming multiple parties for the use of the 
> > report (e.g. as done by FPKI audits) 
> > 
> > 4) Are you aware of schemes in which a supplier requires a vendor to be 
> > audited, and ensures that the customer of supplier are able to access such 
> > audits as part of their reliance upon supplier? (Note, this doesn’t have to 
> > be limited to ISMS systems) 
> > 
> > I’m trying to understand what, given the prevalence of these practices, 
> > makes these instances *not* a comparable world, since it seems that helps 
> > move closer to solutions.
> Ryan, I hope you are not suggesting I am dodging you points. That would be 
> absurd. Let me use different words as comparable world seems to be tripping 
> you up. You are not providing a general/public distribution example to make 
> your point so it is baseless. You are using a restricted opinion from EY and 
> neither Ryan Sleevi nor Google are listed as the two intended users. The 
> closest I have seen to support your desire to name individual auditors is in 
> public company audit reports, which are housed on the SEC website. To be 
> clear, of your two examples, one is an opinion, which is restricted, and the 
> other represents the guidelines. Perhaps you have seen a public/general 
> distribution report from your second opinion as I do not see it in this 
> thread. I am aware, as mentioned previously, of the Federal PKI program 
> desiring to know more about team members, but that is not listed in a 
> non-restricted report, in a public/general distribution format. 

I can click on the URL and read it.  This seems to be the very definition of 
public, even if the audit report says it is not for reliance upon by the 
general public. I fully appreciate that this may be a technicality in the world 
of auditing, but it is very confusing to those of us who are less familiar.

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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 15, 2021 at 6:07 PM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan, I hope you are not suggesting I am dodging you points.  That would
> be absurd.  Let me use different words as comparable world seems to be
> tripping you up.


I'm not trying to suggest you're dodging intentionally, but as I said, I
think we were, and to a degree still are, talking past each other. I think
your reply captured that you don't think I understood your phrasing,
which I didn't, but I also don't think you understood why I was trying to
unpack that phrase more.


> You are not providing a general/public distribution example to make your
> point so it is baseless.  You are using a restricted opinion from EY and
> neither Ryan Sleevi nor Google are listed as the two intended users.


I'm not sure why you're bringing in Google with respect to
https://wiki.mozilla.org/CA/Policy_Participants . I'm also not sure how
this relates to the specific questions I asked, which were an attempt to
reset the conversation here to try and make progress on finding solutions.


> The closest I have seen to support your desire to name individual auditors
> is in public company audit reports, which are housed on the SEC website.
> To be clear, of your two examples, one is an opinion, which is restricted,
> and the other represents the guidelines.  Perhaps you have seen a
> public/general distribution report from your second opinion as I do not see
> it in this thread.  I am aware, as mentioned previously, of the Federal PKI
> program desiring to know more about team members, but that is not listed in
> a non-restricted report, in a public/general distribution format.


Sure, and the purpose of the questions was an attempt to reset the
conversation to a point where we're not talking past each other, by trying
to build up from basics. I know we both know there are many different audit
criteria that are used, and the WTTF member organizations are global
organizations. I don't want to assume that those who focus on the WTTF are
as familiar with, say, the BSI requirements or other audit criteria, much
the same way it wouldn't be reasonable to expect I know as much about AI as
PKI :)

The example report I provided wasn't about calling out an individual
member, but rather to highlight an area that, objectively, seems
comparable, particularly to Ben's proposed language, to better understand
what you meant by that, and whether you had concerns with the new approach
still.

You've anchored here on the public disclosure part, which I can understand
and appreciate the risk perceived by having auditor names attached to the
reports, instead of just firms. I see most of your answers focus on a
specific form of disclosure, but that wasn't what my previous mail was
trying to get to yet. I was trying to work back to understand where
"comparable" criteria diverge, so we can figure out possible paths.

To be clear, I support Ben's proposal as a very useful and meaningful
interim step. Your original message was a bit ambiguous about where you
stand, in large part because your use of "comparable" left quite a bit
ambiguous, and whether you thought the changes were sufficient. I'm quite
glad to hear that it sounds workable for those performing WebTrust audits,
because that helps make forward progress.

However, I still think it'd be useful to view this as an interim step, and
it certainly feels like you might be saying this as far as things can go.
In the cloud services space, we regularly see end users expecting audits of
their cloud provider, and those transitively apply to dependencies of that
cloud provider (e.g. datacenter security, software vendors used by the
cloud provider, etc). This is similarly true with respect to software
supply chain security: working out not just first order dependencies, but
working through second and third-order dependencies as well, to build up a
holistic risk picture. Browsers rely on and delegate to CAs, so it's no
surprise that browsers expect audits for CAs. Yet browsers have their own
customers, and need to provide those customers the assurances they need,
and their customers need, etc.

My Question #5 was an attempt to unpack "comparable" further, because these
are hardly unique problems to software vendor/service provider
relationships. It's not even unique to "cloud" or "PKI", as supply chain
assurances are pretty universal, as shown by goods such as coconut milk,
coffee, chocolate, or diamonds. You answered in the context of "public
report", but I wasn't trying to go there yet. I was trying to figure out
where "comparable" split off, and what schemes were and weren't
comparable, so that we can continue to make improvements.  Now that it
seems we have a path forward for direct disclosure, I think it's reasonable
to spend time thinking about how to bring that assurance to browser's
users/customers, such as this community, in the same way we help bring
transparency to cloud 

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Jeff Ward via dev-security-policy]

On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote:
> Apologies for belaboring the point, but I think we might be talking past 
> eachother. 
> 
> You originally stated “The only place I am aware that lists the audit
> partner in a comparable world is the signing audit partner on public
> company audits in the US, which is available on the SEC website.” I gave 
> two separate examples of such, and you responded to one (FPKI) by saying 
> the report was not public (even when it is made available publicly), and 
> the other I didn’t see a response to. 
> 
> This might feel like nit-picking, but I think this is a rather serious 
> point to work through, because I don’t think you’re fully communicating 
> what you judge to be a “comparable world”, as it appears you are dismissing 
> these examples. 
> 
> I can think of several possible dimensions you might be thinking are 
> relevant, but rather than assume, I’m hoping you can expand with a few 
> simple questions. Some admittedly seem basic, but I don’t want to take 
> anything for granted here. 
> 
> 1) Are you/the WTTF familiar with these audit schemes? 
> 
> 2) Are you aware of schemes that require disclosing the relevant skills and 
> experience of the audit team to the client? (E.g. as done by BSI C5 audits 
> under ISAE 3000) 
> 
> 3) Are you aware of such reports naming multiple parties for the use of the 
> report (e.g. as done by FPKI audits) 
> 
> 4) Are you aware of schemes in which a supplier requires a vendor to be 
> audited, and ensures that the customer of supplier are able to access such 
> audits as part of their reliance upon supplier? (Note, this doesn’t have to 
> be limited to ISMS systems) 
> 
> I’m trying to understand what, given the prevalence of these practices, 
> makes these instances *not* a comparable world, since it seems that helps 
> move closer to solutions.


Ryan, I hope you are not suggesting I am dodging you points.  That would be 
absurd.  Let me use different words as comparable world seems to be tripping 
you up.  You are not providing a general/public distribution example to make 
your point so it is baseless.  You are using a restricted opinion from EY and 
neither Ryan Sleevi nor Google are listed as the two intended users.  The 
closest I have seen to support your desire to name individual auditors is in 
public company audit reports, which are housed on the SEC website.  To be 
clear, of your two examples, one is an opinion, which is restricted, and the 
other represents the guidelines.  Perhaps you have seen a public/general 
distribution report from your second opinion as I do not see it in this thread. 
 I am aware, as mentioned previously, of the Federal PKI program desiring to 
know more about team members, but that is not listed in a non-restricted 
report, in a public/general distribution format.  

EY did the FPKI audit.  I am not sure why you keep tagging the as a WTTF 
member.  They are a global firm so if you are implying only they know the 
standards/rules (which I hope you are not) would be misleading.  But to answer 
you question #1, yes.  We even spoke last about this in our TF meeting last 
week and every member had the same response, including the one you have 
referenced.  #2 answered previously.  We are not arguing who wants what.  The 
fact this information is desired is not being debated, rather how it is 
reported to the user.  #3 question is unclear.  I am not aware of any report 
that restricts an opinion to certain users specifically, in the case you 
mentioned the CA and FPKI that allows additional users to get this information. 
 SOC2 for example has a broader restriction which allows the reports to go to a 
class or classes of users.  Your example is not that case.#4 I am 
definitely aware of this requirement.  A public/general distribution report can 
be shared with anyone.  The restriction dictates who gets the opinion.  This is 
the main point you are not understanding Ryan.  For example, I if perform an 
audit of a company and restrict it to them and one other user, say their bank, 
the engagement letter / statement of work would clearly reflect this 
restriction.  In addition, the standard terms would require the company to get 
permission to issue the report beyond the specified users.  The example you 
raise in this question is certainly covered under the broad type of restriction 
that SOC2 provides, as they would be knowledgeable about the subject matter.  
The EY report example you provided does not include the broader use.  And not 
to belabor this point, but the restriction precludes its public/general 
distribution.  The words matter.  When the distribution of a report is tightly 
binding two parties, as in your example, you can't distribute it broader.  
Restricted reports by definition are different.

This is a long dialogue supporting Ben's approach.  Firms will most likely be 
willing to provide the qualifications of auditors in a non-public 

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

Apologies for belaboring the point, but I think we might be talking past
eachother.

You originally stated “The only place I am aware that lists the audit
partner in a comparable world is the signing audit partner on public
company audits in the US, which is available on the SEC website.” I gave
two separate examples of such, and you responded to one (FPKI) by saying
the report was not public (even when it is made available publicly), and
the other I didn’t see a response to.

This might feel like nit-picking, but I think this is a rather serious
point to work through, because I don’t think you’re fully communicating
what you judge to be a “comparable world”, as it appears you are dismissing
these examples.

I can think of several possible dimensions you might be thinking are
relevant, but rather than assume, I’m hoping you can expand with a few
simple questions. Some admittedly seem basic, but I don’t want to take
anything for granted here.

1) Are you/the WTTF familiar with these audit schemes?

2) Are you aware of schemes that require disclosing the relevant skills and
experience of the audit team to the client? (E.g. as done by BSI C5 audits
under ISAE 3000)

3) Are you aware of such reports naming multiple parties for the use of the
report (e.g. as done by FPKI audits)

4) Are you aware of schemes in which a supplier requires a vendor to be
audited, and ensures that the customer of supplier are able to access such
audits as part of their reliance upon supplier? (Note, this doesn’t have to
be limited to ISMS systems)

I’m trying to understand what, given the prevalence of these practices,
makes these instances *not* a comparable world, since it seems that helps
move closer to solutions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Jeff Ward via dev-security-policy]

On Monday, February 15, 2021 at 1:57:11 PM UTC-6, Ryan Sleevi wrote:
> On Mon, Feb 15, 2021 at 2:03 PM Jeff Ward via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > I wanted to clarify a couple of points. Firms must be independent to do 
> > audit/assurance work. If independence is impaired, for example, by one 
> > person in the firm performing management functions, the entire firm is no 
> > longer independent. Firms have the responsibility to monitor activities of 
> > its professionals, which also includes personal investments, to ensure they 
> > remain independent. 
> > 
> > Also, WebTrust practitioners provide information on the firm and the 
> > professionals used on these engagements. The information provided is 
> > closely aligned with the Auditor Qualifications you are describing. As you 
> > know, CPA Canada provides a listing of qualified audit firms on its 
> > website. Working closely with them could also help in instances where 
> > auditor qualifications are in question. 
> > 
> > And one last item, thank you for hearing us on the listing of auditors 
> > performing the engagement. The only place I am aware that lists the audit 
> > partner in a comparable world is the signing audit partner on public 
> > company audits in the US, which is available on the SEC website. Other 
> > than that, I am not aware of any other team member being listed. We have 
> > seen listings of team members and related experience summarized on a 
> > non-publicly issued letter to management in the US Federal space.
> Jeff, 
> 
> https://www.oversight.gov/sites/default/files/oig-reports/18-19.pdf 
> 
> Is an example, which is an audit of the U.S. Government Printing Office, 
> provided by a WTTF member, against the US Federal PKI CP. This doesn’t meet 
> the criteria you mentioned (public company, SEC), and itself was provided 
> several years ago. 
> 
> It is directed to a set of named parties, and made publicly available by 
> those parties, using the WebTrust for CAs criteria. On page 4 (report)/6 
> (FPKI submission)/9 (PDF page), you can see an enumerated list of audit 
> participants and their applicable skills, summarized. 
> 
> Since you mentioned “a comparable world”, the BSI C5 controls, which 
> provide a valuable model for improvements in transparency and thoroughness 
> of reporting (aka the so called “detailed controls” report), notes this 
> within Section 3.5.1 of the Controls [1] 
> 
> “As part of the reporting, it must be specified which of the professional 
> examinations/certifications are held by the audit team (e. g. in the 
> section “Independence and quality assurance of the auditor”). Upon request, 
> appropriate documents (e. g. certificates etc.) must be submitted to the 
> client.” 
> 
> Could you clarify whether you and the WTTF considered these two cases? The 
> former is an example of using an assurance scheme the FPKIMA has said on 
> its own is insufficient, namely WTCA, but with additional reporting can be 
> made sufficient. The latter is an example of a scheme specifically adapted 
> for cloud/vendor security controls against an ISAE 3000 reporting scheme, 
> which is nearly identical to WTBRs in that regard. It was unclear if y’all 
> were simply not familiar with these cases, or if you believe there is 
> substantive differences in the proposal here that may require addressing. 
> 
> [1] 
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/ComplianceControlsCatalogue-Cloud_Computing-C5.pdf?__blob=publicationFile=3
>  
> 
> >
Correct Ryan.  This is one of the examples you provided previously.  This 
report is of course restricted:
"This report is intended solely for the information and use of {CA} and the 
Federal PKI Policy Authority and is not intended to be, and should not be, used 
by anyone other than {CA} and Federal PKI Policy Authority."

As you know, this report then is not generally / publicly distributed as it is 
a restricted use report.  This restriction does not appear in the public 
company audit opinions, hence the reference.  I called out the federal space 
with this very example in mind.  So yes, I am aware of and quite familiar with 
this scenario.  It is more about the restricted use (or in this case the lack 
thereof) as it is the framework being used.  The very point you are referencing 
an opinion that you are using outside of the restriction sums up my argument.  
I can't speak for all audit firms as this is more of a risk management issue, 
but my firm would be fine issuing this report in a restricted manner, unless it 
became known it would not actually be used in the restricted manner.  That 
defeats the whole purpose.  I've issued auditor qualifications in this manner 
in a management letter, which is also restricted.  To my knowledge, that letter 
has never been made available to those outside of the restricted use, as it 
appears to have been in this case.  So unfortunately your statement is 

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ryan Sleevi via dev-security-policy]

On Mon, Feb 15, 2021 at 2:03 PM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I wanted to clarify a couple of points.  Firms must be independent to do
> audit/assurance work.  If independence is impaired, for example, by one
> person in the firm performing management functions, the entire firm is no
> longer independent.  Firms have the responsibility to monitor activities of
> its professionals, which also includes personal investments, to ensure they
> remain independent.
>
> Also, WebTrust practitioners provide information on the firm and the
> professionals used on these engagements.  The information provided is
> closely aligned with the Auditor Qualifications you are describing.  As you
> know, CPA Canada provides a listing of qualified audit firms on its
> website.  Working closely with them could also help in instances where
> auditor qualifications are in question.
>
> And one last item, thank you for hearing us on the listing of auditors
> performing the engagement.  The only place I am aware that lists the audit
> partner in a comparable world is the signing audit partner on public
> company audits in the US, which is available on the SEC website.  Other
> than that, I am not aware of any other team member being listed.  We have
> seen listings of team members and related experience summarized on a
> non-publicly issued letter to management in the US Federal space.


Jeff,

https://www.oversight.gov/sites/default/files/oig-reports/18-19.pdf

Is an example, which is an audit of the U.S. Government Printing Office,
provided by a WTTF member, against the US Federal PKI CP. This doesn’t meet
the criteria you mentioned (public company, SEC), and itself was provided
several years ago.

It is directed to a set of named parties, and made publicly available by
those parties, using the WebTrust for CAs criteria. On page 4 (report)/6
(FPKI submission)/9 (PDF page), you can see an enumerated list of audit
participants and their applicable skills, summarized.

Since you mentioned “a comparable world”, the BSI C5 controls, which
provide a valuable model for improvements in transparency and thoroughness
of reporting (aka the so called “detailed controls” report), notes this
within Section 3.5.1 of the Controls [1]

“As part of the reporting, it must be specified which of the professional
examinations/certifications are held by the audit team (e. g. in the
section “Independence and quality assurance of the auditor”). Upon request,
appropriate documents (e. g. certificates etc.) must be submitted to the
client.”

Could you clarify whether you and the WTTF considered these two cases? The
former is an example of using an assurance scheme the FPKIMA has said on
its own is insufficient, namely WTCA, but with additional reporting can be
made sufficient. The latter is an example of a scheme specifically adapted
for cloud/vendor security controls against an ISAE 3000 reporting scheme,
which is nearly identical to WTBRs in that regard. It was unclear if y’all
were simply not familiar with these cases, or if you believe there is
substantive differences in the proposal here that may require addressing.

[1]
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/ComplianceControlsCatalogue-Cloud_Computing-C5.pdf?__blob=publicationFile=3

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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Jeff Ward via dev-security-policy]

On Thursday, February 11, 2021 at 12:41:44 PM UTC-6, Ben Wilson wrote:
> All, 
> 
> I've modified the proposed change to MRSP section 3.2 so that it would now 
> insert a middle paragraph that would read: 
> 
> "A Qualified Auditor MUST have relevant IT Security experience, or have 
> audited a number of CAs, and be independent and not conflicted. Individuals 
> have competence, partnerships and corporations do not. Each Audit Report 
> MUST be accompanied by documentation provided to Mozilla of individual 
> auditor qualifications sufficient for Mozilla to determine the competence, 
> experience, and independence of the Qualified Auditor." 
> 
> See 
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/57063dc07f5b753184c94dbf5d0d30d0b9b90789
>  
> 
> The basis for further interpretation of the above language would still be 
> section 8.2 of the Baseline Requirements. ("In normal circumstances, 
> Mozilla requires that audits MUST be performed by a Qualified Auditor, as 
> defined in the Baseline Requirements section 8.2"). 
> 
> Section 3.1.4 still remains with a proposed subsection 3 - "name(s) and 
> qualifications of individuals performing the audit, as required by section 
> 3.2." 
> 
> I anticipate that additional guidance for how CAs should submit this 
> information will be made available here on the wiki - 
> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications. 
> 
> 
>  
> Ben
> On Thu, Jan 28, 2021 at 2:10 PM Ryan Sleevi  wrote: 
> 
> > 
> > On Thu, Jan 28, 2021 at 3:05 PM Ben Wilson  wrote: 
> > 
> >> Thanks. My current thinking is that we can leave the MRSP "as is" and 
> >> that we write up what we want in 
> >> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications, 
> >> which is, as you note, information about members of the audit team and how 
> >> individual members meet #2, #3, and #6. 
> >> 
> > 
> > Is this intended as a temporary fix until the issue is meaningfully 
> > addressed? Or are you seeing this as a long-term resolution of the issue? 
> > 
> > I thought the goal was to make the policy clearer on the expectations, and 
> > my worry is that it would be creating more work for you and Kathleen, and 
> > the broader community, because it puts the onus on you to chase down CAs to 
> > provide the demonstration because they didn't pay attention to it in the 
> > policy. This was the complaint previously raised about "CA Problematic 
> > Practices" and things that are forbidden, so I'm not sure I understand the 
> > distinction/benefit here from moving it out? 
> > 
> > I think the relevance to MRSP is trying to clarify whether Mozilla thinks 
> > of auditors as individuals (as it originally did), or whether it thinks of 
> > auditors as organizations. I think that if MRSP was clarified regarding 
> > that, then the path you're proposing may work (at the risk of creating more 
> > work for y'all to request that CAs provide the information that they're 
> > required to provide, but didn't know that). 
> > 
> > If the issue you're trying to solve is one about whether it's in the audit 
> > letter vs communicated to Mozilla, then I think it should be possible to 
> > achieve that within the MRSP and explicitly say that (i.e. not require it 
> > in the audit letter, but still requiring it). 
> > 
> > Just trying to make sure I'm not overlooking or misunderstanding your 
> > concerns there :) 
> > 
> >>
I wanted to clarify a couple of points.  Firms must be independent to do 
audit/assurance work.  If independence is impaired, for example, by one person 
in the firm performing management functions, the entire firm is no longer 
independent.  Firms have the responsibility to monitor activities of its 
professionals, which also includes personal investments, to ensure they remain 
independent.

Also, WebTrust practitioners provide information on the firm and the 
professionals used on these engagements.  The information provided is closely 
aligned with the Auditor Qualifications you are describing.  As you know, CPA 
Canada provides a listing of qualified audit firms on its website.  Working 
closely with them could also help in instances where auditor qualifications are 
in question.

And one last item, thank you for hearing us on the listing of auditors 
performing the engagement.  The only place I am aware that lists the audit 
partner in a comparable world is the signing audit partner on public company 
audits in the US, which is available on the SEC website.  Other than that, I am 
not aware of any other team member being listed.  We have seen listings of team 
members and related experience summarized on a non-publicly issued letter to 
management in the US Federal space.

Hope this helps!

Jeff
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Ben Wilson via dev-security-policy]

The current proposed draft of changes is at
https://github.com/BenWilson-Mozilla/pkipolicy/commit/443b4c5d5155942a216322480f3a6a273ea2

Right now, I'm considering having subsection of MRSP section 3.1.4 say,
"the CA locations that were or were not audited" - with a hyperlink to
https://wiki.mozilla.org/CA/Audit_Statements#Audited_Locations, and then
elaborating there as needed.


On Wed, Jan 13, 2021 at 10:25 AM Ben Wilson  wrote:

> Thanks, Jeff.  These are useful comments, and I will take them into
> consideration in revising our proposal.
>
> On Tue, Jan 12, 2021 at 8:38 AM Jeff Ward via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Sunday, January 3, 2021 at 8:38:05 AM UTC-6, Jeff Ward wrote:
>> > On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote:
>> > > All,
>> > >
>> > > This email is part of the discussion for the next version of the
>> Mozilla
>> > > Root Store Policy (MSRP), version 2.7.1, to be published during of
>> Q1-2021.
>> > >
>> > > For audit delays, we currently require that audit statements disclose
>> the
>> > > locations that were and were not audited, but that requirement has
>> not been
>> > > incorporated yet into the MRSP. See
>> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations.
>> That
>> > > provision reads as follows:
>> > >
>> > > Disclose each location (at the state/province level) that was
>> included in
>> > > the scope of the audit or should have been included in the scope of
>> the
>> > > audit, whether the inspection was physically carried out in person at
>> each
>> > > location, and which audit criteria were checked (or not checked) at
>> each
>> > > location.
>> > >
>> > > - If the CA has more than one location in the same state/province,
>> then
>> > > use terminology to clarify the number of facilities in that
>> state/province
>> > > and whether or not all of them were audited. For example: "Facility 1
>> in
>> > > Province", "Facility 2 in Province, Facility 3 in Province" *or*
>> > > "Primary Facility in Province", "Secondary Facility in Province",
>> "Tertiary
>> > > Facility in Province".
>> > > - The public audit statement does not need to identify the type of
>> > > Facility.
>> > > - "Facility" includes: data center locations, registration authority
>> > > locations, where IT and business process controls of CA operations
>> are
>> > > performed, facility hosting an active HSM with CA private keys,
>> > > facility or
>> > > bank deposit box storing a deactivated and encrypted copy of a
>> > > private key.
>> > >
>> > > It is proposed by Issue #207
>> > >  that this language
>> > > requiring the disclosure of site locations--audited and unaudited--be
>> made
>> > > clearly part of the MSRP by reference to the language above.
>> > >
>> > > A similar method of incorporating by reference has been taken in
>> section
>> > > 2.4 of the MSRP
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents>
>>
>> > > with respect to incident reporting and in section 7.1
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions>
>>
>> > > with requirements for the CA inclusion process.
>> > >
>> > > It is proposed that we add a new subsection 10 to MRSP section 3.1.4
>> > > <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information>
>>
>> > > that would require that audit documentation disclose the facility
>> site
>> > > locations that were, or were not, examined.
>> > >
>> > > One concern that has been raised previously is that the Baseline
>> > > Requirements do not define "facility site location". However, we
>> believe
>> > > that the language above at
>> > > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations
>> > > accomplishes that. We're open to suggestions for re-wording parts of
>> it to
>> > > make it even better.
>> > >
>> > > Currently, the audit letter template for WebTrust for CAs references
>> the
>> > > site location audited (at the level of specificity that is proposed
>> > > above). Over this past year, due to COVID, some ETSI attestation
>> letters
>> > > have also explained which sites were and were not checked. This
>> approach
>> > > seems to work, and the additional information will be beneficial in
>> the
>> > > future as we evaluate the security and trust of PKI service
>> providers.
>> > >
>> > > So, for the page cited above, we intend to move "Minimum
>> Expectations" out
>> > > from under "Audit Delay" so that it stands separately as a
>> requirement for
>> > > disclosing the facility site location. Then we will also revise MRSP
>> > > section 3.1.4 by inserting a new subsection 10 to require "facility
>> site
>> > > locations that were, or were not, examined" with a hyperlink to the
>> Minimum
>> > > Expectations language cited above.
>> > >
>> > 

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Jeff Ward via dev-security-policy]

On Friday, February 12, 2021 at 10:27:11 AM UTC-6, Ben Wilson wrote:
> I'm fine with that suggestion.
> On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote:
> > > 11. all incidents (as defined in section 2.4), including those reported 
> > in 
> > > Bugzilla, that were: 
> > > * disclosed by the CA or discovered by the auditor, and 
> > > * unresolved at any time during the audit period; 
> > >
> > > The idea is that all "incidents" must be reported if they were 
> > "unresolved" 
> > > - which would include those that occurred or were open - at any time 
> > during 
> > > the audit period. 
> > > 
> >
> > Wouldn't it be clearer to non-native English speakers to avoid the nuance 
> > associated with "unresolved at any time" needing to imply both those that 
> > occurred or those that were still open? 
> > 
> > Why not amend the language to just say: 
> >
> > 11. all incidents (as defined in section 2.4), including those reported in
> > Bugzilla, that: 
> > * were disclosed by the CA or discovered by the auditor, and 
> > * occurred or were open at any time during the audit period;
> > ___ 
> > dev-security-policy mailing list 
> > dev-secur...@lists.mozilla.org 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> >
This wording works from a WebTrust perspective as well.  Thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Nick Lamb via dev-security-policy]

On Thu, 11 Feb 2021 15:12:46 -0500
Ryan Sleevi via dev-security-policy
 wrote:

> So I'd say feel free to ask your question there, which helps make
> sure it's answered before the issue is closed.

Good point. In this case Arvid has clarified that in fact the ticket
now has an updated sheet which (I haven't examined it yet) should
satisfy my question so I shan't follow up there except in the event I
have further questions.


> This is one of many outstanding items still
> for the Validation Working Group of the CA/B Forum, as possible
> mitigations were also discussed. In short, "capability URLs" (where
> the entire URL is, in effect, the capability) are dangerous.

Good to know.
 
> Note that there have been far more than "Ten Blessed Methods" since
> those discussions, so perhaps it's clearer to just say 3.2.2.4.

Personally I just like the way "Ten Blessed Methods" sounds.

I wouldn't reliably recognise all Thirty Six Views of Mount Fuji,
everything except (what I'd call) Big Wave, and Watermill could be any
of dozens of imitators as far as this uneducated eye is concerned - and
of course there are actually ten more of them, but we still call it
"Thirty Six Views of Mount Fuji".

The addition (and deprecation) of methods is an expected and desirable
course for the Baseline Requirements, and I am watching even if I don't
comment on it.

However because everything is formatted according to RFC 3647 (which is
a good thing), section 3.2.2.4 doesn't carry the same implication as
"Ten Blessed Methods". BR 1.3.0 had a section 3.2.2.4 it's just that it
doesn't in fact set down which methods must be used, which is how we
got here in the first place.

But I'm not old enough just yet to be incapable of learning new tricks,
I've learned to call it a "blocklist" not a "blacklist" and I'm sure if
everybody really starts to refer only to "3.2.2.4" I'll get used to
that.

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

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

All,

The proposed change currently reads,

"Full-surveillance period-of-time audits MUST be conducted and updated
audit information provided no less frequently than annually from the time
of CA key pair generation until the CA certificate is no longer trusted by
Mozilla's root store or until all copies of the CA private key have been
completely destroyed, as evidenced by a Qualified Auditor's key destruction
report, whichever occurs sooner. This cradle-to-grave audit requirement
applies equally to subordinate CAs as it does to root CAs. Successive
period-of-time audits MUST be contiguous (no gaps)."
But is the argument that I should also add something along these
lines--"This cradle-to-grave audit requirement applies equally to ...,  *and
an audit would be required for all subordinate CAs until their private keys
have been completely destroyed as well*."?  Is that still the issue here?
Or has it already been resolved with the language further above?

Thanks,

Ben

On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson  wrote:

> I agree that we should add language that makes it more clear that the key
> destruction exception for audit only applies to the CA certificates whose
> key has been destroyed.  I'm also hoping that a CAO wouldn't destroy a Root
> CA key if there were still valid subordinate CAs that the CAO might need to
> revoke.
>
> On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 2020-11-05 22:43, Tim Hollebeek wrote:
>> > So, I'd like to drill down a bit more into one of the cases you
>> discussed.
>> > Let's assume the following:
>> >
>> > 1. The CAO [*] may or may not have requested removal of the CAC, but
>> removal
>> > has not been completed.  The CAC is still trusted by at least one public
>> > root program.
>> >
>> > 2. The CAO has destroyed the CAK for that CAC.
>> >
>> > The question we've been discussing internally is whether destruction
>> alone
>> > should be sufficient to get you out of audits, and we're very skeptical
>> > that's desirable.
>> >
>> > The problem is that destruction of the CAK does not prevent issuance by
>> > subCAs, so issuance is still possible.  There is also the potential
>> > possibility of undisclosed subCAs or cross relationships to consider,
>> > especially since some of these cases are likely to be shutdown
>> scenarios for
>> > legacy, poorly managed hierarchies.  Removal may be occurring
>> *precisely*
>> > because there are doubts about the history, provenance, or scope of
>> previous
>> > operations and audits.
>> >
>> > We're basically questioning whether there are any scenarios where
>> allowing
>> > someone to escape audits just because they destroyed the key is likely
>> to
>> > lead to good outcomes as opposed to bad ones.  If there aren't
>> reasonable
>> > scenarios where it is necessary to be able to remove CACs from audit
>> scope
>> > through key destruction while they are still trusted by Mozilla, it's
>> > probably best to require audits as long as the CACs are in scope for
>> > Mozilla.
>> >
>> > Alternatively, if there really are cases where this needs to be done, it
>> > would be wise to craft language that limits this exception to those
>> > scenarios.
>> >
>>
>> I believe that destruction of the Root CA Key should only end audit
>> requirements for the corresponding Root CA itself, not for any of its
>> still trusted SubCAs.
>>
>> One plausible (but hypothetical) sequence of events is this:
>>
>> 1. Begin Root ceremony with Auditors present.
>>
>> 1.1 Create Root CA Key pair
>> 1.2 Sign Root CA SelfCert
>> 1.3 Create 5 SubCA Key pairs
>> 1.4 Sign 5 SubCA pre-certificates
>> 1.5 Request CT Log entries for the 5 SubCA pre-certificates
>> 1.6 Sign 5 SubCA certificates with embedded CTs
>> 1.7 Sign, but do not publish a set of post-dated CRLs for various
>> contingencies
>> 1.8 Sign, but do not publish a set of post-dated revocation OCSP
>> responses for those contingencies
>> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation
>> OCSP responses confirming that the SubCAs have not been revoked on each
>> date during their validity.
>> 1.10 Destroy Root CA Key pair.
>>
>> 2. Initiate audited storage of the unreleased CRL and OCSP signatures.
>>
>> 3. End Root ceremony, end root CAC audit period.
>>
>> 4. Release public audit report of this ceremony, this ends the ordinary
>> audits required for the Root CA Cert.  However audit reports that only
>> the correct contingency and continuation OCSP/CRL signatures were
>> released from storage remain technically needed.
>>
>> 5. Maintain revocation servers that publish the prepared CRLs and OCSP
>> answers according to their embedded dates.  Feed their publication queue
>> from audited batch releases from the storage.
>>
>> 6. Operate the 5 SubCAs under appropriate security and audit schemes
>> detailed in CP/CPS document pairs.
>>
>> 7. Apply for inclusion in the Mozilla root program.
>>
>>
>> In the above 

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
On Monday, I'm going to recommend to Kathleen that we proceed with these
root inclusion requests of GlobalSign.
Please let us know if there are any concerns.
Thanks,
Ben

On Fri, Feb 12, 2021 at 7:31 AM Arvid Vermote via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Nick
>
> We attached an updated version of the affected certificate overview to the
> bug on February 10, which does contain the date of order and date of
> issuance.
>
> Thanks
>
> Arvid
>
> > -Original Message-
> > From: dev-security-policy  >
> On
> > Behalf Of Nick Lamb via dev-security-policy
> > Sent: donderdag 11 februari 2021 19:12
> > To: dev-security-policy@lists.mozilla.org
> > Cc: Ben Wilson 
> > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for
> R46,
> > E46, R45 and E45 Roots
> >
> > On Tue, 9 Feb 2021 14:29:15 -0700
> > Ben Wilson via dev-security-policy
> >  wrote:
> >
> > > All,
> > > GlobalSign has provided a very detailed incident report in Bugzilla -
> > > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> > > There are a few remaining questions that still need to be answered, so
> > > this email is just to keep you aware.
> > > Hopefully later this week I'll be able to come back and see if people
> > > are satisfied and whether we can proceed with the root inclusion
> > > request.
> >
> > I have a question (if I should write it in Bugzilla instead please say so
> it is unclear
> > to me what the correct protocol is)
> >
> > GlobalSign have provided a list of 112 other certificates which were
> issued for the
> > same reason, I examined some of them manually and determined that they
> are
> in
> > appearance unextraordinary (2048-bit RSA keys for example) and so it's
> > unsurprising we didn't notice they were issued previously.
> >
> > However, the list does not tell me when these certificates were ordered
> or, if
> > substantially different, when the email used to "validate" these orders
> was sent.
> >
> > As a result it's hard to be sure whether these certificates were issued
> perhaps
> > only a few weeks after they were ordered, which is a relatively minor
> oversight,
> > or, like the incident certificate, many years afterwards. I'd like maybe
> a
> column of
> > "order date" and "email sent date" if the two can be different.
> >
> > -
> >
> > I also have noticed something that definitely isn't (just) for
> GlobalSign.
> It seems to
> > me that the current Ten Blessed Methods do not tell issuers to prevent
> robots
> > from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want
> this
> > certificate" POST form ought to be enough to defuse typical "anti-virus",
> "anti-
> > malware" or automated crawling/ cache building robots. Maybe I just
> missed
> > where the BRs tell you to prevent that, and hopefully even without
> prompting all
> > issuers using the email-based Blessed Methods have prevented this,
> >
> >
> > Nick.
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy