Welcome Ben Wilson to Mozilla!

[Ben Wilson via dev-security-policy]

Thanks, Kathleen

I'm really excited to begin working with all of you!

Cheers and stay safe,

Ben Wilson

On Mon, Apr 13, 2020 at 11:07 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> All,
>
> I am pleased to announce that Ben Wilson has joined Mozilla as a CA
> Program Manager!
>
> Ben has worked in PKI security, compliance, and policy since 1998.
> Previously, he worked at DigiCert in various roles, including VP of PKI
> Operations, VP of Compliance, and Chair of DigiCert’s Policy Authority
> team to develop and communicate policies and practices for internal and
> external stakeholders. Ben has also been very involved in the CA/Browser
> Forum. He is a former Chair of the CA/Browser Forum and of the American
> Bar Association’s Information Security Committee. Over the years, Ben
> has also participated in this mozilla.dev.security.policy forum.
>
> Here are some of the things that Ben will be responsible for:
> + Steps 3 through 9 of Mozilla’s root inclusion process[1], which
> includes the detailed CP/CPS reviews[2] and the public discussion phase[3]
> + CA Incident Bugs[4]
> + Updates to Mozilla’s Root Store Policy[5] and the Common CCADB
> Policy[6], including prioritizing potential changes[7] and leading
> discussions to determine the actual changes
> + Represent Mozilla in the CA/Browser Forum, along with Wayne
>
> I have added Ben to the Policy_Participants wiki page[8], and updated
> Wayne's entry.
>
> Welcome, Ben!
>
> Thanks,
> Kathleen
>
> [1] https://wiki.mozilla.org/CA/Application_Process
> [2] https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review
> [3] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion
> [4] https://wiki.mozilla.org/CA/Incident_Dashboard
> [5]
>
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> [6] https://www.ccadb.org/policy
> [7] https://github.com/mozilla/pkipolicy/issues
> [8] https://wiki.mozilla.org/CA/Policy_Participants
> ___
> 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: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

Dear Sándor,

I have a couple of follow-up questions for Microsec.

There were some responses during the recent public discussion in which
Microsec indicated it would update its CPS(es).

When do you anticipate that this will occur?

Also, it is also unclear from the quoted thread below whether such updates
will include additions to section 1.5.2 as required by Section 4.9.3 of the
Baseline Requirements.

Could you please clarify if and when section 1.5.2 will be updated?

Thanks.

Sincerely yours,

Ben Wilson
Mozilla Root Program



   -

   BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for
   reporting an issue such as key compromise to the CA. The Microsec CPS’
   only state that questions related to the policy may be reported via the
   info in that section, and other email addresses

(“highpriority...@e-szigno.hu”,

“revoc...@e-szigno.hu") are found in other sections of some documents. Section
4.9.5 then states that revocation requests are only accepted at the address
listed in section 1.2, but there is no email address in this section.

The CPS of Microsec is structured according to the requirement of RFC3647.
This also required by the CABF BR in section 2.2. According to RFC3647 the
Section 1.5 is for the policy administration and section 1.5.2 defines the
contact person who is responsible for maintaining the CPS. Section 4.9.3 of
the CPS contains detailed information about the possibilities of revocation
request submission. Section 1.3.1 contains the email addresses, where
revocation request can be sent (mentioning section 1.2 is an editorial
mistake, it will be corrected in the next version of the CPS). Section
4.9.3 contains also a subsection which describes the High-Priority
Certificate Problem Report mechanism. More detailed information can be
found on our website on the given link.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ben Wilson via dev-security-policy]

Dear MDSP community,

As you are aware from past discussions on this list, there has been a
concern about the impact of COVID-19 on CA operations.  COVID-19 continues
to impact certain areas of the world more severely than others. For
example, there has been a recent resurgence of COVID-19 in Japan.[1]  Globally,
COVID-19 has not leveled out.[2]

Recently at least one CA has expressed concern about Action 3 of Mozilla's
January 2020 CA Communication [3] and enforcement of Section 5.2 of
Mozilla’s Root Store Policy, which provide that as of 1-July-2020,
end-entity certificates MUST include an EKU extension containing
KeyPurposeId(s) describing the intended usage(s) of the certificate, and
the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
See [4].

Some CAs (and their customers) located in Japan, the U.S., and elsewhere
are dealing with new priorities that were not apparent back in January.  Some
have had to reorganize to deal with reduced staff and reallocate resources,
while other companies have modified their schedules to delay changes that
might cause instability.[5], [6]

For some parties, the benefit of a 3-month delay (to 1-October-2020) in
enforcement of Mozilla’s EKU requirement may result in more flexibility,
resilience and secure operations.

Several options are being considered:

1.   Require that a CA request an extension, to be submitted on
Bugzilla and flagged as “covid-19”, similar to audit delays [7] AND

a.   Not require an incident report, OR

b.   Require an incident report

2.   Grant a blanket 3-month extension and not require revocation of
certificates that do not comply

3.   Replace July 1 with October 1 in section 5.2 of the Mozilla Root
Store Policy and publish a new version

4.   Recognize broader exceptions for COVID-19 issues, e.g. enlarge the
scope of the delayed-audit approach to include other non-conformities/other
issues and not require immediate certificate revocations

I look forward to hearing your opinions and suggestions.

Sincerely yours,

Ben Wilson

Endnotes:

[1]  https://apnews.com/9140ddd7283d534d8464778d9c4bd92a

[2]
https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases

[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3waNOW&QuestionId=Q00086,Q00087,Q00097


[4]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices

[5]  https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020

[6]
https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

[7]  https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ben Wilson via dev-security-policy]

 Dear Andrew,

The purpose of my email was to alert the Mozilla community of a COVID-19
concern as it arose and to start/continue a dialogue on these COVID-19
matters. I was hoping to get some general feedback to help guide our
COVID-19 policy.

I appreciate the feedback so far. As mentioned in the responses, the CA
will have to come forward to this list with more details about the issues
it faces, that way, the specific merits of its situation can be openly and
transparently evaluated.  If the CA chooses not to come forward, I will
assume that it will comply with the July 1 EKU deadline.

Sincerely yours,

Ben

On Thu, Apr 23, 2020 at 2:56 AM westmail24--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello Ben,
> What CA you present here?
> Andrew.
> ___
> 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

Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

This request is for inclusion of the certSIGN Root CA G2 certificate and to
turn on the Websites trust bit and for EV treatment.


The request is documented in Bugzilla and in the CCADB as follows:

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

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

(Summary of info gathered and verified, URLs for test websites, etc.)



* certSIGN’s BR Self Assessment is here:

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

The Certsign document repository can be found here:

https://www.certsign.ro/en/certsign-documents/policies-procedures

* Root Certificate Locations:

http://crl.certsign.ro/certsign-rootg2.crt

http://registru.certsign.ro/certcrl/certsign-rootg2.crt

http://www.certsign.ro/certcrl/certsign-rootg2.crt

https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305

https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem


* EV Policy OID:   2.23.140.1.1

* CRL URL: http://crl.certsign.ro/certsign-rootg2.crl

* OCSP URL: http://ocsp.certsign.ro



* Audit: See https://bugzilla.mozilla.org/attachment.cgi?id=9142635 (
http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1612-163_V10_Certsign_S.pdf)
which shows that a recent annual audit was performed on the certSIGN Root
CA G2 by LSTI Group according to ETSI EN 319 411-2, V2.2.2 (2018-04)”,
“ETSI EN 319 411-1, V1.2.2 (2018-04)” and “ETSI EN 319 401, V2.2.1
(2018-04)” as well as the CA/Browser Forum’s “EV SSL Certificate
Guidelines, version 1.7.1” and “Baseline Requirements, version 1.6.7”
considering the requirements of the “ETSI EN 319 403, V2.2.2 (2015-08)” for
the Trust Service Provider Conformity Assessment.


* CP/CPS Review

Ryan Sleevi conducted a preliminary review the PKI Disclosure Statement and
CPS - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13

I followed up, and now Comment #24 in Bugzilla shows the latest responses
from Certsign - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c24



This begins the 3-week comment period for this request.

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

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

Re: Mozilla's Expectations for OCSP Incident Reporting

[Ben Wilson via dev-security-policy]

Just an FYI - I've also started a thread on the CA/Browser Forum list to
see about establishing OCSP uptime requirements in the Baseline
Requirements.

On Mon, May 11, 2020 at 5:45 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2020-05-08 21:03, Wayne Thayer wrote:
> > It was recently reported [1] that IdenTrust experienced a multi-day OCSP
> > outage about two weeks ago. Other recent OCSP issues have resulted in
> > incident reports [3][4], so I am concerned that IdenTrust didn't report
> > this, and I created a bug [5] to ensure that we track the issue (assuming
> > the report of an extended outage is accurate).
> >
> > I also created an issue [6] suggesting that Mozilla clarify expectations
> > for reporting CRL and OCSP outages. These services are notoriously
> > unreliable and I doubt that a constant barrage of reports for brief
> outages
> > would be manageable. I believe that Mozilla does expect CAs to report
> > "significant" outages, but there is currently no guidance to help CAs
> > determine when they should file a report.
>
> Should we have minimum uptime requirements? For instance 90% for a 24
> hour period and 95% per 30 days?
>
>
> Kurt
> ___
> 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: Digicert issued certificate with let's encrypts public key

[Ben Wilson via dev-security-policy]

Thanks, Corey.
I've added this as a matter to consider in a future version of the Root
Store Policy. https://github.com/mozilla/pkipolicy/issues/215

On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> While I realize the current topic is concerning TLS, I find it rather
> surprising that Mozilla Policy does not mandate PoP for S/MIME certificate
> issuance. Lack of checking for S/MIME would present more concrete security
> concerns, so perhaps this should be addressed in a future update to the
> Policy.
>
> Thanks,
> Corey
> ___
> 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: Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

In accordance with the CA inclusion process[1], this is a summary of the
public discussion of Certsign’s application for inclusion of the certSIGN
ROOT CA G2 into the Mozilla root store with the websites trust bit and EV
enabled. The request is documented in Bugzilla #1403453[2]. The public
discussion began on 6-May-2020[3].

During the public discussion, it was noted that the audit report listed six
minor non-conformities regarding documentation and process
implementation[4]. Of primary concern was recordkeeping of the CA key
shares. Certsign responded that all six non-conformities, including key
share recordkeeping, had been remediated[5]. Specifically with regard to
the CA key shares, Certsign has registered its DR backup shares in its
asset inventory, card custody is recorded, use of secrets by the
application is logged by a script, and person(s) with access to the
safeboxes no longer has/have access to the room where the safeboxes are
stored.[6]

No other comments were received.

Based on a totality of the information presented and reviewed, I am
planning to recommend that Certsign’s application be approved.


I appreciate any feedback on this proposed course of action.

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ


[4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635

[5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366

[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ


On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:
> > The ETSI audit attestation statement referenced by Ben [1] lists 6
> > non-conformities that were to be corrected within 3 months of the onsite
> > audit that occurred on 2020-02-10 until 2020-02-14:
> >
> > Findings with regard to ETSI EN 319 401:
> > -REQ-7.8-06–Documentation shall be improved
> >
> > Findings with regard to ETSI EN 319 411-1:
> > -REG-6.3.1-01–Implementation shall be improved
> > -GEN-6.5.1-04-Implementation shall be improved
> >
> > Findings with regard to ETSI EN 319 411-2:
> > -SDP-6.5.1-02 -Implementation shall be improved
> > -GEN-6.6.1-05–Documentation shall be improved
> > -CSS-6.3.10-13–Documentation shall be improved
> >
> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
> > signing certificates shall be created under, at least, dual control.
> >
> > I'd like to see an explanation of these non-conformities and the
> > remediation from certSIGN, and confirmation from LSTI that they have been
> > fixed.
> >
> > - Wayne
> >
> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
> >
> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > This request is for inclusion of the certSIGN Root CA G2 certificate
> and to
> > > turn on the Websites trust bit and for EV treatment.
> > >
> > >
> > > The request is documented in Bugzilla and in the CCADB as follows:
> > >
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
> > >
> > >
> > >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
> > >
> > > (Summary of info gathered and verified, URLs for test websites, etc.)
> > >
> > >
> > >
> > > * certSIGN’s BR Self Assessment is here:
> > >
> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673
> > >
> > > The Certsign document repository can be found here:
> > >
> > > https://www.certsign.ro/en/certsign-documents/policies-procedures
> > >
> > > * Root Certificate Locations:
> > >
> > > http://crl.certsign.ro/certsign-rootg2.crt
> > >
> > > http://registru.certsign.ro/certcrl/certsign-rootg2.crt
> > >
> > > http://www.certsign.ro/certcrl/certsign-rootg2.crt
> > >
> > >
> > >
> https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305
> > >
> > >
> > >
> https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem
> > >
> > >
> > > * EV Policy OID:   2.23.140.1.1
> > >
> > > * CRL URL: http://crl.certsign.ro/certsign-rootg2.crl
> > >
> > > * OCSP URL: http://ocsp.certsign.ro
> &g

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

In accordance with the CA inclusion process,[1] this is a summary of the
public discussion of Microsec’s application for inclusion of the e-Szigno
Root CA 2017 into the Mozilla root store, and to EV enable it and the
currently-included e-Szigno Root CA 2009. The request is documented in
Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
email launching the public discussion and comments received during the
public discussion raised a number of issues, not all of which are itemized
here, including:

* the CPS was unclear about certificate problem reporting and revocation
request processing[4]; and

* Microsec has had systemic, standards-related non-conformities, e.g. Bug#
1622539[5], and needs to demonstrate better behavior in keeping up with and
complying with the CABF Baseline Requirements and root store policy.[6]

Microsec is resolving these concerns by:

- updating its CPS[7][8]; and

- committing to engage in better compliance with industry standards[9].

In my opinion Microsec has demonstrated sufficient response that we do not
need to remove Microsec from Mozilla’s root store. Therefore, once I am
satisfied after a review of the updated CPS, I am planning to recommend
that we approve the request to include the e-Szigno Root CA 2017
certificate and enable the websites trust bit. However, I plan to deny the
request for EV treatment for both root certificates. Microsec may re-apply
by filing a new request for EV treatment after they have demonstrated
improved compliance with the BRs and EV Guidelines.

I appreciate any feedback on this proposed course of action.

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ

[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ


[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539

[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ


[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ


[8]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30


[9]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ



On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Dear Ben,
>
> I confirm that Microsec will correct all issues in the CP and CPS
> documents as promised during the public discussion.
>
> Thanks to everyone who took the time to read Microsec CP and CPS and to
> comment on them.
>
> If there are no more comments on the content of our CP and CPS documents
> in the public discussion, we will review the thread again and gather all
> the issues to be resolved.
> As usual, Microsec will review current versions of all applicable
> requirements for changes.
>
> I confirm that the section 1.5.2 will be changed. The High Priority
> Certificate Problem Report will be reviewed and will be moved here from
> section 4.9.3.
>
> Other issues I can see after a brief overview:
> - Preliminary report in case of Certificate problem report in section 4.9.5
> - correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5
> - review the email address validation rules in case of non-automatic
> validation procedure in section 3.2.7
>
> I expect that Microsec will be able to do it within one week and will
> prepare the draft version of the public documents by the end of April.
>
> We publish the drafts on our website and send them to the auditor and our
> supervisory authority at the same time.
>
> This is followed by a 30-day commenting period during which anyone can
> comment on the planned changes.
> If significant issues arise during this period, the draft shall be amended
> and the 30 days shall begin again.
> If there are no significant issues, the new document will enter into force
> by the end of May 2020.
>
> Please let us know if you expect us to take any further steps in this
> process.
>
> Best regards,
>
> Sándor
>
> dr. Sándor Szőke
> Microsec deputy director
> ___
> 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: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
to hold up approval of the inclusion of this root for the following
reasons, which I believe are relatively minor, but Microsec should be aware
that:

   - section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
   Authentication CPS" (
   https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
   CPS") appears to allow certain identifiers, allowed for EV, but not yet
   added to the Baseline Requirements, see
   
https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
   This is something that should be taken up with the CA/Browser Forum (and
   corrected in Microsec's CPS); and
   - section 4.9.5 of the CPS, which states, "Emails arriving out of office
   hours are considered as arrived at the beginning of the next business day."
   This may put Microsec at risk of a violation of the Baseline Requirements
   sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet
   defined in the Baseline Requirements, there is an expectation of 24x7
   availability, which it appears Microsec is providing - "The Trust Service
   Provider maintains a continuous 24x7 ability to respond internally to a
   High Piority Certificate Problem Report."

This concludes my review of the Microsec CPs/CPSes, and I believe it is now
appropriate to begin the process of adding this root CA into NSS (without
EV enablement).

On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process,[1] this is a summary of the
> public discussion of Microsec’s application for inclusion of the e-Szigno
> Root CA 2017 into the Mozilla root store, and to EV enable it and the
> currently-included e-Szigno Root CA 2009. The request is documented in
> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
> email launching the public discussion and comments received during the
> public discussion raised a number of issues, not all of which are itemized
> here, including:
>
> * the CPS was unclear about certificate problem reporting and revocation
> request processing[4]; and
>
> * Microsec has had systemic, standards-related non-conformities, e.g. Bug#
> 1622539[5], and needs to demonstrate better behavior in keeping up with and
> complying with the CABF Baseline Requirements and root store policy.[6]
>
> Microsec is resolving these concerns by:
>
> - updating its CPS[7][8]; and
>
> - committing to engage in better compliance with industry standards[9].
>
> In my opinion Microsec has demonstrated sufficient response that we do not
> need to remove Microsec from Mozilla’s root store. Therefore, once I am
> satisfied after a review of the updated CPS, I am planning to recommend
> that we approve the request to include the e-Szigno Root CA 2017
> certificate and enable the websites trust bit. However, I plan to deny
> the request for EV treatment for both root certificates. Microsec may
> re-apply by filing a new request for EV treatment after they have
> demonstrated improved compliance with the BRs and EV Guidelines.
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>
>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>
>
> [7]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>
>
> [8]
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>
>
> [9]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>
>
>
> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Dear Ben,
>>
>> I confirm that Microsec will correct all issues in the CP and CPS
>> documents as promised during the public discussion.
>>
>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>> comment on them.
>>
>> If there are no more comments on the content of our CP and CPS documents
>> in the public discussion, we will review the thread again and gather all
>> the issues to be resolved.
>> As usual, Microsec will review current versions of all applicable
>> requirements for changes.
>>
>> I confirm that the section 1.5.2 will be changed. The High Priority
>> Certificate Problem Report will be reviewed and will be moved here from
>> section 4.9.3.
>>
>> Other issues I can see after a brief overview:
>> - Preliminary report in case of Certificate problem report in section
>> 4.9.5
>> - correct the reference to section 1.3.1 instead of 1.2 in sec

CA Configuration and Operation

[Ben Wilson via dev-security-policy]

Often CA configurations and settings are complex and can be difficult to
manage. We would like to remind CA operators that they need to be familiar
with the configuration and operation of all aspects of CA software and
ensure that they have adequate documentation and training.

For example, in April, a CA operator in the Mozilla Root Program received a
post-issuance warning that a certificate with an RSASSA-PSS key had made it
through the EJBCA pre-issuance check.[1][2]  Apparently, “Check for RSA” on
CSR input allowed an RSASSA-PSS key through because it was considered part
of the RSA suite that was whitelisted. Internal documentation for CA setup
did not include correct validator (pre-issuance) configuration setup.

The CA operator started an investigation into why this occurred. Upon
investigation the CA operator discovered that the validator had started
functioning due to a configuration change occurring unbeknownst to an
engineer when he clicked on save after selecting the validator in CA
settings. The CA operator explained that highlighting the specific
validator was an additional required step after adding a certificate
profile in the validator settings. This additional step was not clearly
stated in the CA software manual.

The vendor has explained that this misunderstanding was due to the fact
that validators need to be enabled on a certificate-profile basis, in order
to allow the same CA to host multiple profiles without validators
conflicting with each other. As certificate profiles can be shared amongst
multiple CAs, the validator needs to be selected there as well.

The vendor also recommends that CA operators use the provided human
readable configuration export tool to run and diff after upgrades and
configuration changes to verify that nothing unintended has changed.

In summary, the general purpose of this email is to urge all CA operators
to be familiar with configuration processes of the CA software that they
use, and specifically to alert users of EJBCA to the procedural measures
described above.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1630870

[2] EJBCA software by Primekey has a pre-issuance “validator” system for
keys, amongst which an external validator to run linters. See
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/validators-overview/post-processing-validators
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben

On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson  wrote:

> I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
> to hold up approval of the inclusion of this root for the following
> reasons, which I believe are relatively minor, but Microsec should be aware
> that:
>
>- section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
>Authentication CPS" (
>https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
>CPS") appears to allow certain identifiers, allowed for EV, but not yet
>added to the Baseline Requirements, see
>
> https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
>This is something that should be taken up with the CA/Browser Forum (and
>corrected in Microsec's CPS); and
>- section 4.9.5 of the CPS, which states, "Emails arriving out of
>office hours are considered as arrived at the beginning of the next
>business day." This may put Microsec at risk of a violation of the Baseline
>Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival")
>is not yet defined in the Baseline Requirements, there is an expectation of
>24x7 availability, which it appears Microsec is providing - "The Trust
>Service Provider maintains a continuous 24x7 ability to respond internally
>to a High Piority Certificate Problem Report."
>
> This concludes my review of the Microsec CPs/CPSes, and I believe it is
> now appropriate to begin the process of adding this root CA into NSS
> (without EV enablement).
>
> On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:
>
>> In accordance with the CA inclusion process,[1] this is a summary of the
>> public discussion of Microsec’s application for inclusion of the e-Szigno
>> Root CA 2017 into the Mozilla root store, and to EV enable it and the
>> currently-included e-Szigno Root CA 2009. The request is documented in
>> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
>> email launching the public discussion and comments received during the
>> public discussion raised a number of issues, not all of which are itemized
>> here, including:
>>
>> * the CPS was unclear about certificate problem reporting and revocation
>> request processing[4]; and
>>
>> * Microsec has had systemic, standards-related non-conformities, e.g.
>> Bug# 1622539[5], and needs to demonstrate better behavior in keeping up
>> with and complying with the CABF Baseline Requirements and root store
>> policy.[6]
>>
>> Microsec is resolving these concerns by:
>>
>> - updating its CPS[7][8]; and
>>
>> - committing to engage in better compliance with industry standards[9].
>>
>> In my opinion Microsec has demonstrated sufficient response that we do
>> not need to remove Microsec from Mozilla’s root store. Therefore, once I am
>> satisfied after a review of the updated CPS, I am planning to recommend
>> that we approve the request to include the e-Szigno Root CA 2017
>> certificate and enable the websites trust bit. However, I plan to deny
>> the request for EV treatment for both root certificates. Microsec may
>> re-apply by filing a new request for EV treatment after they have
>> demonstrated improved compliance with the BRs and EV Guidelines.
>>
>> I appreciate any feedback on this proposed course of action.
>>
>> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>>
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>>
>> [3]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>>
>> [4]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>>
>>
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>>
>> [6]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>>
>>
>> [7]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>>
>>
>> [8]
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>>
>>
>> [9]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>>
>>
>>
>> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Dear Ben,
>>>
>>> I confirm that Microsec will correct all issues in the CP and CPS
>>> documents as promised during the public discussion.
>>>
>>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>>> comment on them.
>>>
>>> If there are no more comments on the content of our CP and CPS documents
>>> in the public discussion, we will review the thread again and gather all
>>> the issues to be resolved.
>>> As usual, Microsec will review current versions of all applicable
>>> requirements for changes.
>>>
>>> I confirm th

Re: Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1403453
<https://bugzilla.mozilla.org/show_bug.cgi?id=1403453>

- Ben

On Thu, May 28, 2020 at 12:06 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process[1], this is a summary of the
> public discussion of Certsign’s application for inclusion of the certSIGN
> ROOT CA G2 into the Mozilla root store with the websites trust bit and EV
> enabled. The request is documented in Bugzilla #1403453[2]. The public
> discussion began on 6-May-2020[3].
>
> During the public discussion, it was noted that the audit report listed
> six minor non-conformities regarding documentation and process
> implementation[4]. Of primary concern was recordkeeping of the CA key
> shares. Certsign responded that all six non-conformities, including key
> share recordkeeping, had been remediated[5]. Specifically with regard to
> the CA key shares, Certsign has registered its DR backup shares in its
> asset inventory, card custody is recorded, use of secrets by the
> application is logged by a script, and person(s) with access to the
> safeboxes no longer has/have access to the room where the safeboxes are
> stored.[6]
>
> No other comments were received.
>
> Based on a totality of the information presented and reviewed, I am
> planning to recommend that Certsign’s application be approved.
>
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ
>
>
> [4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>
> [5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ
>
>
> On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:
>> > The ETSI audit attestation statement referenced by Ben [1] lists 6
>> > non-conformities that were to be corrected within 3 months of the onsite
>> > audit that occurred on 2020-02-10 until 2020-02-14:
>> >
>> > Findings with regard to ETSI EN 319 401:
>> > -REQ-7.8-06–Documentation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-1:
>> > -REG-6.3.1-01–Implementation shall be improved
>> > -GEN-6.5.1-04-Implementation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-2:
>> > -SDP-6.5.1-02 -Implementation shall be improved
>> > -GEN-6.6.1-05–Documentation shall be improved
>> > -CSS-6.3.10-13–Documentation shall be improved
>> >
>> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
>> > signing certificates shall be created under, at least, dual control.
>> >
>> > I'd like to see an explanation of these non-conformities and the
>> > remediation from certSIGN, and confirmation from LSTI that they have
>> been
>> > fixed.
>> >
>> > - Wayne
>> >
>> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>> >
>> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > > This request is for inclusion of the certSIGN Root CA G2 certificate
>> and to
>> > > turn on the Websites trust bit and for EV treatment.
>> > >
>> > >
>> > > The request is documented in Bugzilla and in the CCADB as follows:
>> > >
>> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>> > >
>> > >
>> > >
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
>> > >
>> > > (Summary of info gathered and verified, URLs for test websites, etc.)
>> > >
>> > >
>> > >
>> > > * certSIGN’s BR Self Assessment is here:
>> > >
>> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673
>> > >
>> > > The Certsign document repository can be found here:
>> > >
>> > > https://www.certsign.ro/en/certsign-documents/policies-procedures
>> > >
>> > > * Root Certificate Locations:
>> > >
>> > > http://crl.certsign.ro/certsign-rootg2.crt
>> > &

Updated Language in CA Incident Report Template

[Ben Wilson via dev-security-policy]

All,

I have updated the wiki page containing the CA incident report template.
See https://wiki.mozilla.org/CA/Responding_To_An_Incident


The purpose of this update is to place more emphasis on the level of detail
that CAs should provide, especially in sections 6 (root cause) and 7
(remediation) of incident reports. Other changes were made to ensure that
all types of incidents (i.e. not just misissuance) can be adequately
explained.

Here is a diff version -
https://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=prev&oldid=1228621

Thanks,
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ben Wilson via dev-security-policy]

All,


Thank you to Ryan for identifying this problem, and to all of you who are
earnestly investigating what this problem means and the impact to your CA
hierarchies. Mozilla::pkix requires that an OCSP responder certificate be
an end entity certificate, so we believe that Firefox and Thunderbird are
not impacted by this problem. Historically, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=991209#c10, Mozilla has
allowed CA certificates to have the OCSP signing EKU because some CAs
reported that some Microsoft server software required CA certificates to
have the id-kp-OCSPSigning EKU.

The comments in the code[1] say

// When validating anything other than an delegated OCSP signing cert,

// reject any cert that also claims to be an OCSP responder, because such

// a cert does not make sense. For example, if an SSL certificate were to

// assert id-kp-OCSPSigning then it could sign OCSP responses for itself,

// if not for this check.

// That said, we accept CA certificates with id-kp-OCSPSigning because

// some CAs in Mozilla's CA program have issued such intermediate

// certificates, and because some CAs have reported some Microsoft server

// software wrongly requires CA certificates to have id-kp-OCSPSigning.

// Allowing this exception does not cause any security issues because we

// require delegated OCSP response signing certificates to be end-entity

// certificates.

Additionally, as you all know, Firefox uses OneCRL for checking the
revocation status of intermediate certificates, so as long as the revoked
intermediate certificate is in OneCRL, the third-party would not be able to
“unrevoke” their certificate (for Firefox). Therefore, Mozilla does not
need the certificates that incorrectly have the id-kp-OCSPSigning EKU to be
revoked within the next 7 days, as per section 4.9.1.2 of the BRs.

However, as Ryan has pointed out in this thread, others may still have risk
because they may not have a OneCRL equivalent, or they may have certificate
verification implementations that behave differently than mozilla::pkix in
regards to processing OCSP responder certificates. Therefore, it is
important to identify a path forward to resolve the security risk that this
problem causes to the ecosystem.

We are concerned that revoking these impacted intermediate certificates
within 7 days could cause more damage to the ecosystem than is warranted
for this particular problem. Therefore, Mozilla does not plan to hold CAs
to the BR requirement to revoke these certificates within 7 days. However,
an additional Incident Report for delayed revocation will still be
required, as per our documented process[2].  We want to work with CAs to
identify a path forward, which includes determining a reasonable timeline
and approach to replacing the certificates that incorrectly have the
id-kp-OCSPSigning EKU (and performing key destruction for them).

Therefore, we are looking forward to your continued input in this
discussion about the proper response for CAs to take to resolve the
security risks caused by this problem, and ensure that this problem is not
repeated in future certificates.  We also look forward to your suggestions
on how we can improve OCSP responder requirements in Mozilla’s Root Store
Policy, and to your continued involvement in the CA/Browser Forum to
improve the BRs.

Thanks,


Ben

[1]
https://dxr.mozilla.org/mozilla-central/rev/c68fe15a81fc2dc9fc5765f3be2573519c09b6c1/security/nss/lib/mozpkix/lib/pkixcheck.cpp#858-869

[2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation


On Wed, Jul 1, 2020 at 3:06 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certifi

New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

All,
This is just to let everyone know that I posted a new Mozilla Security blog
post this morning. Here is the link>
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
As I note at the end of the blog post, we continue to seek safeguarding
secure browsing by working with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to keep our users
safe.
Thanks,
Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3,
and the costs vs. benefits of going to a 398-day certificate lifetime.
We'll keep those in mind as we move forward. In response, the security of
our users is the primary concern for Mozilla. So while we recognize there
might be added costs and burdens, we still believe that they do not
outweigh the user security benefits of moving to a 398-day certificate
lifetime.
Thanks again,
Ben

On Thu, Jul 9, 2020 at 12:48 PM Paul Walsh  wrote:

> Good question. And I can see why you might ask that question.
>
> The community lead of PhishTank mistakenly said that submissions should
> only be made for URLs that are used to steal' credentials. This helps to
> demonstrate a misconception. While this might have been ok in the past,
> it’s not today.
>
> Phishing is a social engineering technique, used to trick consumers into
> trusting URLs / websites so they can do bad things - including but not
> limited to, man-in-the-middle attacks. Mozilla references this attack
> vector as one of the main reasons for wanting to reduce the life of a cert.
> They didn’t call it “phishing” but that’s precisely what it is.
>
> We can remove all of my references to “phishing” and replace it with
> “security risks” or “social engineering” if it makes this conversation a
> little easier.
>
> And, according to every single security company in the world that focuses
> on this problem, certificates are absolutely used by bad actors - if only
> to make sure they don’t see a “Not Secure” warning.
>
> I’m not talking about EV or identity related info here as it’s not
> related. I’m talking about the risk of a bad actor caring to use a cert
> that was issued to someone else when all they have to do is get a new one
> for free.
>
> I don’t see the risk that some people see. Hoping to be corrected because
> the alternative is that browsers are about to make life harder and more
> expensive for website owners with little to no upside - outside that of a
> researchers lab.
>
> Warmest regards,
> Paul
>
>
> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> According to Google, spear phishing
>
>
> I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
> since certificates have nothing to do with phishing. Did I overlook
> something saying it was about phishing?
>
> It seems reasonable to read it as it was written, which doesn't mention
> phishing, which isn't surprising, because certificates have never been able
> to address phishing.
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Some people have asked whether two-year certificates existing on August 31
would remain valid.  The answer is yes. Those certificates will remain
valid until they expire. The change only applies to certificates issued on
or after Sept. 1, 2020.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Yes, that's right.

On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie 
wrote:

> Ben,
>
> For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.
>
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Friday, July 10, 2020 12:49 PM
> To: mozilla-dev-security-policy
> 
> Subject: Re: New Blog Post on 398-Day Certificate Lifetimes
>
> Some people have asked whether two-year certificates existing on August 31
> would remain valid.  The answer is yes. Those certificates will remain
> valid
> until they expire. The change only applies to certificates issued on or
> after Sept. 1, 2020.
> ___
> 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

EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
documented here:

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

*  Summary of Information Gathered and Verified:

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

*  SHA2 hash for Root CA Certificate:
5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE

*  Root Certificate Download URL:

http://validation.identrust.com/roots/commercialrootca1.p7c

*  Identrust’s BR Self Assessment is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet
Download)

*  CPS:

https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf

*  Test Website:

https://ev-valid.identrustssl.com/

*  EV Policy OIDs:

2.16.840.1.113839.0.6.9,  2.23.140.1.1

* CRL URL:

http://validation.identrust.com/crl/commercialrootca1.crl

*  OCSP URL:

http://commercial.ocsp.identrust.com

*  Audit:

A period of time WebTrust EV annual audit report was provided on August 16,
2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That and
other WebTrust audit reports are available from the bottom of the following
applicant page:  https://www.identrust.com/support/documents/trustid.


I’ve reviewed the CPS, BR Self Assessment, and related information for this
inclusion request.  Comments and concerns regarding the CPS were
satisfactorily addressed as noted in
https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend that
the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
treatment.


This begins the 3-week comment period for this request.


I will greatly appreciate your thoughtful and constructive feedback on
Identrust’s request.

Sincerely yours,

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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben

On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
>
> Hi,
>
> blog post should clarify if this is valid for certificates issued by
> preinstalled root CAs only or also for CAs installed by user.
>
>
> regards
> Christian
> ___
> 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: EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

Today is the close of the comment period for the Identrust EV enablement
request. I don't believe we have received any comments, and I intend to
recommend that this request be approved unless there are any reasons why
the request should be denied.
Thanks,
Ben

On Fri, Jul 10, 2020 at 4:05 PM Ben Wilson  wrote:

> This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
> documented here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703
>
> *  Summary of Information Gathered and Verified:
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417
>
> *  SHA2 hash for Root CA Certificate:
> 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE
>
> *  Root Certificate Download URL:
>
> http://validation.identrust.com/roots/commercialrootca1.p7c
>
> *  Identrust’s BR Self Assessment is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet
> Download)
>
> *  CPS:
>
>
> https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf
>
> *  Test Website:
>
> https://ev-valid.identrustssl.com/
>
> *  EV Policy OIDs:
>
> 2.16.840.1.113839.0.6.9,  2.23.140.1.1
>
> * CRL URL:
>
> http://validation.identrust.com/crl/commercialrootca1.crl
>
> *  OCSP URL:
>
> http://commercial.ocsp.identrust.com
>
> *  Audit:
>
> A period of time WebTrust EV annual audit report was provided on August
> 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That
> and other WebTrust audit reports are available from the bottom of the
> following applicant page:
> https://www.identrust.com/support/documents/trustid.
>
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for
> this inclusion request.  Comments and concerns regarding the CPS were
> satisfactorily addressed as noted in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend
> that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
> treatment.
>
>
> This begins the 3-week comment period for this request.
>
>
> I will greatly appreciate your thoughtful and constructive feedback on
> Identrust’s request.
>
> Sincerely yours,
>
> Ben Wilson
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

Based on the record in Bugzilla Case 1551703 and the CCADB Case 417 (
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417)
, and receiving no further comments, I have recommended approval of this
request to EV-enable the Identrust Commercial Root CA 1.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1551703#c13


On Fri, Jul 31, 2020 at 10:28 AM Ben Wilson  wrote:

> Today is the close of the comment period for the Identrust EV enablement
> request. I don't believe we have received any comments, and I intend to
> recommend that this request be approved unless there are any reasons why
> the request should be denied.
> Thanks,
> Ben
>
> On Fri, Jul 10, 2020 at 4:05 PM Ben Wilson  wrote:
>
>> This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
>> documented here:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703
>>
>> *  Summary of Information Gathered and Verified:
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417
>>
>> *  SHA2 hash for Root CA Certificate:
>> 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE
>>
>> *  Root Certificate Download URL:
>>
>> http://validation.identrust.com/roots/commercialrootca1.p7c
>>
>> *  Identrust’s BR Self Assessment is located here:
>>
>> https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel
>> Spreadsheet Download)
>>
>> *  CPS:
>>
>>
>> https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf
>>
>> *  Test Website:
>>
>> https://ev-valid.identrustssl.com/
>>
>> *  EV Policy OIDs:
>>
>> 2.16.840.1.113839.0.6.9,  2.23.140.1.1
>>
>> * CRL URL:
>>
>> http://validation.identrust.com/crl/commercialrootca1.crl
>>
>> *  OCSP URL:
>>
>> http://commercial.ocsp.identrust.com
>>
>> *  Audit:
>>
>> A period of time WebTrust EV annual audit report was provided on August
>> 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That
>> and other WebTrust audit reports are available from the bottom of the
>> following applicant page:
>> https://www.identrust.com/support/documents/trustid.
>>
>>
>> I’ve reviewed the CPS, BR Self Assessment, and related information for
>> this inclusion request.  Comments and concerns regarding the CPS were
>> satisfactorily addressed as noted in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend
>> that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
>> treatment.
>>
>>
>> This begins the 3-week comment period for this request.
>>
>>
>> I will greatly appreciate your thoughtful and constructive feedback on
>> Identrust’s request.
>>
>> Sincerely yours,
>>
>> Ben Wilson
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SecureTrust: Root Certificates Inclusion Request

[Ben Wilson via dev-security-policy]

This email announces an intent to include the following three (3) root
certificates as trust anchors with the websites and email trust bits
enabled, and to enable each root for EV as documented in the following
Bugzilla case:  https://bugzilla.mozilla.org/show_bug.cgi?id=1528369

This email commences the three-week public discussion period set forth in
https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion.

The three root CA certificates are as follows:

*Trustwave Global Certification Authority* – valid from 23-Aug-2017

SHA2: 97552015F5DDFC3C8788C006944555408894450084F100867086BC1A2BB58DC8

*Trustwave Global ECC P256 Certification Authority* – valid from 23-Aug-2017

SHA2: 945BBC825EA554F489D1FD51A73DDF2EA624AC7019A05205225C22A78CCFA8B4

*Trustwave Global ECC P384 Certification Authority* –

SHA2: 55903859C8C0C3EBB8759ECE4E2557225FF5758BBD38EBD48276601E1BD58097


*A Summary of Information Gathered and Verified appears here in the CCADB:*
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0392


*Root Certificate Download URLs are as follows:*
https://certs.securetrust.com/CA/TWGCA.txt

https://certs.securetrust.com/CA/TWGP256CA.txt

https://certs.securetrust.com/CA/TWGP384CA.txt

*CP/CPS:*  We have reviewed the CPS and provided comments, which were
incorporated into SecureTrust's most recent CPS:

https://certs.securetrust.com/CA/SecureTrustCPS_62.pdf

(Repository location:  https://ssl.trustwave.com/CA /
https://certs.securetrust.com/CA/)

*SecureTrust’s BR Self Assessment* is located here:
https://bugzilla.mozilla.org/attachment.cgi?id=9060769

*Audits:*  Annual audits are performed by BDO International, Ltd. according
to the WebTrust Standard, BR and EV audit criteria.  I have reviewed the
key generation audit report from Grant Thornton and subsequent 2018 and
2019 audit reports for these three roots and determined that there is
continuity (all three are included in WebTrust Standard, BR and EV audits
continuously since CA generation). Minor issues were found by BDO
International, Ltd., as part of the 2019 Baseline Requirements audit.[1]
These issues were addressed in [2], which was closed by Mozilla on
14-Mar-2020.

[1]
https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1606031  (BR Audit 2019 -
matters to be resolved)


I ran mis-issuance reports for the three roots with linting to look for
issuance errors and didn’t find any from the three above-mentioned roots.


Other closed CA Incidents for SecureTrust include the following:

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1546776  (Unvalidated
domain in certificate )

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374  ("Some-State" in
stateOrProvinceName)

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1600844 (Unconstrained ICA
not included in WTBR audit report)

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1646711 (Metadata-only
field values in 2 certificates)


This email begins the three-week public discussion period, which will close
on 24-August-2020.

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

Temporary WebTrust Seal for COVID Issues

[Ben Wilson via dev-security-policy]

All,

Some CAs have inquired about Mozilla's acceptance of WebTrust's temporary,
6-month seal related to COVID19 issues.
See
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services

According to that WebTrust webpage, the temporary seal will be offered only
in situations that meet the following criteria:

   - The practitioner report has been qualified,
   - The qualification is directly related to government-imposed COVID-19
   scope restrictions only and is disclosed in the practitioner report, and
   - There are no qualifications due to control deficiencies in the period.

It also states, "When a temporary seal has been granted, it is expected
that a practitioner will be able to perform the procedures that could not
be completed initially which gave rise to the scope limitation before the
temporary seal expires. Where the practitioner is able to perform such
procedures and is able to issue subsequently an unqualified report for the
CA, the unqualified report could then be submitted to CPA Canada to obtain
the traditional seal."

For purposes of obtaining a timely audit, it appears that such a timely
filed report would satisfy Mozilla Policy 3.1.3's annual audit filing
requirements (
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters)
and therefore it would not be a "delay".  For context see
https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
and https://wiki.mozilla.org/CA/Audit_Statements#WebTrust_Audits.


So as further guidance on the above page, I am proposing clarification that
the Temporary WebTrust Seal for COVID-19-related qualified reports does not
require the CA to file an Incident Report, but rather that we will create a
CA Compliance bug in Bugzilla simply to track the expiration of the
temporary seal.

Thanks,
Ben Wilson
Mozilla Root Store Manager

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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will also be
enforced at the server-certificate level, through the incident-reporting
process and treated as a mis-issuance. See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents.
However, if a user installs its own CA certificate, then that CA can issue
server certificates with validity longer than 398 days. The code will check
the TLS server certificate to see if it chains to a publicly trusted root
and whether it was issued on or after 1-Sept-2020. If so, then if it does
not have a lifetime of less than 398 days, the TLS connection will be
blocked and there will be a warning message. See
https://bugzilla.mozilla.org/show_bug.cgi?id=908125
Does that answer your question?
Thanks,
Ben

On Tue, Aug 25, 2020 at 10:42 AM None Of via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> > Hi Christian,
> > I think your concern is about how our code will enforce this. Because
> our
> > policy only applies to roots that are built in, our intent is to have
> our
> > code apply this restriction only to certificates that chain up to
> built-in
> > roots.
> > Thanks,
> > Ben
> > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via
> dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> > > >
> > >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> > >
> > > Hi,
> > >
> > > blog post should clarify if this is valid for certificates issued by
> > > preinstalled root CAs only or also for CAs installed by user.
> > >
> > >
> > > regards
> > > Christian
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> Hello Ben,
>
> I also would like clarification as to whether this change is an
> "administrative change" for Mozilla accepting CAs in the included root
> store, or whether it will be a technical change in how Firefox validates CA
> certificate validity.
>
> If users install a CA cert that has a validity longer than 398 days after
> 1 Sept 2020, will this cause warning messages to appear?
> ___
> 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: SecureTrust: Root Certificates Inclusion Request

[Ben Wilson via dev-security-policy]

 Dear All,
The public discussion period for the three SecureTrust roots ended
yesterday, and I don't believe that we received any comments.
I intend to recommend that this request be approved unless there are any
reasons why the request should be denied.
Thanks,
Ben

On Mon, Aug 3, 2020 at 1:24 PM Ben Wilson  wrote:

> This email announces an intent to include the following three (3) root
> certificates as trust anchors with the websites and email trust bits
> enabled, and to enable each root for EV as documented in the following
> Bugzilla case:  https://bugzilla.mozilla.org/show_bug.cgi?id=1528369
>
> This email commences the three-week public discussion period set forth in
> https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion.
>
> The three root CA certificates are as follows:
>
> *Trustwave Global Certification Authority* – valid from 23-Aug-2017
>
> SHA2: 97552015F5DDFC3C8788C006944555408894450084F100867086BC1A2BB58DC8
>
> *Trustwave Global ECC P256 Certification Authority* – valid from
> 23-Aug-2017
>
> SHA2: 945BBC825EA554F489D1FD51A73DDF2EA624AC7019A05205225C22A78CCFA8B4
>
> *Trustwave Global ECC P384 Certification Authority* –
>
> SHA2: 55903859C8C0C3EBB8759ECE4E2557225FF5758BBD38EBD48276601E1BD58097
>
>
> *A Summary of Information Gathered and Verified appears here in the CCADB:*
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0392
>
>
> *Root Certificate Download URLs are as follows:*
> https://certs.securetrust.com/CA/TWGCA.txt
>
> https://certs.securetrust.com/CA/TWGP256CA.txt
>
> https://certs.securetrust.com/CA/TWGP384CA.txt
>
> *CP/CPS:*  We have reviewed the CPS and provided comments, which were
> incorporated into SecureTrust's most recent CPS:
>
> https://certs.securetrust.com/CA/SecureTrustCPS_62.pdf
>
> (Repository location:  https://ssl.trustwave.com/CA /
> https://certs.securetrust.com/CA/)
>
> *SecureTrust’s BR Self Assessment* is located here:
> https://bugzilla.mozilla.org/attachment.cgi?id=9060769
>
> *Audits:*  Annual audits are performed by BDO International, Ltd.
> according to the WebTrust Standard, BR and EV audit criteria.  I have
> reviewed the key generation audit report from Grant Thornton and subsequent
> 2018 and 2019 audit reports for these three roots and determined that there
> is continuity (all three are included in WebTrust Standard, BR and EV
> audits continuously since CA generation). Minor issues were found by BDO
> International, Ltd., as part of the 2019 Baseline Requirements audit.[1]
> These issues were addressed in [2], which was closed by Mozilla on
> 14-Mar-2020.
>
> [1]
> https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1606031  (BR Audit 2019
> - matters to be resolved)
>
>
> I ran mis-issuance reports for the three roots with linting to look for
> issuance errors and didn’t find any from the three above-mentioned roots.
>
>
>
> Other closed CA Incidents for SecureTrust include the following:
>
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1546776  (Unvalidated
> domain in certificate )
>
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374  ("Some-State"
> in stateOrProvinceName)
>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1600844 (Unconstrained
> ICA not included in WTBR audit report)
>
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1646711 (Metadata-only
> field values in 2 certificates)
>
>
> This email begins the three-week public discussion period, which will
> close on 24-August-2020.
>
> 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: Verifying Auditor Qualifications

[Ben Wilson via dev-security-policy]

In a draft template for audit attestations, provided by the ACAB'c, the
template would provide a URL to the NAB's certification of the CAB with a
statement that the NAB had certified the CAB to perform "certification of
trust services according to 'EN ISO/IEC 17065:2012' and 'ETSI EN 319 403
V2.2.2 (2015-08)' " but with a note that the CAB could update the template
based on actual certifications received from the NAB. This raises the
question of whether NABs typically include ETSI EN 319 401, ETSI EN 319
411-1 and ETSI EN 319 411-2 in such CAB certification records. If not,
maybe references to EN ISO/IEC 17065:2012 and ETSI EN 319 403 V2.2.2
(2015-08) would then need to be sufficient. That is something that would be
good to know.

Thanks, Kathleen

On Wed, Aug 26, 2020 at 12:54 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 6/3/20 4:20 PM, Kathleen Wilson wrote:
> > It recently came to my attention that I need to be more diligent in
> > verifying auditor qualifications.
> > 
> > https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications
>
> All,
>
> While re-verifying auditor qualifications I have run into the following
> situation, that I will appreciate your opinions on.
>
>
> https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check
>
>  >> Check 1:  The NAB is listed as “full member” under
>
> https://european-accreditation.org/ea-members/directory-of-ea-members-and-mla-signatories/
>
> The NAB, Accredia (https://www.accredia.it/) is listed as a "Full Member".
>
>
>  >> Check 2:  The accreditation documentation was issued by that NAB and
> is hosted on the NAB's website
>
> The accreditation documentation on the NAB's website for a few CABs:
>
> QMSCERT:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=3761
>
> Bureau Veritas Italia:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=0663
>
> CSQA:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=0010
>
>
>  >> Check 3: The CABs accreditation documentation explicitly refers to
> all of the following:  411-1, and ETSI EN 319 411-2>
>
> This is where I'm running into difficulty. The NAB's accreditation
> documentation does not explicitly state that the CAB is certified to
> audit against those ETSI EN standards.
>
> For each of the CABs listed above, an Allegato (for UNI CEI EN/ISO/IEC
> 17065:2012) can be downloaded that says: "TSP (Trust Service Provider)
> and the services they offer compared with (EU Regulation) 910/2014 and /
> or specific provisions adopted by the national authorities for the
> services covered by the Accreditation Scheme."
>
> Which apparently refers to the the following documents that list the
> ETSI EN standards:
> Italian:
>
> https://www.accredia.it/app/uploads/2020/03/Circolare_tecnica_DC_05-2020.pdf
> English:
> https://www.accredia.it/app/uploads/2017/03/7015_DC2017SSV046eng.pdf
>
> https://www.accredia.it/documento/circolare-dc-n-82017-informativa-in-merito-allaccreditamento-degli-organismi-di-certificazione-operanti-a-fronte-dei-requisiti-del-regolamento-ue-2014_910-eidas-e-della-norma-etsi-en-319_4/
>
>
> Is that sufficient evidence that the CAB is certified by the NAB to
> audit according to the ETSI EN 319 403, ETSI EN 319 401, ETSI EN 319
> 411-1, and ETSI EN 319 411-2 standards?
>
> 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

Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Below is a list of issues that I propose be addressed in the next version
(2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
issues related to the MRSP listed here:
https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13
items to consider for this policy update; which are tagged as v.2.7.1 in
GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
appreciate your input on this list as to whether there are issues that
should be added or removed. Then, based on the list, I will start a
separate discussion thread in mozilla.dev.security.policy for each issue.

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153.

#147  - 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.

#153  – 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.
Related to Issue #139.

#154  - Require Management
Assertions to list Non-compliance – Add to MRSP 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.”

#173  - Strengthen
requirement for newly included roots to meet all past and present
requirements – Add language to MRSP 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.

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

#187  - Require disclosure
of incidents in Audit Reports –  To MRSP 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) that occurred or were still open/unresolved at any time during
the audit period, or a statement that the auditor is unaware of any;”

#192  - Require
information about auditor qualifications in the audit report – Require
audit statements to be accompanied by documentation of the auditor’s
qualifications demonstrating the auditor’s competence and experience.

#205  - Require CAs to
publish accepted methods for proving key compromise – Require CAs to
disclose their acceptable methods for proving key compromise in section
4.9.12 of their CPS.

#206  - Limit re-use of
domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
verify ownership/control of each dNSName and iPAddress in the certificate's
subjectAltName at intervals of 398 days or less;”

#207  - Require audit
statements to provide information about which CA Locations were and were
not audited, and the extent to which they were (or were not) audited

#211  - Align OCSP
requirements in Mozilla's policy with the section 4.9.10 of the Baseline
Requirements
#218  Clarify CRL
requirements for End Entity Certificates – For CRLite, Mozilla would like
to ensure that it has full lists of revoked certificates. If the CA uses
partial CRLs, then require CAs to provide the URL location of their full
and complete CRL in the CCADB.

Ben Wilson
Mozilla Root Program Manager
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Sectigo to Be Acquired by GI Partners

[Ben Wilson via dev-security-policy]

 As announced previously by Rob Stradling, there is an agreement for
private investment firm GI Partners, out of San Francisco, CA, to acquire
Sectigo. Press release:
https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners.


I am treating this as a change of legal ownership covered by section 8.1

of the Mozilla Root Store Policy, which states:

> If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root
program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program.

In order to comply with policy, I hereby formally announce the commencement
of a 3-week discussion period for this change in legal ownership of Sectigo
by requesting thoughtful and constructive feedback from the community.

Sectigo has already stated that it foresees no effect on its operations due
to this ownership change, and I believe that the acquisition announced by
Sectigo and GI Partners is compliant with Mozilla policy.

Thanks,

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

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Doug,
I don't have any preconceived notions. I was hoping that by discussing the
implementation issues for each issue we could determine appropriate
timeframes.
Ben

On Tue, Oct 6, 2020 at 12:19 PM Doug Beattie 
wrote:

> Ben,
>
> When, approximately, do you think this proposed updates would become
> effective, and specifically this item:
>
>https://github.com/mozilla/pkipolicy/issues/206
>
> Doug
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, October 1, 2020 4:22 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.7.1 Issues to be Considered
>
> Below is a list of issues that I propose be addressed in the next version
> (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
> issues related to the MRSP listed here:
> https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13
> items to consider for this policy update; which are tagged as v.2.7.1 in
> GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139 <https://github.com/mozilla/pkipolicy/issues/139> - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #147 <https://github.com/mozilla/pkipolicy/issues/147> - 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.
>
> #153 <https://github.com/mozilla/pkipolicy/issues/153> – 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.
> Related to Issue #139.
>
> #154 <https://github.com/mozilla/pkipolicy/issues/154> - Require
> Management Assertions to list Non-compliance – Add to MRSP 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.”
>
> #173 <https://github.com/mozilla/pkipolicy/issues/173> - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 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.
>
> #186 <https://github.com/mozilla/pkipolicy/issues/186> - Clarify MRSP 5.3
> Requirement to Disclose Self-signed Certificates – Clarify that self-signed
> certificates with the same key pair as an existing root meets MRSP 5.3’s
> definition of an intermediate certificate that must be disclosed in the
> CCADB.
>
> #187 <https://github.com/mozilla/pkipolicy/issues/187> - Require
> disclosure of incidents in Audit Reports –  To MRSP 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) that occurred or were still open/unresolved at
> any time during the audit period, or a statement that the auditor is
> unaware of any;”
>
> #192 <https://github.com/mozilla/pkipolicy/issues/192> - Require
> information about auditor qualifications in the audit report – Require
> audit statements to be accompanied by documentation of the auditor’s
> qualifications demonstrating the auditor’s competence and experience.
>
> #205 <https://github.com/mozilla/pkipolicy/issues/205> - Require CAs to
> publish accepted methods for proving key compromise – Require CAs to
> disclose their acceptable methods for proving key compromise in section
> 4.9.12 of their CPS.
>
> #206 <https://github.com/mozilla/pkipolicy/issues/206> - Limit re-use of
> domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
> verify ownership/control of each dNSName and iPAddress in the certificate's
> subjectAltName at intervals of 398 days or less;”
>
> #207 <https://github.com/mozilla/pkipolicy/issues/207> - Require audit
> statements to provide information about which CA Locations were and were
> not audited, and the extent to which they were (or were not) audited
>
> #211 <https://github.com/mozilla/pkipolicy/issues

MRSP Issue #139: Audits required even if not issuing

[Ben Wilson via dev-security-policy]

 Here is the first issue for discussion here on the m.d.s.p. list relative
to the next version of the Mozilla Root Store Policy (v.2.7.1).

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153
.

Seven (7) comments are listed so far for this issue in GitHub, including
discussion re: whether auditors can provide reports when a CA isn't being
used to issue certificates.

I made an initial attempt to address this with some language in line 272 in
the following commit in my GitHub repository -
https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
(related changes also appear below in that commit).

The suggested language would amend the first paragraph of section 3.1.3 of
the MRSP to read, "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. Successive
period-of-time audits MUST be contiguous (no gaps)."

We will need to discuss scope and timing for implementing this requirement.

Thanks in advance for your contributions and suggestions.

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

MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

 #147  - 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.

This issue is presented for resolution in the next version of the Mozilla
Root Store Policy.

Suggested language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b


The proposal is to replace "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Corey,
We will add this to the 2.7.1 batch of proposed changes. I've started
discussion of Issue 147, so we can discuss it there, or I can create a
separate email thread for it.

On Fri, Oct 2, 2020 at 5:16 AM Corey Bonnell  wrote:

> Including https://github.com/mozilla/pkipolicy/issues/152 would be a
> useful clarification alongside issue 147, as it will better define the
> parameters that determine if a given intermediate is “EV capable”.
>
> Thanks,
> Corey
> --
> *From:* dev-security-policy 
> on behalf of Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> *Sent:* Thursday, October 1, 2020 4:21:48 PM
> *To:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Policy 2.7.1 Issues to be Considered
>
> Below is a list of issues that I propose be addressed in the next version
> (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
> issues related to the MRSP listed here:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=GZ8%2F%2FJg0sa%2FKAPcRes4w1tWPtQrXfd3xAdjoEY62gBQ%3D&reserved=0.
> So far, I have identified 13
> items to consider for this policy update; which are tagged as v.2.7.1 in
> GitHub (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Flabels%2F2.7.1&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=fNzV%2FEjnNTWKsA%2BNMJo08ESzNttlkIHINUr23jRy%2F5E%3D&reserved=0).
> I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F139&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=7xarPFNWPfgfEcddgA%2BsVk23dViiNv9QRxpEoqjp1vk%3D&reserved=0>
> - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #147 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F147&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=kt7ywgVE5S6VqWB47cNsTf943OyNzdtSEbqA14%2F4TYo%3D&reserved=0>
> - 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.
>
> #153 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F153&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=FToJiGI1xtCsEBHmmRsB2P%2Fv%2B8SFqze5HouMkmsJ8lc%3D&reserved=0>
> – 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.
> Related to Issue #139.
>
> #154 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F154&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=qEnD7LC%2FXsEF3Hs7u68fxA4fNAPFaP7rGLox7GvIjn4%3D&reserved=0>
> - Require Management
> Assertions to list Non-compliance – Add to MRSP 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.”
>
> #173 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F173&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=THxcETFV6slWGx4h3Y9E9l4OVcRvCf43iPjtoqqpIzc%3D&reserved=0>
> - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 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 Requir

NAVER: Public Discussion of 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,
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9). Mozilla is considering approval of NAVER Business Platform
Corp.’s request to include the NAVER Global Root Certification Authority as
a trust anchor with the websites trust bit enabled, as documented in the
following Bugzilla case:
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
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 the CCADB:*

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

*NAVER Global Root Certification Authority, *valid from 8/18/2017 to
8/18/2037

SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265

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

*Root Certificate Download:*

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt


*CP/CPS:*

Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
through 42 in Bugzilla contain discussion concerning the CPS and revisions
thereto.

Current CPS is version 1.4.3:

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf

Repository location:  https://certificate.naver.com/bbs/initCrtfcJob.do

*BR Self Assessment* (Excel file) is located here:

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

*Audits:*  Annual audits are performed by Deloitte according to the
WebTrust Standard and WebTrust Baseline Requirements audit criteria. See
webtrust.org. The last complete audit period for NAVER was from 1 December
2018 to 30 November 2019 and no issues were found. However, the audit
report was dated 28 April 2020, which was more than three months following
the end of the audit period. The explanation for the delay in obtaining the
audit report was as follows, “NBP had received a notification mail on
updating the audit information from CCADB support in March since the Root
certificate is only included into Microsoft Root Program. According to
instructions on the email, I explained that NBP would submit the audit
update information in April to Microsoft.”  The current audit period ends
30 November 2020.

*Mis-Issuances *

According to crt.sh and censys.io, the issuing CA under this root
(NAVER Secure Certification Authority 1) has issued approximately 80
certificates. I ran the following query for the issuing CA to identify any
mis-issuances:
https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-08-18,
and during the course of our review, we identified six test certificates
with errors. (Such certificates have either been revoked or have expired).
See:

https://crt.sh/?id=2132664529&opt=cablint,zlint,x509lint

https://crt.sh/?id=2102184572&opt=cablint,zlint,x509lint

https://crt.sh/?id=1478365347&opt=cablint,zlint,x509lint

https://crt.sh/?id=2149282089&opt=cablint,zlint,x509lint

https://crt.sh/?id=2149282369&opt=cablint,zlint,x509lint

https://crt.sh/?id=2282123486&opt=cablint,zlint,x509lint

The explanation provided (
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was “Regarding
CA/B Forum and X.509 lint tests NBP figured out two(2) certificates which
were not complied with BRs right after issuing them. The domains on SANs of
the certificates were owned and controlled by NBP. They were immediately
revoked according to CA procedures. For ZLint tests, the certificate (CN=
test2-certificate.naver.com) had been issued and became expired in
compliance with CA Browser Forum BRs and RFC 5280. I understand there is a
specific Mozilla policy on Authority Key IDs. NBP already fixed the system
functions. There is no such valid certificate and NBP CA currently issues
certificates fully complied with the Mozilla policy. You can see the new
certificate (CN= test2-certificate.naver.com) was issued without any error
at https://crt.sh/?id=2824319278.”

I have no further questions or concerns at this time, however I urge anyone
with concerns or questions to raise them by replying to this list under the
subject heading above.

Again, this email begins a three-week public discussion period, which I’m
scheduling to close on Monday, 2-November-2020.

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

Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

 This issue is presented for resolution in the next version of the Mozilla
Root Store Policy. It is related to Issue #147
 (previously posted for
discussion on this list on 6-Oct-2020).

Possible language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4

In addition to replacing "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits --
it would be followed by "(i.e. a subordinate CA under an EV-enabled root
that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage
EKU, and a certificatePolicies extension that asserts the CABF EV OID of
2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus, Mozilla
considers that a CA is capable of issuing EV certificates if it is (1) a
subordinate CA (2) under an EV-enabled root (3) that contains no EKU or the
id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a
certificatePolicies extension that asserts the CABF EV OID of 2.23.140.1.1,
the anyPolicy OID, or the CA's EV policy OID.

I look forward to your suggestions.

Thanks,

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

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

[Ben Wilson via dev-security-policy]

This issue #153, listed here:
https://github.com/mozilla/pkipolicy/issues/153, is proposed for resolution
with version 2.7.1 of the Mozilla Root Store Policy. It is related to Issue
139  (audits required even
if not issuing).

The first paragraph of section 3.1.3 of the MRSP would read:

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. Successive period-of-time audits MUST be
contiguous (no gaps).
Item 5 in the fifth paragraph of section 7.1 of the MRSP (new root
inclusions) would read:

5. an auditor-witnessed root key generation ceremony report and contiguous
period-of-time audit reports performed thereafter no less frequently than
annually;

The proposed language can be examined further in the following commits:

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

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

Or here:
https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/policy.md

Thanks in advance for your comments,

Ben
___
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 #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

 Ryan wrote:

> If we apply this concept to the proposed language, then the requirement
for an EV audit is
> simply about whether there is any unexpired, unrevoked path to a root CA
which can issue
> EV certificates. Similarly, checking the scope for an EV audit becomes
“the entire hierarchy”.

> This is accomplished by simply removing your proposed “(i.e. ...)”
parenthetical, and allowing
> the language from 3.1 to apply, by changing the language to “if the root
is recognized for
> issuing EV certificates”.

I think it might need to be phased in or have some effective date. Also, I
haven't mapped out how this might affect CAs that we sometimes add to the
root store without EV enablement and with the suggestion that they apply
later for it.

On Sat, Oct 17, 2020 at 12:26 AM Ryan Sleevi  wrote:

>
>
> On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>  This issue is presented for resolution in the next version of the Mozilla
>> Root Store Policy. It is related to Issue #147
>> <https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
>> discussion on this list on 6-Oct-2020).
>>
>> Possible language is presented here:
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
>>
>> In addition to replacing "if issuing EV certificates" with "if capable of
>> issuing EV certificates" in two places -- for WebTrust and ETSI audits --
>> it would be followed by "(i.e. a subordinate CA under an EV-enabled root
>> that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage
>> EKU, and a certificatePolicies extension that asserts the CABF EV OID of
>> 2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus,
>> Mozilla
>> considers that a CA is capable of issuing EV certificates if it is (1) a
>> subordinate CA (2) under an EV-enabled root (3) that contains no EKU or
>> the
>> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a
>> certificatePolicies extension that asserts the CABF EV OID of
>> 2.23.140.1.1,
>> the anyPolicy OID, or the CA's EV policy OID.
>>
>> I look forward to your suggestions.
>
>
> Given the continuing issues we see with respect to audits, it seems like
> this notion of “technically constrained (from issuing EV) sub-CA” is going
> to encounter many of the same fundamental issues we’ve seen with audit
> scopes being incorrect and improper.
>
> It seems the easiest, and best (for users) way, is to ensure that once a
> root is trusted for a given purpose, as much as possible it’s ensured that
> *all* CA certificates beneath that hierarchy are included within the scope
> of the audit.
>
> It’s already well-accepted that, for example, the expectations of the BR
> audits still apply even if a CA has not issued, whether that “not issued”
> was because it has never issued a very (e.g. just created and not used
> yet), whether it is no longer issuing certs (e.g. it is being retired),
> *and* for situations where the key had previously issued certs, but did not
> issue certs within the audit period (e.g. a pause, rather than simply not
> being used yet).
>
> For separate purposes (e.g. S/MIME vs TLS), we know there are practical
> reasons to ensure separate hierarchies; most pragmatic of them being the
> creation of certificates for one purpose that impact the trustworthiness of
> certificates for another purpose (e.g. S/MIME certs, both those technically
> separated and those merely “intended” for S/MIME, impacting TLS trust, such
> as we saw with the recent OCSP issue).
>
> Because of this, it seems that there is a simpler, clearer, unambiguous
> path for CAs that seems useful to move to:
> - If a CA is trusted for purpose X, that certificate, and all subordinate
> CAs, should be audited against the criteria relevant for X
>
> This would avoid much of the confusion CAs seemingly continue to encounter
> with respect to audit scope, disclosure, and intent, by making it as simple
> as “If you signed it, you audit it.”
>
> If we apply this concept to the proposed language, then the requirement
> for an EV audit is simply about whether there is any unexpired, unrevoked
> path to a root CA which can issue EV certificates. Similarly, checking the
> scope for an EV audit becomes “the entire hierarchy”.
>
> This is accomplished by simply removing your proposed “(i.e. ...)”
> parenthetical, and allowing the language from 3.1 to apply, by changing the
> language to “if the root is recognized for issuing EV certificates”.
>
> From an audit ingestion point, and for CAs, it becomes easie

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Here is NAVER's response which I am forwarding from them:

Here is NAVER Business Platform's response to the comment:
-
Hello, I am Sooyoung at NAVER Business Platform.
As George mentioned, all the certificates, with both of city and province
names in stateOrProvinceName field, were issued to NAVER Business Platform
(NBP) for test domains. The addresses were verified correctly when issuing
them. NBP reflected George’s comment and has fixed the DN structure. You
can directly check the issued certificate including the new DN (L is
"Seongnam-si" as city name and S field is "Gyeonggi-do" as province name)
as below.
https://crt.sh/?id=3510606493
NBP also added additional verification process, in compliance with ISO
3166-2, in order to put province information correctly in S field of user
DN for newly issued certificates.
-
Best Regards,
Sooyoung Eo

On Fri, Oct 9, 2020 at 4:30 PM George  wrote:

> Minor but it seems like all certificates with a stateOrProvinceName field
> are misissued. The ST field should probably be the "Gyeonggi-do" as the
> "Seongnam-si" entered is a city.
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Dear All,
> >
> > This is to announce the beginning of the public discussion phase of the
> > Mozilla root CA inclusion process,
> > https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4
> > through 9). Mozilla is considering approval of NAVER Business Platform
> > Corp.’s request to include the NAVER Global Root Certification Authority
> as
> > a trust anchor with the websites trust bit enabled, as documented in the
> > following Bugzilla case:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate
> a
> > 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 the CCADB:
> >
> >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
> >
> > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to
> > 8/18/2037
> >
> > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
> >
> > https://crt.sh/?id=1321953839
> >
> > Root Certificate Download:
> >
> >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt
> >
> > CP/CPS:
> >
> > Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> > through 42 in Bugzilla contain discussion concerning the CPS and
> revisions
> > thereto.
> >
> > Current CPS is version 1.4.3:
> >
> >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP
> Certification Practice Statement v1.4.3.pdf
> >
> > Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do
> >
> > BR Self Assessment (Excel file) is located here:
> >
> > https://bugzilla.mozilla.org/attachment.cgi?id=9063955
> >
> > Audits: Annual audits are performed by Deloitte according to the
> > WebTrust Standard and WebTrust Baseline Requirements audit criteria. See
> > webtrust.org. The last complete audit period for NAVER was from 1
> December
> > 2018 to 30 November 2019 and no issues were found. However, the audit
> > report was dated 28 April 2020, which was more than three months
> following
> > the end of the audit period. The explanation for the delay in obtaining
> the
> > audit report was as follows, “NBP had received a notification mail on
> > updating the audit information from CCADB support in March since the Root
> > certificate is only included into Microsoft Root Program. According to
> > instructions on the email, I explained that NBP would submit the audit
> > update information in April to Microsoft.” The current audit period ends
> > 30 November 2020.
> >
> > *Mis-Issuances *
> >
> > According to crt.sh and censys.io, the issuing CA under this root
> > (NAVER Secure Certification Authority 1) has issued approximately 80
> > certificates. I ran the following query for the issuing CA to identify
> any
> > mis-issuances:
> >
> https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-08-1

Policy 2.7.1: MRSP Issue #154: Require Management Assertions to list Non-compliance

[Ben Wilson via dev-security-policy]

The purpose of this email is to begin public discussion on an addition to
section 2.4 of the Mozilla Root Store Policy. Issue #154
 in GitHub proposes to
require that management assertions (CA disclosures to auditors) provide
written mention of all incidents occurring (or open) during the audit
period.

Initial draft language can be found here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/bc669d03ba3fb7cb48dc4492d4e8dd52bfd9a943
and here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5dec00e53b4c6361d85af7644660fe185fcf463d


This issue is a companion to Issue 187
 (Consider requiring audit
reports to list all incidents that occurred during the audit period or
clearly state that the auditor is not aware of any)

Please provide your comments and suggestions in response to this email.

Thanks,

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

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

[Ben Wilson via dev-security-policy]

 The purpose of this email is to begin public discussion on the addition of
a subsection 11 to section 3.1.4 of the Mozilla Root Store Policy. Issue
#187  in GitHub proposes
to require audit reports to list all incidents occurring (or open) during
the audit period of which the auditor has been made aware or to state that
the auditor is unaware of any incidents.  This is related to Issue #154
 (management assertion
disclosures).  That proposal is to have section 2.4 read as follows:  "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."

Proposed language may be found in the following commits:

   -
   
https://github.com/BenWilson-Mozilla/pkipolicy/commit/f6639f503b743aae402dc0f4841dc3dd5ba88753
   -
   
https://github.com/BenWilson-Mozilla/pkipolicy/commit/6c07c44e4db473dc4d34009f1bc955a0e18cb4c1
   -
   
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5dec00e53b4c6361d85af7644660fe185fcf463d

Proposed language for section 3.1.4 is:

"11.  all incidents (as defined in section 2.4) that occurred or were still
open/unresolved at any time during the audit period, or a statement that
the auditor is unaware of any;"

I look forward to your comments, suggestions and discussions.

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

Policy 2.7.1: MRSP Issue #173: Strengthen requirement for newly included roots to meet all current requirements

[Ben Wilson via dev-security-policy]

 The current language of MRSP section 7.1 says, "Before being included, CAs
MUST provide evidence that their CA certificates have continually, from the
time of creation, complied with the then-current Mozilla Root Store Policy
and Baseline Requirements." If an older root were to be submitted for
inclusion that does not meet current requirements, there might be an
argument that the certificate met the "then-current" requirements even
though it does not meet the current requirements. The purpose of this
proposed revision to section 7.1 of the MRSP is to close this potential
loophole.

The proposed language would amend the 4th paragraph of section 7.1 to read,
"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.

This email begins public discussion of this proposal for inclusion in
version 2.7.1 of the MRSP.

Thanks,

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

Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Issue #186 in Github 
deals with the disclosure of CA certificates that directly or transitively
chain up to an already-trusted, Mozilla-included root. A common scenario
for the situation discussed in Issue #186 is when a CA creates a second (or
third or fourth) root certificate with the same key pair as the root that
is already in the Mozilla Root Store. This problem exists at the
intermediate-CA-certificate level, too, where a self-signed
intermediate/subordinate CA certificate is created and not reported.

Public disclosure of such certificates is already required by section 5.3
of the MRSP, which reads, "All certificates that are capable of being used
to issue new certificates, and which directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program, MUST be operated
in accordance with this policy and MUST either be technically constrained
or be publicly disclosed and audited."

There have been several instances where a CA operator has not disclosed a
CA certificate under the erroneous belief that because it is self-signed it
cannot be trusted in a certificate chain beneath the already-trusted,
Mozilla-included CA. This erroneous assumption is further discussed in Issue
#186 .

The third paragraph of MRSP section 5.3 currently reads, " These
requirements include all cross-certificates which chain to a certificate
that is included in Mozilla’s CA Certificate Program."

I recommend that we change that paragraph to read as follows:

"These requirements include all cross-certificates *and self-signed
certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
is signed by the private key) that* chain to a CA certificate that is
included in Mozilla’s CA Certificate Program*, and CAs must disclose such
CA certificates in the CCADB*.

I welcome your recommendations on how we can make this language even more
clear.

Thanks,

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

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

The 3-week public discussion was to close on Monday, but I'd like Naver to
provide any further final comments and give anyone else an opportunity to
comment through this Thursday, and then I will proceed with Steps 6-10
(summarize matters, note any remaining items, and make a last call for
objections).

On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:
> > Minor but it seems like all certificates with a stateOrProvinceName
> field are misissued. The ST field should probably be the "Gyeonggi-do" as
> the "Seongnam-si" entered is a city.
> >
> >
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐
> > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > > Dear All,
> > >
> > > This is to announce the beginning of the public discussion phase of
> the
> > > Mozilla root CA inclusion process,
> > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4
> > > through 9). Mozilla is considering approval of NAVER Business Platform
> > > Corp.’s request to include the NAVER Global Root Certification
> Authority as
> > > a trust anchor with the websites trust bit enabled, as documented in
> the
> > > following Bugzilla case:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby
> initiate a
> > > 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 the
> CCADB:
> > >
> > >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
> > >
> > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to
> > > 8/18/2037
> > >
> > > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
> > >
> > > https://crt.sh/?id=1321953839
> > >
> > > Root Certificate Download:
> > >
> > >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt
> > >
> > > CP/CPS:
> > >
> > > Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
>
> > > through 42 in Bugzilla contain discussion concerning the CPS and
> revisions
> > > thereto.
> > >
> > > Current CPS is version 1.4.3:
> > >
> > >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf&atch_real_file_nm=NBP
> Certification Practice Statement v1.4.3.pdf
> > >
> > > Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do
> > >
> > > BR Self Assessment (Excel file) is located here:
> > >
> > > https://bugzilla.mozilla.org/attachment.cgi?id=9063955
> > >
> > > Audits: Annual audits are performed by Deloitte according to the
> > > WebTrust Standard and WebTrust Baseline Requirements audit criteria.
> See
> > > webtrust.org. The last complete audit period for NAVER was from 1
> December
> > > 2018 to 30 November 2019 and no issues were found. However, the audit
> > > report was dated 28 April 2020, which was more than three months
> following
> > > the end of the audit period. The explanation for the delay in
> obtaining the
> > > audit report was as follows, “NBP had received a notification mail on
> > > updating the audit information from CCADB support in March since the
> Root
> > > certificate is only included into Microsoft Root Program. According to
> > > instructions on the email, I explained that NBP would submit the audit
> > > update information in April to Microsoft.” The current audit period
> ends
> > > 30 November 2020.
> > >
> > > *Mis-Issuances *
> > >
> > > According to crt.sh and censys.io, the issuing CA under this root
> > > (NAVER Secure Certification Authority 1) has issued approximately 80
> > > certificates. I ran the following query for the issuing CA to identify
> any
> > > mis-issuances:
> > >
> https://crt.sh/?caid=126361&opt=cablint,zlint,x509lint&minNotBefore=2017-08-18,
>
> > > and during the course of our review, we identified six test
> certificates
> > &

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

[Ben Wilson via dev-security-policy]

Historically, Mozilla Policy required that CAs "provide attestation of
their conformance to the stated verification requirements and other
operational criteria by a competent independent party or parties with
access to details of the CA's internal operations."
https://wiki.mozilla.org/CA:CertificatePolicyV1.0  "Competency" was "for
whom there is sufficient public information available to determine that the
party is competent to judge the CA's conformance to the stated criteria. In
the latter case the 'public information' referred to should include
information regarding the party's:

   - knowledge of CA-related technical issues such as public key
   cryptography and related standards;
   - experience in performing security-related audits, evaluations, or risk
   analyses; *and*
   - honesty and objectivity."

Today, section 3.2 of the MRSP

states, "In normal circumstances, Mozilla requires that audits MUST be
performed by a Qualified Auditor, as defined in the Baseline Requirements
section 8.2," but under section 2.3
,
"Mozilla reserves the right to accept audits by auditors who do not meet
the qualifications given in section 8.2 of the Baseline Requirements, or
refuse audits from auditors who do."

Section 8.2 of the Baseline Requirements states an auditor must have:
1. Independence from the subject of the audit;
2. The ability to conduct an audit that addresses the criteria specified in
an Eligible Audit Scheme (see Section 8.1);
3. Employs individuals who have proficiency in examining Public Key
Infrastructure technology, information security tools and techniques,
information technology and security auditing, and the third-party
attestation function;
4. (For audits conducted in accordance with any one of the ETSI standards)
accredited in accordance with ISO 17065 applying the requirements specified
in ETSI EN 319 403;
5. (For audits conducted in accordance with the WebTrust standard) licensed
by WebTrust;
6. Bound by law, government regulation, or professional code of ethics; and
7. Except in the case of an Internal Government Auditing Agency, maintains
Professional Liability/Errors & Omissions insurance with policy limits of
at least one million US dollars in coverage

It is proposed in Issue #192
 that information about
individual auditor's qualifications be provided--identity, competence,
experience and independence. (For those interested as to this independence
requirement, Mozilla Policy v.1.0 required either disclosure of the
auditor's compensation or the establishment that the auditor "is bound by
law, government regulation, and/or a professional code of ethics to render
an honest and objective judgement regarding the CA.")

While subsection 3 of BR 8.2 requires "individuals who have proficiency in
examining Public Key Infrastructure technology, information security tools
and techniques, information technology and security auditing, and the
third-party attestation function," that fact needs evidence in order to be
established. The proposed resolution of this Issue #192 intends to
accomplish that.

This proposal to require disclosure of individual auditor qualifications is
very similar to the approach adopted by the U.S. Federal PKI

(see Appendices B-1 and C). E.g., "Did each Audit Opinion Letter identify
the auditor and the individuals performing the audit?"  In practice, the
information about auditor qualifications could be in the form of a separate
document, such as a curriculum vitae.

Some initial, draft language to address this issue is located here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/d0da7cb2b6db38e66c3a72e5c1db0e78e91d8df6

A new subsection 3. would be added to the list of audit requirements that
would require "[the] name(s) and qualifications of individuals performing
the audit, as required by section 3.2" and a new paragrpah would be added
to section 3.2 that would say, "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. Audit documentation of individual auditor
qualifications MUST be provided to Mozilla that is sufficient for Mozilla
to determine the competence, experience, and independence of the Qualified
Auditor. Mozilla will review each individual auditor’s credentials and
ensure that any Qualified Auditor has the collective set of skills required
by section 8.2 of the Baseline Requirements."

Please provide your comments and suggestions in response to this email.

Thanks,

Ben
___
dev-security-policy ma

Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Ben Wilson via dev-security-policy]

This email begins discussion of a potential change to section 6 of the
Mozilla Root Store Policy
.


The method by which a person may provide a CA with proof of private key
compromise has been an issue discussed on the mdsp list

this past year.

According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements
, key compromise is
one reason for certificate revocation within a 24-hour period, and section
4.9.3 of the Baseline Requirements requires that CAs provide "clear
instructions for reporting suspected Private Key Compromise ..." and that
they "publicly disclose the instructions through a readily accessible
online means and in section 1.5.2 of their CPS."  However, in many of the
CPSes reviewed by Mozilla, the only information appearing is a contact
person's street address, email address, and sometimes a telephone number.
Seldom is this information provided in the context of revocation for key
compromise, and in many situations, email is an inadequate method of
communicating key compromises, especially at scale. Some CAs have portals
(e.g. DigiCert 
and Sectigo ) in
addition to an email address to submit revocation requests. There is also
an open-source ACME server which is designed for the sole purpose of
receiving revocations: https://github.com/tobermorytech/acmevoke.

Github Issue #205  notes
that the best place for disclosure of such revocation methods would be in
section 4.9.12 of a CA's CPS. Section 4.9.12 of the RFC 3647 outline
 is titled "Special
requirements re key compromise". Not only will this requirement make it
easier for the Mozilla community to report key compromises, but it will
also help streamline key-compromise-based revocations, thereby reducing the
number of Bugzilla incidents filed for delayed revocation.

Draft language in
https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4
proposes to add a last sentence to section 6 of the MRSP reading "Section
4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may
use to demonstrate private key compromise."

We recognize that there is some overlap with the BR 4.9.3 requirement that
certain instructions be provided in section 1.5.2 of the CPS, but we
believe that the overlap can be worked through during this discussion and,
if not, a related discussion within the CA/Browser Forum.

We look forward to your comments and suggestions on this issue.

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: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

Hi Dimitris,

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store


On Mon, Nov 9, 2020 at 2:45 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
>
> On 7/11/2020 3:12 μ.μ., Ryan Sleevi wrote:
> >
> >
> > On Sat, Nov 7, 2020 at 4:52 AM Dimitris Zacharopoulos
> > mailto:ji...@it.auth.gr>> wrote:
> >
> >
> > I will try to further explain my thoughts on this. As we all know,
> > according to Mozilla Policy "CAs MUST follow and be aware of
> > discussions in the mozilla.dev.security.policy
> >  forum,
> > where Mozilla's root program is coordinated". I believe Mozilla
> > Root store managers' minimum expectations from CAs are to _read
> > the messages and understand the content of those messages_. Right
> > now, we have [1], [2], [3], [4], [5], [6], [7], [8], [9]
> > policy-related threads opened up for discussion since October 15th.
> >
> > If every post in these threads contained as much information and
> > complexity as your recent reply to Clemens,
> >
> >
> > This seems like a strawman argument,  ht I don’t think it’s intentional.
> >
> > You’re arguing that “if things were like this hypothetical situation,
> > that would be bad”. However, they aren’t like that situation, as the
> > evidence you provided shows. This also goes back to the “what is your
> > desired outcome from your previous mail”, and trying to work out what
> > a clear call to action to address your concerns. Your previous
> > message, especially in the context of your (hypothetical) concern,
> > reads like you’re suggesting “Mozilla shouldn’t discuss policy changes
> > with the community”. I think we’re all sensitive and aware of the
> > desire not to have too many parallels discussions, which is exactly
> > why Ben’s been only introducing a few points a week, to facilitate
> > that and make progress without overwhelming.
>
> To the contrary, I want more people to be able to participate in these
> discussions, which is precisely why I "complained" about the size of
> your response to Clemens :-) Keeping our replies to reasonable levels,
> with a mindset that this is an International Internet community and
> people might be interested to participate (even auditors that are not
> native-English speakers), I believe is a good thing.
>
> I also see that Ben has introduced a lot of policy proposal topics for
> discussion in a short period of time, but I don't know what the
> expectations about their "discussion time" are. Should anyone just pick
> any topic and start a discussion? That might introduce a lot of parallel
> discussions and I'm not sure if this is desirable by Ben. Perhaps we
> need some coordination on these topics, for example "please send
> feedback for topics 1 and 2 before the end of week X. If no feedback is
> received, we'll deem the proposal accepted", something like that, before
> moving to other topics.
>
> >
> > As it relates to this thread, or any other thread, it seems the first
> > order evaluation for any CA is “Will the policy change”, followed by
> > “What do I need to do to meet the policy?”, both of which are still
> > very early in this discussion. You’re aware of the policy discussion,
> > and you’re aware a decision has not been made yet: isn’t that all you
> > need at this point? Unlike some of the other proposals, which require
> > action by CAs, this is a proposal that largely requires action by
> > auditors, because it touches on the audit framework and scheme. It
> > seems like, in terms of expectations for CAs to participate,
> > discussing this thread with your auditor is the reasonable step, and
> > working with them to engage here.
> >
> > Hopefully that helps. Your “but what if” is easily answered as “but
> > we’re not”, and the “this is a lot, what do I need to do” is simply
> > “talk with your auditor and make sure they’re aware of discussions
> > here”. That seems a very simple, digestible call to action?
> >
>
> It he

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

eir revocation processes, but this language in the NAVER
CPS meets the minimum requirements. Hopefully, NAVER and other CAs will not
only strive to improve their CPS revocation language, but also strive to
revoke certificates quickly when one of the criteria is met.

Are there any final comments or issues that have not been addressed?  If
not, I will be closing public discussion tomorrow [Step 9] and giving
notice that it is Mozilla’s intent to approve NAVER's request for inclusion
[Step 10].

Thanks,

Ben


On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thank you all for the comments during the public discussion phase.
> All matters raised in this public discussion has been fixed and then
> published
> our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14,
> and 9.16.3.
>
> You can find the revised CPS v1.5.0 at our repository.
> https://certificate.naver.com/bbs/initCrtfcJob.do
> (directly download link:
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf
> )
>
> To minimize confusion,  I would like to metion that "NAVER BUSINESS
> PLATFORM"
> has been renamed to "NAVER Cloud" without any changes on the ownership of
> the company and Certification Authority on October 26, 2020.
>
> Kind Regards,
> Sooyoung Eo
>
>
> 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:
> > The 3-week public discussion was to close on Monday, but I'd like Naver
> to
> > provide any further final comments and give anyone else an opportunity
> to
> > comment through this Thursday, and then I will proceed with Steps 6-10
> > (summarize matters, note any remaining items, and make a last call for
> > objections).
> > On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:
> > > > Minor but it seems like all certificates with a stateOrProvinceName
> > > field are misissued. The ST field should probably be the "Gyeonggi-do"
> as
> > > the "Seongnam-si" entered is a city.
> > > >
> > > >
> > > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy
> <
> > > dev-secur...@lists.mozilla.org> wrote:
> > > >
> > > > > Dear All,
> > > > >
> > > > > This is to announce the beginning of the public discussion phase
> of
> > > the
> > > > > Mozilla root CA inclusion process,
> > > > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> > > (Steps 4
> > > > > through 9). Mozilla is considering approval of NAVER Business
> Platform
> > > > > Corp.’s request to include the NAVER Global Root Certification
> > > Authority as
> > > > > a trust anchor with the websites trust bit enabled, as documented
> in
> > > the
> > > > > following Bugzilla case:
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby
> > > initiate a
> > > > > 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 the
> > > CCADB:
> > > > >
> > > > >
> > >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
> > > > >
> > > > > *NAVER Global Root Certification Authority, *valid from 8/18/2017
> to
> > > > > 8/18/2037
> > > > >
> > > > > SHA2:
> 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
> > > > >
> > > > > https://crt.sh/?id=1321953839
> > > > >
> > > > > Root Certificate Download:
> > > > >
> > > > >
> > >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST&atch_file_nm=1c3763b33dbf457d8672371567fd1a12.crt&atch_real_file_nm=naverrca1.crt
> > > > >
> > > > > CP/CPS:
> > > > >
> > > > > Comments 29 (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> > >
&

Policy 2.7.1: Process Overview

[Ben Wilson via dev-security-policy]

 Re-posting this email to start it with its own subject line and to start a
new thread:

There have been questions about the process being followed and the comment
period.  Here is where it now stands.

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

ese
> Requirements and the CA’s Certification Practice Statement”.
>
> A key take-away from a review of these comments and responses is the need
> for each CA’s CPS language to provide a firm commitment to revoke
> certificates on a timely basis. I think members of the Mozilla community do
> not want to have to worry about “when” or “whether” a certificate will be
> revoked. In sections 4.9.1.1 and 4.9.5 of the NAVER CPS, NAVER has adopted
> essentially the 24-hour and 5-day timeframes of sections 4.9.1.1 and 4.9.5
> of the Baseline Requirements. Certainly, all CAs could improve the
> descriptions of their revocation processes, but this language in the NAVER
> CPS meets the minimum requirements. Hopefully, NAVER and other CAs will not
> only strive to improve their CPS revocation language, but also strive to
> revoke certificates quickly when one of the criteria is met.
>
> Are there any final comments or issues that have not been addressed?  If
> not, I will be closing public discussion tomorrow [Step 9] and giving
> notice that it is Mozilla’s intent to approve NAVER's request for
> inclusion [Step 10].
>
> Thanks,
>
> Ben
>
>
> On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Thank you all for the comments during the public discussion phase.
>> All matters raised in this public discussion has been fixed and then
>> published
>> our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14,
>> and 9.16.3.
>>
>> You can find the revised CPS v1.5.0 at our repository.
>> https://certificate.naver.com/bbs/initCrtfcJob.do
>> (directly download link:
>> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY&atch_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf&atch_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf
>> )
>>
>> To minimize confusion,  I would like to metion that "NAVER BUSINESS
>> PLATFORM"
>> has been renamed to "NAVER Cloud" without any changes on the ownership of
>> the company and Certification Authority on October 26, 2020.
>>
>> Kind Regards,
>> Sooyoung Eo
>>
>>
>> 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:
>> > The 3-week public discussion was to close on Monday, but I'd like Naver
>> to
>> > provide any further final comments and give anyone else an opportunity
>> to
>> > comment through this Thursday, and then I will proceed with Steps 6-10
>> > (summarize matters, note any remaining items, and make a last call for
>> > objections).
>> > On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy <
>> > dev-secur...@lists.mozilla.org> wrote:
>> >
>> > > 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:
>> > > > Minor but it seems like all certificates with a stateOrProvinceName
>> > > field are misissued. The ST field should probably be the
>> "Gyeonggi-do" as
>> > > the "Seongnam-si" entered is a city.
>> > > >
>> > > >
>> > > >
>> > > > ‐‐‐ Original Message ‐‐‐
>> > > > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy
>> <
>> > > dev-secur...@lists.mozilla.org> wrote:
>> > > >
>> > > > > Dear All,
>> > > > >
>> > > > > This is to announce the beginning of the public discussion phase
>> of
>> > > the
>> > > > > Mozilla root CA inclusion process,
>> > > > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
>>
>> > > (Steps 4
>> > > > > through 9). Mozilla is considering approval of NAVER Business
>> Platform
>> > > > > Corp.’s request to include the NAVER Global Root Certification
>> > > Authority as
>> > > > > a trust anchor with the websites trust bit enabled, as documented
>> in
>> > > the
>> > > > > following Bugzilla case:
>> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby
>> > > initiate a
>> > > > > 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
>> the
>> > > CCAD

Re: Policy 2.7.1: Process Overview

[Ben Wilson via dev-security-policy]

I believe that this is where we are so far.  I have not received any
comments on issues 139, 147, 154, 173, or 205.
I have not sent an email out yet for issues 206, 207, 211 or 218.

*Issue*

*When Announced; Status*

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153.

10/6/2020; no comments yet

#147  - 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.

10/6/2020; no comments yet

#152  - 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.

10/15/2020; comments

#153  – 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.
Related to Issue #139.

10/15/2020; comments

#154  - Require Management
Assertions to list Non-compliance – Add to MRSP 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.”

10/22/2020; no comments yet

#173  - Strengthen
requirement for newly included roots to meet all past and present
requirements – Add language to MRSP 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.

10/28/2020; no comments yet

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

10/28/2020; comments

#187  - Require disclosure
of incidents in Audit Reports –  To MRSP 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) that occurred or were still open/unresolved at any time during
the audit period, or a statement that the auditor is unaware of any;”

10/22/2020; comments

#192  - Require
information about auditor qualifications in the audit report – Require
audit statements to be accompanied by documentation of the auditor’s
qualifications demonstrating the auditor’s competence and experience.

11/3/2020; comments

#205  - Require CAs to
publish accepted methods for proving key compromise – Require CAs to
disclose their acceptable methods for proving key compromise in section
4.9.12 of their CPS.

11/5/2020; no comments yet

#206  - Limit re-use of
domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
verify ownership/control of each dNSName and iPAddress in the certificate's
subjectAltName at intervals of 398 days or less;”

Not sent to m.d.s.p. list yet

#207  - Require audit
statements to provide information about which CA Locations were and were
not audited, and the extent to which they were (or were not) audited

Not sent to m.d.s.p. list yet

#211  - Align OCSP
requirements in Mozilla's policy with the section 4.9.10 of the Baseline
Requirements

Not sent to m.d.s.p. list yet

#218  Clarify CRL
requirements for End Entity Certificates – For CRLite, Mozilla would like
to ensure that it has full lists of revoked certificates. If the CA uses
partial CRLs, then require CAs to provide the URL location of their full
and complete CRL in the CCADB.

Not sent to m.d.s.p. list yet

On Mon, Nov 9, 2020 at 2:14 PM Ben Wilson  wrote:

> Re-posting this email to start it with its own subject line and to start a
> new thread:
>
> There have been questions about the process being followed and the comment
> period.  Here is where it now stands.
>
> I intend to introduce the remaining discussion topics over the next three
> weeks. I did not announce an end to the discussion period on purpose, so
> that we can have as full of a discussion as possible. Also, in the next
> three weeks, I int

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Here is an attempt to address the comments received thus far. In Github,
here is a markup:

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

This sentence would be deleted: "These requirements include all
cross-certificates which chain to a certificate that is included in
Mozilla’s CA Certificate Program."

And the following would be added:

"A certificate is deemed to directly or transitively chain to a CA
certificate included in Mozilla’s CA Certificate Program if:

(1)   the certificate’s Issuer Distinguished Name matches (according to the
name-matching algorithm specified in RFC 5280, section 7.1) the Subject
Distinguished Name in a CA certificate or intermediate certificate that is
in scope according to section 1.1 of this Policy, and

(2)   the certificate is signed with a Private Key whose corresponding
Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or
intermediate certificate.
Thus, these requirements also apply to so-called reissued/doppelganger CA
certificates (roots and intermediates) and to cross-certificates."

I think it is important not to lose sight of the main reason for this
proposed change-- there has been confusion about whether re-issued root CA
certificates need to be disclosed in the CCADB.

I look forward to your additional comments and suggestions.

Thank you,

Ben


On Mon, Nov 2, 2020 at 11:14 AM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> As an alternate proposal, I suggest replacing the third paragraph of
> section 5.3, which currently reads:
>
> "These requirements include all cross-certificates which chain to a
> certificate that is included in Mozilla’s CA Certificate Program."
>
> with:
>
> "A certificate is considered to directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program if there is a CA
> or Intermediate certificate in scope (as defined in section 1.1 of this
> Policy) where both of the following is true:
> 1)  The certificate’s Issuer Distinguished Name matches (according to
> the name-matching algorithm specified in RFC 5280, section 7.1) the Subject
> Distinguished Name of the certificate in scope, and
> 2)  The certificate is signed with a Private Key whose corresponding
> Public Key is encoded in the SubjectPublicKeyInfo of the certificate in
> scope."
>
> This proposal better defines the meaning of chaining to certificates
> included in the Mozilla CA program and covers the various scenarios that
> have caused issues historically concerning cross-certificates and
> self-signed certificates.
>
> Thanks,
> Corey
>
> On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
> > Issue #186 in Github 
> > deals with the disclosure of CA certificates that directly or
> transitively
> > chain up to an already-trusted, Mozilla-included root. A common scenario
> > for the situation discussed in Issue #186 is when a CA creates a second
> (or
> > third or fourth) root certificate with the same key pair as the root
> that
> > is already in the Mozilla Root Store. This problem exists at the
> > intermediate-CA-certificate level, too, where a self-signed
> > intermediate/subordinate CA certificate is created and not reported.
> >
> > Public disclosure of such certificates is already required by section
> 5.3
> > of the MRSP, which reads, "All certificates that are capable of being
> used
> > to issue new certificates, and which directly or transitively chain to a
> > certificate included in Mozilla’s CA Certificate Program, MUST be
> operated
> > in accordance with this policy and MUST either be technically
> constrained
> > or be publicly disclosed and audited."
> >
> > There have been several instances where a CA operator has not disclosed
> a
> > CA certificate under the erroneous belief that because it is self-signed
> it
> > cannot be trusted in a certificate chain beneath the already-trusted,
> > Mozilla-included CA. This erroneous assumption is further discussed in
> Issue
> > #186 .
> >
> > The third paragraph of MRSP section 5.3 currently reads, " These
> > requirements include all cross-certificates which chain to a certificate
> > that is included in Mozilla’s CA Certificate Program."
> >
> > I recommend that we change that paragraph to read as follows:
> >
> > "These requirements include all cross-certificates *and self-signed
> > certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public
> key
> > is signed by the private key) that* chain to a CA certificate that is
> > included in Mozilla’s CA Certificate Program*, and CAs must disclose
> such
> > CA certificates in the CCADB*.
> >
> > I welcome your recommendations on how we can make this language even
> more
> > clear.
> >
> > Thanks,
> >
> > Ben
> ___
> dev-security-policy mailing l

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

> I see that this is related to
> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
> does not assert the anyPolicy or the CA's EV policy OID, including the
> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>
> That's correct.
___
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 #205: Require CAs to publish accepted methods for proving key compromise

[Ben Wilson via dev-security-policy]

On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos 
wrote:

>
> I believe this information should be the "minimum" accepted methods of
> proving that a Private Key is compromised. We should allow CAs to accept
> other methods without the need to first update their CP/CPS. Do people
> think that the currently proposed language would forbid a CA from
> accepting methods that are not explicitly documented in the CP/CPS?
>
> I also think that "parties" is a bit ambiguous, so I would suggest
> modifying that to follow the language of the BRs section 4.9.2
> "Subscribers, Relying Parties, Application Software Suppliers, and other
> third parties". Here is my proposed change:
>
> "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
> minimum) that Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties may use to demonstrate private key
> compromise."
>
> Dimitris,
Instead, what about something like,  "Section 4.9.12 of a CA's CP/CPS MUST
clearly specify its accepted methods that Subscribers, Relying Parties,
Application Software Suppliers, and other third parties may use to
demonstrate private key compromise. A CA MAY allow additional, alternative
methods that do not appear in section 4.9.12 of its CP/CPS." ?
Ben
___
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 #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

Jakob,

On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> How would that phrasing cover doppelgangers of intermediary SubCAs under
> an included root CA?
>
>
> To clarify, the title of section 5.3 is "Intermediate Certificates".
Also, both subsection (1) and (2) under the proposed amendment reference
"intermediate certificates" -  "(1) ...the Subject Distinguished Name in a
CA certificate or *intermediate certificate* that is in scope according to
section 1.1 of this Policy" and "(2)... corresponding Public Key is encoded
in the SubjectPublicKeyInfo of that CA certificate or *intermediate
certificate*." And finally, additional
language would try and make this clear by saying, "Thus, these requirements
also apply to so-called reissued/doppelganger CA certificates (roots *and
intermediates*) and to cross-certificates."

I hope this answers your question.

Sincerely,

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

FNMT: Public Discussion of Root Inclusion Request

[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 Fábrica Nacional de Moneda y Timbre
(FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the
root store. See
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9).

Mozilla is considering approving FNMT’s request to add the root as a trust
anchor with the websites trust bit and EV enabled as documented in Bugzilla bug
#1559342 .

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 the CCADB:*

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

*AC RAIZ FNMT-RCM SERVIDORES SEGUROS* is valid from 12/20/2018 to 12/20/2043

SHA2 Certificate Hash:
554153B13D2CF9DDB753BFBE1A4E0AE08D0AA4187058FE60A2B862B2E4B87BCB

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

*Root Certificate Download:*

https://www.sede.fnmt.gob.es/documents/10445900/10526749/AC_Raiz_FNMT-RCM-SS.cer


*CP/CPS:*

https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf

Current CPS is version 1.5, published 1-October-2020.

Repository location:
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion

*2020 BR Self Assessment* (pdf) is located here:

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

*Audits:*  Annual audits are performed by AENOR Internacional. The most
recent audit was completed by AENOR, for the period ending January 12,
2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
Validation Certificate Policy).
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf
 The audit found “All the minor non-conformities have been scheduled to be
addressed in the corrective action plan of the Trust Service Provider. No
critical non-conformities were identified.”  Remediation of the minor
conformities was discussed in Bug # 1626805
.

*Incident Reports / Mis-Issuances *

*The following bugs/incidents (closed) have been reported. *

Bug 1495507  (filed
10/1/2018) OU field exceeding 64 characters

Bug 1544586  (filed
4/15/2019) 2019 audit findings

Bug 1596949  (filed
11/15/2019) CP/CPS lack CAA processing details

Bug 1626805  (filed
4/1/2020) 2020 audit findings

No misissuances were found under this root, and certificates issued under
it have passed testing.

Revocation checking at
https://certificate.revocationcheck.com/testactivetipo1.cert.fnmt.es
appears to work fine, except there are a few error messages -- "one of the
certificates in the chain could not be checked", "Valid signature but
response includes an unnecessary certificate chain" and "Certificate status
is 'Revoked' expecting 'Unknown'".  Hopefully, these errors can be
explained or remedied. Otherwise, I have no further questions or concerns
at this time.

I urge anyone with any additional concerns or questions to raise them on
this list by replying under the subject heading above.

Pursuant to Step 5 - "A representative of the CA responds to questions and
concerns posted during the public discussion of the CA's request."

Again, this email begins a three-week public discussion period, which I’m
scheduling to close on or about 9-December-2020.



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: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

 FNMT provided the following clarification regarding its audits:

*Audits:* Annual audits are performed by AENOR Internacional. The most
recent audit was completed by AENOR, for the period ending January 12,
2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
Validation Certificate Policy).
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

It is mentioned that the audit was performed according to ETSI EN 319
411-1, but the link is the one for our audit ETSI 319 411-2 for QCP-w; EVCP:
Policy for EU qualified website certificate issued to a legal person and
linking the website to that person

Our root is being audited according to both ETSI EN 319 411-2 and ETSI 319
411-1 since we have 2 dedicated subordinate CA: AC Servidores Tipo 1 - for
EVCP and AC Servidores Tipo 2 - for OVCP

https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf


On Tue, Nov 17, 2020 at 5:06 PM Ben Wilson  wrote:

> All,
>
> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre
> (FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the
> root store. See
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps
> 4 through 9).
>
> Mozilla is considering approving FNMT’s request to add the root as a trust
> anchor with the websites trust bit and EV enabled as documented in Bugzilla 
> bug
> #1559342 .
>
> 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 the CCADB:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0418
>
> *AC RAIZ FNMT-RCM SERVIDORES SEGUROS* is valid from 12/20/2018 to
> 12/20/2043
>
> SHA2 Certificate Hash:
> 554153B13D2CF9DDB753BFBE1A4E0AE08D0AA4187058FE60A2B862B2E4B87BCB
>
> https://crt.sh/?id=1490711558
>
> *Root Certificate Download:*
>
>
> https://www.sede.fnmt.gob.es/documents/10445900/10526749/AC_Raiz_FNMT-RCM-SS.cer
>
>
> *CP/CPS:*
>
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
>
> Current CPS is version 1.5, published 1-October-2020.
>
> Repository location:
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>
> *2020 BR Self Assessment* (pdf) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9179612
>
> *Audits:*  Annual audits are performed by AENOR Internacional. The most
> recent audit was completed by AENOR, for the period ending January 12,
> 2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
> Validation Certificate Policy).
> https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf
>  The audit found “All the minor non-conformities have been scheduled to
> be addressed in the corrective action plan of the Trust Service Provider.
> No critical non-conformities were identified.”  Remediation of the minor
> conformities was discussed in Bug # 1626805
> .
>
> *Incident Reports / Mis-Issuances *
>
> *The following bugs/incidents (closed) have been reported. *
>
> Bug 1495507  (filed
> 10/1/2018) OU field exceeding 64 characters
>
> Bug 1544586  (filed
> 4/15/2019) 2019 audit findings
>
> Bug 1596949  (filed
> 11/15/2019) CP/CPS lack CAA processing details
>
> Bug 1626805  (filed
> 4/1/2020) 2020 audit findings
>
> No misissuances were found under this root, and certificates issued under
> it have passed testing.
>
> Revocation checking at
> https://certificate.revocationcheck.com/testactivetipo1.cert.fnmt.es
> appears to work fine, except there are a few error messages -- "one of the
> certificates in the chain could not be checked", "Valid signature but
> response includes an unnecessary certificate chain" and "Certificate status
> is 'Revoked' expecting 'Unknown'".  Hopefully, these errors can be
> explained or remedied. Otherwise, I have no further questions or concerns
> at this time.
>
> I urge anyone with any additional concerns or questions to raise them on
> this list by replying under the subject heading above.
>
> Pursuant to Step 5 - "A representative of the CA responds to questions and
> concerns posted during the public discussion of the CA's request."
>
> Again, this email begins a three-week public discussion period, which I’m
> scheduling to close on or about 9-

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

[Ben Wilson via dev-security-policy]

FWIW - Here is a recent post on this issue from JC Jones -
https://github.com/mozilla/crlite/issues/43#issuecomment-726493990


On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote:
> > On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Kathleen,
> > >
> > > This introduces an interesting question, how might Mozilla want to see
> > > partial CRLs be discoverable? Of course, they are pointed to by the
> > > associated CRLdp but is there a need for a manifest of these CRL
> shards
> > > that can be picked up by CCADB?
> > >
> > What's the use case for sharding a CRL when there's no CDP in the issued
> > certificates and the primary downloader is root stores?
>
> I think there may be some confusion. In my response to Kathleen's mail I
> stated " Of course, they are pointed to by the associated CRLdp", as such I
> am not suggesting there is a value to sharded/partitioned CRLs if not
> referenced by the CRLdp.
>
> The origin of my question is that as I remember the requirements, CAs do
> not have to produce a full and complete CRL. Specifically today, I believe
> they are allowed to produce partitioned CRLs, this is good because in some
> cases a full and complete CRL can be gigabytes in size. I assume the reason
> for adding the URL to a full, and I imagine complete, CRL is that Mozilla
> would like to use this information in its CRLLite feature.
>
> If so, and a CA partitions CRLs and does not produce a full and complete
> CRL how should the CA ensure Mozilla has the entire set of information it
> wants?
>
> Ryan
> ___
> 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

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

[Ben Wilson via dev-security-policy]

 The purpose of this email is to begin public discussion on a modification
to subsection 5 in section 2.1 of the Mozilla Root Store Policy.

Issue #206  in GitHub
discusses the need to bring the reuse period for domain validation in line
with the certificate issuance validity cycle of 398 days (as set forth in
section 6.3.2 of the Baseline Requirements). This proposal is not to say
that Mozilla is not also contemplating a ballot in the CA/Browser Forum
that would introduce similar language to the Baseline Requirements. Any
potential CABF endorsers of such a ballot should reach out to me off-list.

Currently, subsection 5 of section 2.1 of the Mozilla Root Store Policy
(MRSP) states that a CA must “verify that all of the information that is
included in SSL certificates remains current and correct at time intervals
of 825 days or less;”

It is proposed that a subsection 5.1 be added to this subsection to require
that, for subjectAltName verifications of dNSNames or IPAddresses performed
on or after July 1, 2021, CAs verify the dNSName or IPAddress at intervals
of 398 days or less.
Proposed language may be found in the following commit:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/b7b53eea3a0af1503f3c99632ba22efc9e86bee2
Restated here, the proposed language for subsection 5.1 of section 2.1 is:

"for subjectAltName verifications of dNSNames and IPAddresses performed on
or after July 1, 2021, verify that each dNSName or IPAddress is current and
correct at intervals of 398 days or less;"

I look forward to your comments, suggestions and discussions.

Thanks,

Ben
___
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]

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


>
> Could you consider changing it to read more like this (feel free to edit
> as needed):
>
> CAs may re-use domain validation for subjectAltName verifications of
> dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days  accordance with domain validation re-use in the BRs, section  4.2.1>.  CAs
> MUST limit domain re-use for subjectAltName verifications of dNSNames and
> IPAddresses to 398 days for domains validated on or after July 1, 2021.
>

Thanks. I am open to all suggestions and improvements to the language. I'll
see how this can be phrased appropriately to reduce the chance for
misinterpretation.


>
> From a CA perspective, I don't have any major concerns with shortening the
> domain re-use periods, but customers do/will.  Will there be a Mozilla blog
> that outlines the security improvements with cutting the re-use period in
> half and why July 2021 is the right time?
>

Yes.  I'll prepare a blog post that outlines the security improvements to
be obtained by shortening the reuse period. (E.g., certificates should not
contain stale information.) July 2021 was chosen because I figured April
2021 would be too soon. It also allows CAs to schedule any needed system
work during Q2/2021. In my opinion, Oct. 2023 is a considerably long tail
for this change, and existing domains/customers should not be affected
until then.

Cheers,

Ben


>
> Doug
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Monday, November 30, 2020 2:27 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
>  The purpose of this email is to begin public discussion on a modification
> to subsection 5 in section 2.1 of the Mozilla Root Store Policy.
>
> Issue #206 <https://github.com/mozilla/pkipolicy/issues/206> in GitHub
> discusses the need to bring the reuse period for domain validation in line
> with the certificate issuance validity cycle of 398 days (as set forth in
> section 6.3.2 of the Baseline Requirements). This proposal is not to say
> that Mozilla is not also contemplating a ballot in the CA/Browser Forum
> that would introduce similar language to the Baseline Requirements. Any
> potential CABF endorsers of such a ballot should reach out to me off-list.
>
> Currently, subsection 5 of section 2.1 of the Mozilla Root Store Policy
> (MRSP) states that a CA must “verify that all of the information that is
> included in SSL certificates remains current and correct at time intervals
> of 825 days or less;”
>
> It is proposed that a subsection 5.1 be added to this subsection to
> require that, for subjectAltName verifications of dNSNames or IPAddresses
> performed on or after July 1, 2021, CAs verify the dNSName or IPAddress at
> intervals of 398 days or less.
> Proposed language may be found in the following commit:
>
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/b7b53eea3a0af1503f3c99632ba22efc9e86bee2
> Restated here, the proposed language for subsection 5.1 of section 2.1 is:
>
> "for subjectAltName verifications of dNSNames and IPAddresses performed on
> or after July 1, 2021, verify that each dNSName or IPAddress is current and
> correct at intervals of 398 days or less;"
>
> I look forward to your comments, suggestions and discussions.
>
> Thanks,
>
> Ben
> ___
> 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

[Ben Wilson via dev-security-policy]

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 domain validation for subjectAltName verifications of
>> > dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days
>> > > accordance with domain validation re-use in the BRs, section  4.2.1>.
>> CAs
>> > MUST limit domain re-use for subjectAltName verifications of dNSNames
>> and
>> > IPAddresses to 398 days for domains validated on or after July 1, 2021.
>> >
>>
>> Thanks. I am open to all suggestions and improvements to the language.
>> I'll
>> see how this can be phrased appropriately to reduce the chance for
>> misinterpretation.
>>
>
> As noted above, I think adopting this wording would prevent much (any?)
> benefit from being achieved until 2023. I can understand that 2023 is
> better than "never", but I'm surprised to see an agreement so quickly to
> that being desirable over 2021. I suspect there's ample context here, but I
> think it would benefit from discussion.
>

The language needs to be worked on some more.  As I note above, we should
come up with a cutoff date that is before 2023. It seems that two years is
too long to wait for the last 825-day validation to expire when there are
domain validation methods that work in a matter of seconds.


>
>
>> > From a CA perspective, I don't have any major concerns with shortening
>> the
>> > domain re-use periods, but customers do/will.  Will there be a Mozilla
>> blog
>> > that outlines the security improvements with cutting the re-use period
>> in
>> > half and why Jul

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 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 domain validation for subjectAltName verifications
> >> > of dNSNames and IPAddresses done prior to J

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Matthias,
Have you been able to obtain the CPS downloadable from here:
https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1  or
here:  https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
?  (They both lead to the same CPS v. 1.6 document.)
Ben

On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
dev-security-policy  wrote:

> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
> Meent escribió:
> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > >  wrote:
> > > >
> > > > [...]
> > > >
> > > > *CP/CPS:*
> > > >
> > > >
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
> > > >
> > > > Current CPS is version 1.5, published 1-October-2020.
> > > >
> > > > Repository location:
> > > >
>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > > >
> > > I'm having trouble finding the end entity certificate profiles in this
> > > CPS. According to the CPS s7.1.2, they are supposed to be available at
> > > http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
> > > [0] of which the only english-language document [1] does not contain
> > > any end entity certificate profiles, but only the root and ICA
> > > profiles in attachments. Similarly, I cannot find the CPS you linked
> > > in their repository.
> > >
> > All the relevant documentation (CPS, PDS, Terms and conditions,
> certificate profiles, and old versions of CPSs) of each CA is published in
> its corresponding channel in the website, all of them accessible from:
> >
>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>
> I'm sorry, but I'm having trouble finding a link to the latest version of
> the CPS of the to-be-included root in that repository. If you add this CPS,
> it would be useful to take Mozilla Root Store Policy section 3.3 (6) into
> account ("CAs must provide a way to clearly determine which CP and CPS
> applies to each of its root and intermediate certificates").
>
> > For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each
> intermediate CA):
> > AC SERVIDORES SEGUROS TIPO 1:
> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> > and
> > AC SERVIDORES SEGUROS TIPO 2:
> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
> >
> > In regards the certificate profiles, we have included in CPS v1.6 section
> 7.1.2. direct links to the published documents of profiles.
> >
> > The document describing the profiles of the Website authentication
> certificates, including all extensions, are published at
> > AC SERVIDORES SEGUROS TIPO 1:
> >
>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> > AC SERVIDORES SEGUROS TIPO 2:
> >
>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
> >
>
> Thank you for the links, I probably overlooked them before.
>
> > > I noticed that the CPS defers a great amount of sections (section 5,
> > > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
> > > probably is [1] but that is never explicitly confirmed in the CPS -
> > > there is no explicit link to any repository in section 1.6.1 where the
> > > acronym is defined, nor are there any other indications that this DGPC
> > > is located in the repository under the link of [0]. This is confusing,
> > > and detrimental to the readability of the document.
> > >
> > CPS new version (v1.6) integrates all the sections that were referred to
> in the DGPC (v5.8) and which applied in general to all our CAs. From
> version 1.6 our CPS collects in a single document all the information and
> BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS
> > [...]
> > I hope that we have been able to resolve all the issues raised with this
> new version of the CPS (1.6) and have gained in transparency.
> > Thanks
> > Santiago.
>
> Thanks for the update, it sounds promising. I'll check it again once I can
> find the CPS in the repository.
>
> Regards,
>
> Matthias
> ___
> 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

Summary of Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

 All,

We have prepared an issues list as a summary of Camerfirma's compliance
issues over the past several years. The purpose of the list is to collect
and document all issues and responses in one place so that an overall
picture can be seen by the community. The document is on the Mozilla wiki:
https://wiki.mozilla.org/CA:Camerfirma_Issues.


I will now forward the link above to Camerfirma to provide them with a
proper opportunity to respond to the issues raised and to ask that they
respond directly in m.d.s.p. with any comments, corrections, inputs, or
updates that they may have.

If anyone in this group believes they have an issue appropriate to add to
the list, please send an email to certifica...@mozilla.org.

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: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

s,
> > > Have you been able to obtain the CPS downloadable from here:
> > > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or
> here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2 ?
> (They both lead to the same CPS v. 1.6 document.)
> > > Ben
> > >
> > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
> dev-security-policy  wrote:
> > >>
> > >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
> > >> dev-secur...@lists.mozilla.org> wrote:
> > >> >
> > >> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias
> van de
> > >> Meent escribió:
> > >> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > >> > >  wrote:
> > >> > > >
> > >> > > > [...]
> > >> > > >
> > >> > > > *CP/CPS:*
> > >> > > >
> > >> > > >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
> > >> > > >
> > >> > > > Current CPS is version 1.5, published 1-October-2020.
> > >> > > >
> > >> > > > Repository location:
> > >> > > >
> > >>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > >> > > >
> > >> > > I'm having trouble finding the end entity certificate profiles in
> this
> > >> > > CPS. According to the CPS s7.1.2, they are supposed to be
> available at
> > >> > > http://www.cert.fnmt.es/dpcs/, but that redirects me to a
> repository
> > >> > > [0] of which the only english-language document [1] does not
> contain
> > >> > > any end entity certificate profiles, but only the root and ICA
> > >> > > profiles in attachments. Similarly, I cannot find the CPS you
> linked
> > >> > > in their repository.
> > >> > >
> > >> > All the relevant documentation (CPS, PDS, Terms and conditions,
> > >> certificate profiles, and old versions of CPSs) of each CA is
> published in
> > >> its corresponding channel in the website, all of them accessible
> from:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > >>
> > >> I'm sorry, but I'm having trouble finding a link to the latest
> version of
> > >> the CPS of the to-be-included root in that repository. If you add
> this CPS,
> > >> it would be useful to take Mozilla Root Store Policy section 3.3 (6)
> into
> > >> account ("CAs must provide a way to clearly determine which CP and
> CPS
> > >> applies to each of its root and intermediate certificates").
> > >>
> > >> > For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for
> each
> > >> intermediate CA):
> > >> > AC SERVIDORES SEGUROS TIPO 1:
> > >> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> > >> > and
> > >> > AC SERVIDORES SEGUROS TIPO 2:
> > >> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
> > >> >
> > >> > In regards the certificate profiles, we have included in CPS v1.6
> section
> > >> 7.1.2. direct links to the published documents of profiles.
> > >> >
> > >> > The document describing the profiles of the Website authentication
> > >> certificates, including all extensions, are published at
> > >> > AC SERVIDORES SEGUROS TIPO 1:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> > >> > AC SERVIDORES SEGUROS TIPO 2:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
> > >> >
> > >>
> > >> Thank you for the links, I probably overlooked them before.
> > >>
> > >> > > I noticed that the CPS defers a great amount of sections (section
> 5,
> > >> > > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC,
> which
> > >> > > probably is [1] but that is never explicitly confirmed in the CPS
> -
> > >> > > there is no expli

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

he event that a Private Key is to be transported from one Cryptographic
> Module to another, the Private Key must be encrypted during transport.
> Private Keys must never exist in plain text form outside the Cryptographic
> Module boundary."
>
> CPS / DGPC s6.2.7 fails to commit FNMT to using devices meeting FIPS 140
> level 3 or higher (as that is apparently located in DGPC 6.2.1 and 6.2.8
> (?))
>
> Section 6.2.7 now states, "Root CA private keys of the FNMT-RCM are
> generated and stored inside cryptographic modules which meet the
> requirements of 6.2.1 of this CPS"
>
> CPS / DGPC does not mention "factor" or "2fa" according to my search, even
> though BR 6.5.2 specifies 'The CA SHALL enforce multi-factor authentication
> for all accounts capable of directly causing certificate issuance.".
>
> Section 6.5.1 now states, "The FNMT-RCM shall enforce multi-factor
> authentication for all accounts capable of directly causing certificate
> issuance."
>
> ... skipped over similar issues in 7: failure to document a commitment to
> the relevant sections of the BR ... skipped over similar issues in 8:
> failure to document a commitment to the relevant sections of the BR
>
> FNMT indicated "Sections 7 and 8 have been reviewed and more detailed
> information has been included in CPS v.1.6 sections 7.1.2, 8, 8.1, and 8.5.
> "
>
>
>
> On Fri, Dec 4, 2020 at 12:40 PM Santiago Brox via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> El viernes, 4 de diciembre de 2020 a las 18:20:41 UTC+1, Matthias van de
>> Meent escribió:
>> > Thanks for the pointer, Ben.
>> >
>> > I didn't realise that the links in section 'Particulares AC Raíz
>> > FNMT-RCM Servidores Seguros' of their main repository [1] were links
>> > to repositories that would include the applicable CPS... As those
>> > sections seemed to be for ICAs of the root, I didn't consider them as
>> > a source for the CPS of their parent CA. Together with that the CPS
>> > pointers in the certificate profile point to the main repository and
>> > that the QcPDS links in the certificate profiles don't seem to point
>> > to anything, I got lost...
>> >
>> > So, sorry for the noise, I was very confused by the structure of the
>> repository.
>> >
>> > Now that I know where to look, I'll probably check the contents more
>> > thoroughly sometime in the following weekend, at first glance they
>> > already looked much better.
>> >
>> > -Matthias
>> >
>> > [1]
>> https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion
>> > On Wed, 2 Dec 2020, 23:44 Ben Wilson,  wrote:
>> > >
>> > > Matthias,
>> > > Have you been able to obtain the CPS downloadable from here:
>> > > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or
>> here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
>> ? (They both lead to the same CPS v. 1.6 document.)
>> > > Ben
>> > >
>> > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
>> dev-security-policy  wrote:
>> > >>
>> > >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy
>> <
>> > >> dev-secur...@lists.mozilla.org> wrote:
>> > >> >
>> > >> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias
>> van de
>> > >> Meent escribió:
>> > >> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
>> > >> > >  wrote:
>> > >> > > >
>> > >> > > > [...]
>> > >> > > >
>> > >> > > > *CP/CPS:*
>> > >> > > >
>> > >> > > >
>> > >>
>> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
>> > >> > > >
>> > >> > > > Current CPS is version 1.5, published 1-October-2020.
>> > >> > > >
>> > >> > > > Repository location:
>> > >> > > >
>> > >>
>> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>> > >> > > >
>> > >> > > I'm having trouble finding the end entity certificate profiles
>> in this
>> > >> > > CPS. According to the CPS s7.1.2, they are supposed to b

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]

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

with respect to incident reporting and in section 7.1

with requirements for the CA inclusion process.

It is proposed that we add a new subsection 10 to MRSP section 3.1.4

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.

We look forward to your comments and suggestions.

Sincerely yours,

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

Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

[Ben Wilson via dev-security-policy]

This discussion is related to Issue #211 on GitHub
.

Effective September 30, 2020, as a result of the Browser Alignment Ballot
, section
4.9.10 of the CA/Browser Forum’s BaselineRequirements
 (BR§4.9.10) says
that a CA’s OCSP responses must meet certain requirements. The purpose of
this email is to determine whether changes should be made to section 6 of
the Mozilla Root Store Policy

(MRSP§6) to bring it closer to the Forum’s requirements for OCSP responses.
There are a few possible paths forward, including:

*Option 1* - Leave “as is” because MRSP§6 doesn’t conflict with the
Baseline Requirements.  MRSP§6 currently says,

“For end-entity certificates, if the CA provides revocation information via
an Online Certificate Status Protocol (OCSP) service:

· it MUST update that service at least every four days; and

· responses MUST have a defined value in the nextUpdate field, and it MUST
be no more than ten days after the thisUpdate field; and

· the value in the nextUpdate field MUST be before or equal to the notAfter
date of all certificates included within the BasicOCSPResponse.certs field
or, if the certs field is omitted, before or equal to the notAfter date of
the CA certificate which issued the certificate that the BasicOCSPResponse
is for.”

*Option 2* - MRSP§6 could simply incorporate by reference all of BR§4.9.10,
but then quite a few new OCSP requirements would also be adopted, some of
which people might find useful.



*Option 3* - Paste only language from BR§4.9.10’s subsections (1) through
(4) (for Subscriber/End-Entity Certificates) into MRSP§6.  Those four
subsections state:  “(1) OCSP responses MUST have a validity interval
greater than or equal to eight hours; (2) OCSP responses MUST have a
validity interval less than or equal to ten days; (3) For OCSP responses
with validity intervals less than sixteen hours, then the CA SHALL update
the information provided via an Online Certificate Status Protocol prior to
one-half of the validity period before the nextUpdate; and (4) For OCSP
responses with validity intervals greater than or equal to sixteen hours,
then the CA SHALL update the information provided via an Online Certificate
Status Protocol at least eight hours prior to the nextUpdate, and no later
than four days after the thisUpdate.”  The drawback of this approach would
come when trying to synchronize the language—it would not be in lockstep
with relevant changes to the BRs.



*Option 4* - Amend MRSP§6 to just incorporate by reference the above
subsections, i.e., “subsections (1) through (4) of BR§4.9.10, which deal
with the OCSP status responses for Subscriber Certificates, are hereby
incorporated by reference”.  This approach has a similar drawback if
additional subsections are added, and it doesn’t include other language in
BR§4.9.10 that some might find useful.

*Option 5* - Other

Finally, under the options above, can anyone think why different language
might be needed for OCSP responses for non-SSL/TLS (e.g. SMIME)
implementations?

Thanks in advance for your suggestions / recommendations.

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

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

[Ben Wilson via dev-security-policy]

This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
.
It is identified and discussed in GitHub Issue #218
 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation reasons covered by the CRL scope.  A *full and complete CRL*
lists all unexpired certificates issued by a CA that have been revoked for
any reason." (Emphasis added.)

There is a new field in the CCADB for CAs to include information needed for
browsers or others to construct a "full and complete CRL", i.e. to gather
information from CAs that don't include the CRL path to their "full and
complete CRL" in end entity certificates they issue. This new CCADB field
is called "Full CRL Issued By This CA" and is located under the heading
"Pertaining to Certificates Issued by this CA." Rather than condition the
requirement that CAs fill in this information in the CCADB only when they
don't include a CDP to 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. In cases where the CA shards or partitions its
CRL, the CA must provide a JSON-based list of CRLs that when combined are
the equivalent of the full and complete CRL.

Proposed language to add to section 6 of the Mozilla Root Store Policy is
as follows:

*CAs SHOULD place the URL for the associated CRL within the
crlDistributionPoints extension of issued certificates. A CA MAY omit the
crlDistributionPoint extension, if permitted by applicable requirements and
policies, such as the Baseline Requirements. *

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


I look forward to your comments and suggestions.

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

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

[Ben Wilson via dev-security-policy]

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for GlobalSign.

See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
(Steps 4 through 9).

GlobalSign has four (4) new roots to include in the root store.  Two roots,
one RSA and another ECC, are to support server authentication (Bugzilla Bug
# 1570724 ) while two
other roots are for email authentication, RSA and ECC (Bugzilla Bug #
1637269 ).

Mozilla is considering approving GlobalSign’s request(s). 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 these two
CCADB cases:*

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

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

*Root Certificate Information:*

*GlobalSign Root R46 *

crt.sh -
https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

Download - https://secure.globalsign.com/cacert/rootr46.crt

*GlobalSign Root E46*

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

Download - https://secure.globalsign.com/cacert/roote46.crt

*GlobalSign Secure Mail Root R45 *

crt.sh -
https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974

Download - https://secure.globalsign.com/cacert/smimerootr45.crt

*GlobalSign Secure Mail Root E45 *

crt.sh -
https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19

Download - https://secure.globalsign.com/cacert/smimeroote45.crt


*CP/CPS:*

https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf

The current GlobalSign CPS is version 9.6, published 29-December-2020.

Repository location: https://www.globalsign.com/en/repository

*BR Self-Assessment* (Excel) is located here:

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

*Audits:*  GlobalSign is audited annually in accordance with the WebTrust
criteria by Ernst & Young, Belgium, which found in June 2020 that
“throughout the period April 1, 2019 to March 31, 2020, GlobalSign
management’s assertion, as referred to above, is fairly stated, in all
material respects, in accordance with the WebTrust Principles and Criteria
for Certification Authorities - SSL Baseline with Network Security, Version
2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents, which
had been previously reported as of that audit date:

1 Misissuance of QWAC certificates.

2 Issue with an OCSP responder status.

3 Some SSL certificates with US country code and invalid State/Prov have
been issued.

4 ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report.

5 OCSP responders found to respond signed by the default CA when passed an
invalid issuer in request.

6 Wrong business category on 3 EV SSL certificates.

7 OCSP Responder returned invalid values for some precertificates.

8 Customer running an on-premise (technically-constrained) CA that chains
to a GlobalSign root, issued certificates without AIA extension.

9 Misissued 4 certificates with invalid CN.

10 Certificates with Subject Public Key Info lacking the explicit NULL
parameter.

11 Untimely revocation of TLS certificate after submission of private key
compromise.

12 Unable to revoke 2 noncompliant QWACs within 5 days.

13 Unable to revoke noncompliant ICA within 7 days



*Incident Reports / Mis-Issuances *

The following bugs/incidents remain open and are being worked on.

1667944 

Empty SingleExtension in OCSP responses


1651447 

Failure to revoke noncompliant ICA within 7 days


1591005 

ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report 

1649937 

Incorrect OCSP Delegated Responder Certificate


1668007 

Invalid stateOrProvinceName value


1664328 

SHA-256 hash algorithm used with ECC P-384 key


1575880 

SSL Certificates with US country code and invalid State/Prov




No

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]

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.
> > >
> > > We look forward to your comments and suggestions.
> > >
> > > Sincerely yours,
> > >
> > > Ben
> > Hi Ben. Happy New Year. I have asked the WebTrust Task Force members to
> provide their comments and Don and I will then provide a more detailed
> response. I wanted to be sure to get each of the major firms' feedback
> before responding.
> >
> > Thank you.
> >
> > Jeff
>
> Ben, Don and I offer the following response, which has been vetted through
> the WebTrust Task Force:
>
> Proposed Requirement
> Disclose each location (at the state/province level) that 

Policy 2.7.1: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

I've updated the subject line for this thread so that it is consistent with
the other issues.  Also, as an update to what we are considering to address
this issue, we are looking at pointing to existing language here:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable.

On Thu, Nov 12, 2020 at 11:23 AM Ben Wilson  wrote:

>
> On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
>
>> I see that this is related to
>> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
>> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
>> does not assert the anyPolicy or the CA's EV policy OID, including the
>> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>>
>> That's correct.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7.1: MRSP Issue #139: Audits required even if not issuing

[Ben Wilson via dev-security-policy]

I've updated this subject line for consistency with the other issues.

On Tue, Oct 6, 2020 at 2:31 PM Ben Wilson  wrote:

> Here is the first issue for discussion here on the m.d.s.p. list relative
> to the next version of the Mozilla Root Store Policy (v.2.7.1).
>
> #139  - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153
> .
>
> Seven (7) comments are listed so far for this issue in GitHub, including
> discussion re: whether auditors can provide reports when a CA isn't being
> used to issue certificates.
>
> I made an initial attempt to address this with some language in line 272
> in the following commit in my GitHub repository -
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
> (related changes also appear below in that commit).
>
> The suggested language would amend the first paragraph of section 3.1.3 of
> the MRSP to read, "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.
> Successive period-of-time audits MUST be contiguous (no gaps)."
>
> We will need to discuss scope and timing for implementing this requirement.
>
> Thanks in advance for your contributions and suggestions.
>
> Ben
>
>
>
>
___
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 #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

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 disclosed to CCADB?
>
> --
> *From:* dev-security-policy 
> on behalf of Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> *Sent:* 08 January 2021 01:00
> *To:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for
> End Entity Certificates
>
> 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.
>
>
> This is the last issue that I have marked for discussion in relation to
> version 2.7.1 of the Mozilla Root Store Policy
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F&data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637456644391892862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=shOhNu8IGrT0iSSt2LY4E6LQlsr6y435Vv%2BNezNCh98%3D&reserved=0
> >.
> It is identified and discussed in GitHub Issue #218
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F218&data=04%7C01%7Crob%40sectigo.com%7C65685639e2bf45be5f6f08d8b370cf17%7C0e9c489

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

[Ben Wilson via dev-security-policy]

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 hypothetical scenario, there would be no way for the the
> CAO to misissue new SubCAs or otherwise misuse the root CA Key Pair, but
> still the usual risks associated with the 5 SubCA operations.
>
> Also the CAO would have no way to increase the set of top level SubCAs
> or issue revocation statements in any yet-to-be-invented data formats,
> even if doing so would be legitimate or even required by the root
> programs.
>
> Thus the hypothetical scenario could land the CAO in an impossible
> situation, if root program requirements or common CA protocols change,
> and those changes would require even one additional signature by the
> root CA Key Pair.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> 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]

As proposed, changes to section 3.1.3 of the MRSP do not make any
distinction between root CAs and subordinates.  Nonetheless, what if we
added this sentence to MRSP section 3.1.3, "This cradle-to-grave audit
requirement applies equally to subordinate CAs as it does to root CAs."?
If that does not resolve the issues raise, please provide recommended edits
to section 3.1.3 of the MRSP that will make it more clear and less
susceptible to misinterpretation.

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 hypothetical scenario, there would be no way for the the
>> CAO to misissue new SubCAs or otherwise misuse the root CA Key Pair, but
>> still the usual risks associated with the 5 SubCA operations.
>>
>> Also the CAO would have no way to increase the set of top level SubCAs
>> or issue revocation statements in any yet-to-be-invented data formats,
>> even if doing so would be legitimate or even required by the root
>> programs.
>>
>> Thus the hypothetical scenario could land the CAO in an impossible
>> situation, if root p

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

In addition to the original proposal, I propose that we hyperlink "capable
of issuing EV certificates" to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable.

On Thu, Nov 12, 2020 at 11:23 AM Ben Wilson  wrote:

>
> On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
>
>> I see that this is related to
>> https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla
>> Firefox does not enable "EV Treatment" if an Intermediate CA Certificate
>> does not assert the anyPolicy or the CA's EV policy OID, including the
>> CA/B Forum EV OID, regardless of what the end-entity certificate asserts.
>>
>> That's correct.
>
___
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 #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

In line with the proposed hyperlink to
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable from
"capable of issuing EV certificates" (see Issue #147), then I don't think
the proposed parenthetical is necessary anymore, and I think this issue can
be considered resolved without needing to explain policy constraints for EV
audit exceptions in the MRSP.


On Fri, Nov 6, 2020 at 4:43 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  >> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
>  >> occurrence of "capable of issuing EV certificates" link to
>  >> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
>
> > In the definition of EV TLS Capable, I'd move the last bullet up to the
> top.
> >
>
> Done. 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 #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

As an alternative for this addition to MRSP section 5.3, please consider
and comment on:

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.


On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson  wrote:

> Jakob,
>
> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>> an included root CA?
>>
>>
>> To clarify, the title of section 5.3 is "Intermediate Certificates".
> Also, both subsection (1) and (2) under the proposed amendment reference
> "intermediate certificates" -  "(1) ...the Subject Distinguished Name in a
> CA certificate or *intermediate certificate* that is in scope according
> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
> certificate*." And finally, additional
> language would try and make this clear by saying, "Thus, these
> requirements also apply to so-called reissued/doppelganger CA certificates
> (roots *and intermediates*) and to cross-certificates."
>
> I hope this answers your question.
>
> Sincerely,
>
> Ben
>
___
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 #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

All,

Based on the comments received, I am inclined to clarify the proposed
language under Issues #154 and #187 with reference to a CA's Bugzilla
compliance bugs rather than "incidents".  The existing language in section
2.4 of the MRSP already requires the CA to promptly file an Incident Report
in Bugzilla for all incidents.

My proposal for Issue #154 is to add a final sentence to MRSP section 2.4
which would say, "If being audited according to the WebTrust criteria, the
CA’s Management Assertion letter MUST include a complete list of the CA's
Bugzilla compliance bugs that were unresolved at any time during the audit
period."

Under Issue #187, I propose that new item 11 in MRSP section 3.1.4 (required
publicly-available audit documentation) would read:  "11.  a complete list
of the CA’s Bugzilla compliance bugs that were unresolved at any time
during the audit period."

Regarding guidance on excluding bugs that are flagged as "Invalid" or
"Duplicate" - I propose that we add a section to
https://wiki.mozilla.org/CA/BR_Audit_Guidance and hyperlink to it from the
words "CA's Bugzilla compliance bugs".  The guidance would say that invalid
or duplicate bugs do not need to be included in the list.

Also, in response to Jeff's comment, if a bug is in an unresolved status
spanning two audit periods, I think it should still appear in both
management assertions and audit reports because one of the primary
rationales for these requirements is to ensure that auditors are aware of
the CA's compliance status.

Thoughts?

Thanks,

Ben



On Fri, Nov 6, 2020 at 10:36 AM Jeff Ward via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, October 22, 2020 at 1:53:40 PM UTC-5, Ben Wilson wrote:
> > The purpose of this email is to begin public discussion on the addition
> of
> > a subsection 11 to section 3.1.4 of the Mozilla Root Store Policy. Issue
> > #187  in GitHub
> proposes
> > to require audit reports to list all incidents occurring (or open)
> during
> > the audit period of which the auditor has been made aware or to state
> that
> > the auditor is unaware of any incidents. This is related to Issue #154
> >  (management assertion
> > disclosures). That proposal is to have section 2.4 read as follows: "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."
> >
> > Proposed language may be found in the following commits:
> >
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/f6639f503b743aae402dc0f4841dc3dd5ba88753
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/6c07c44e4db473dc4d34009f1bc955a0e18cb4c1
> > -
> >
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/5dec00e53b4c6361d85af7644660fe185fcf463d
> >
> > Proposed language for section 3.1.4 is:
> >
> > "11. all incidents (as defined in section 2.4) that occurred or were
> still
> > open/unresolved at any time during the audit period, or a statement that
> > the auditor is unaware of any;"
> >
> > I look forward to your comments, suggestions and discussions.
> >
> > Ben
>
> Thanks for bringing this up Ben.  It is important to consider this
> requirement in conjunction with #154 and address them together. It seems
> reasonable to require a CA to disclose all known incidents that are
> applicable during a given period. It would be important, however, to define
> “known incident” as a “verified bug” and exclude items such as bugs closed
> as a duplicate, invalid, etc.  It would also make sense to clarify that an
> incident should only be disclosed once and eliminate duplication when an
> incident spans two audit periods.
>
> Also keep in mind an auditor typically issues an opinion on management’s
> assertion of its controls. Audit opinions do not make negative assurance
> statements, such as not being aware of any incidents during the period. If
> the CA is required to make this assertion, the auditor’s opinion will
> consider that statement.
>
> Thanks,
>
> Jeff
> ___
> 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 #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

Here is my attempt to reword section 3.2 based on combining MRSP version
2.4.1 with version 2.7.
My approach was to align the concepts of "competent", "independent" and
"qualified" with their more-accepted meanings.
Version 2.4.1 and earlier versions of the Mozilla Root Store Policy mixed
some of these concepts together.

3.2 Auditors

Mozilla requires that audits MUST be performed by a competent, independent,
qualified party.

The burden is on the CA to prove *establish* that it*s auditor* has me*e*t
*s* the below requirements *below*.

However*,* the CA MAY request a preliminary determination from us regarding
the acceptability of the criteria and/or the competent, independent,
qualified party or parties by which it proposes to meet the requirements of
this policy.

By "competent party" we mean a person or other entity *group of persons* who
is authorized to perform audits according to the stated criteria (e.g., by
the organization responsible for the criteria or by a relevant agency) or
for whom there is sufficient public information available to determine that
the party is competent *has sufficient education, experience, and ability*
to judge the CA’s conformance to the stated criteria.

In the latter case, "Public information" referred to SHOULD include
information regarding the party’s:
- knowledge of CA-related technical issues such as public key cryptography
and related standards;
- experience in performing security-related audits, evaluations, or
risk analyses;
and
- honesty and objectivity *ability to deliver an opinion as to the CA’s
compliance with applicable requirements*.

By "independent party" we mean a person or other entity *group of persons* who
is not affiliated with the CA as an employee or director and for whom at
least one of the following statements is true:

the party is not financially compensated by the CA;

the nature and amount of the party's financial compensation by the CA is
publicly disclosed; or

the party is bound by law, government regulation, and/or a professional
code of ethics to render an honest and objective judgement regarding the CA.

By "qualified party" we mean a person or other entity or group of persons who
meets  *meeting *the requirements of section 8.2 of the Baseline
Requirements.

If a CA wishes to use auditors who do not fit the definition in section 8.2
of the Baseline Requirements, they MUST receive written permission from
Mozilla to do so in advance of the start of the audit engagement.

Mozilla will make its own determination as to the suitability of the
suggested party or parties, at its sole discretion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mozilla's Response to Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

Dear All,

We appreciate your comments and participation in the discussion about the
Summary of Camerfirma's Compliance Issues,
https://wiki.mozilla.org/CA:Camerfirma_Issues.

Mozilla has not yet made a decision about Camerfirma's continuation in our
root store. We intend to continue with our public discussion process to
determine whether Camerfirma's root certificates can remain included in
Mozilla's root store, and what actions they need to take.

Camerfirma has responded to the list of issues by providing a Remediation
Plan,
https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing,
with a commitment to align Camerfirma to the highest level of standards of
the Mozilla community.

They asked if there are parts of the Remediation Plan that need
clarification and for suggestions to improve the Remediation Plan.

We will appreciate your constructive feedback on it.

- Do the proposed actions in the Remediation Plan address the underlying
issues?

- If Camerfirma fully executes on this plan, will that be sufficient to
regain trust so that they can remain a CA in Mozilla's root store?

- Do you have additional recommendations for steps that you think
Camerfirma should take?

Thanks,

Ben
___
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]

Thanks, Clemens. I'll take a look.

Also, apparently my redlining was lost when my message was saved to the
newsgroup.

I'll see if I can re-post without the text formatting of strikeouts and
underlines.

On Tue, Jan 26, 2021 at 10:24 AM Clemens Wanko via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ben,
> looking at what was suggested so far for section 3.2, it seems that the BR
> combine and summarize under "qualified" in the BR section 8.2 what you and
> Kathleen describe with the definitions for "competent" and "independent"
> parties.
>
> Based upon that, MRSP section 3.2 could be structured in the following way:
>
> * 1st: definition of "competent party" **
> By "competent party" we mean...
>
> * 2nd: definition of "independency" **
> By "independent party" we mean...
>
> * 3rd: now refer to the BR summarizing 1 and 2 up in the term
> "qualified assessor/auditor" *
> By "qualified party" we mean a person or other entity or group of persons
> who meet *is meeting * the combination of the requirements defined above
> for a "competent party" and an "independent party" and as such meets
> *meeting * the requirements of section 8.2 of the Baseline Requirements.
>
>
> Further following that idea and syncing it with the wording also used by
> the BR, the current suggestion for MRSP section 3.2 could be
> revised/amended as follows:
>
> *
> 3.2 Auditors
> Mozilla requires that audits MUST be performed by a competent, independent
> and herewith qualified party.
> [...]
> By "competent party" we mean a person or other entity *group of persons*
> who has the proficiency and is authorized to perform audits according to
> the stated criteria (e.g., by the organization responsible for the criteria
> or by a relevant agency) and for whom is sufficient public information
> available to determine and evidence that the party is competent *has
> sufficient education, experience, and ability* to judge the CA’s
> conformance to the stated criteria.
> In the latter case, "Public information" referred to SHOULD *** -> SHALL -
> Why not being more strict here?*** include information regarding the
> party’s:
> - evidence of being bound by law, government regulation, or professional
> code of ethics;
> - knowledge of CA-related technical issues such as public key cryptography
> and related standards;
> - experience in performing security-related audits, evaluations, and risk
> analyses; and
> - honesty and objectivity *ability to deliver an opinion as to the CA’s
> compliance with applicable requirements*.
> [...]
> *
>
> Best regards
> Clemens
>
> ___
> 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: Mozilla's Response to Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

All,

So far there have been several good comments.  Please keep them coming.

I want to take this opportunity just to clarify a few of things.

First, it has been Mozilla's long-standing position that, "We believe that
the best approach to safeguarding secure browsing is to work with CAs as
partners, to foster open and frank communication, and to be diligent in
looking for ways to keep our users safe."  So, expect that we will take a
well-thought and deliberate approach to this issue with Camerfirma.

Second, many of the compliance issues have dealt with requirements
applicable to server certificates, yet only two roots of the four trusted
by Mozilla have the websites bit enabled.

Chambers of Commerce Root – 2008 (Email and Websites)

063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0

Global Chambersign Root – 2008  (Email and Websites)

136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA

Chambers of Commerce Root  (Email only)

0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3

Global Chambersign Root (Email only)

EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED
So there is another issue that needs to be considered, if distrust is
chosen, whether to remove just the websites trust bit or to take action
against all 4 roots, and if so, on what basis?

(Also, note that Camerfirma has two other roots that are not included in
the Mozilla trust store. They are the CHAMBERS OF COMMERCE ROOT – 2016 and
the GLOBAL CHAMBERSIGN ROOT - 2016.)

Thanks,

Ben
___
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]

On second thought, I think that Mozilla can accomplish what we want without
modifying the MRSP

(which says audits MUST be performed by a Qualified Auditor, as defined in
the Baseline Requirements section 8.2), and instead adding language to
https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications that
explains what additional information we need submitted to determine that an
auditor is "qualified" under Section 8.2 of the Baseline Requirements.

In other words (paraphrasing from BR 8.2), we would need evidence that the
persons or entities:
1. Are independent from the subject of the audit;
2. Have the ability to conduct an audit that addresses the criteria;
3. Have proficiency in examining Public Key Infrastructure technology,
information security tools and techniques, information technology and
security auditing, and the third-party attestation function;
4. Are accredited in accordance with ISO 17065 applying the requirements
specified in ETSI EN 319 403  *OR*   5. Are licensed by WebTrust;
6. Are bound by law, government regulation, or professional code of ethics
(to render an honest and objective opinion); and
7. Maintain Professional Liability/Errors & Omissions insurance with policy
limits of at least one million US dollars in coverage.

We do some of this already when we check on an auditor's status to bring an
auditor's record current in the CCADB.  The edits that we'll make will just
make it easier for us to go through the list above.

Thoughts?

Ben

On Tue, Jan 26, 2021 at 1:36 PM Ben Wilson  wrote:

> Thanks, Clemens. I'll take a look.
>
> Also, apparently my redlining was lost when my message was saved to the
> newsgroup.
>
> I'll see if I can re-post without the text formatting of strikeouts and
> underlines.
>
> On Tue, Jan 26, 2021 at 10:24 AM Clemens Wanko via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Hi Ben,
>> looking at what was suggested so far for section 3.2, it seems that the
>> BR combine and summarize under "qualified" in the BR section 8.2 what you
>> and Kathleen describe with the definitions for "competent" and
>> "independent" parties.
>>
>> Based upon that, MRSP section 3.2 could be structured in the following
>> way:
>>
>> * 1st: definition of "competent party" **
>> By "competent party" we mean...
>>
>> * 2nd: definition of "independency" **
>> By "independent party" we mean...
>>
>> * 3rd: now refer to the BR summarizing 1 and 2 up in the term
>> "qualified assessor/auditor" *
>> By "qualified party" we mean a person or other entity or group of persons
>> who meet *is meeting * the combination of the requirements defined above
>> for a "competent party" and an "independent party" and as such meets
>> *meeting * the requirements of section 8.2 of the Baseline Requirements.
>>
>>
>> Further following that idea and syncing it with the wording also used by
>> the BR, the current suggestion for MRSP section 3.2 could be
>> revised/amended as follows:
>>
>> *
>> 3.2 Auditors
>> Mozilla requires that audits MUST be performed by a competent,
>> independent and herewith qualified party.
>> [...]
>> By "competent party" we mean a person or other entity *group of persons*
>> who has the proficiency and is authorized to perform audits according to
>> the stated criteria (e.g., by the organization responsible for the criteria
>> or by a relevant agency) and for whom is sufficient public information
>> available to determine and evidence that the party is competent *has
>> sufficient education, experience, and ability* to judge the CA’s
>> conformance to the stated criteria.
>> In the latter case, "Public information" referred to SHOULD *** -> SHALL
>> - Why not being more strict here?*** include information regarding the
>> party’s:
>> - evidence of being bound by law, government regulation, or professional
>> code of ethics;
>> - knowledge of CA-related technical issues such as public key
>> cryptography and related standards;
>> - experience in performing security-related audits, evaluations, and risk
>> analyses; and
>> - honesty and objectivity *ability to deliver an opinion as to the CA’s
>> compliance with applicable requirements*.
>> [...]
>> *
>>
>> Best regards
>> Clemens
>>
>> ___
>> 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 #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

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.




On Thu, Jan 28, 2021 at 12:44 PM Ryan Sleevi  wrote:

>
>
> On Thu, Jan 28, 2021 at 1:43 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On second thought, I think that Mozilla can accomplish what we want
>> without
>> modifying the MRSP
>> <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors
>> >
>> (which says audits MUST be performed by a Qualified Auditor, as defined in
>> the Baseline Requirements section 8.2), and instead adding language to
>> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications that
>> explains what additional information we need submitted to determine that
>> an
>> auditor is "qualified" under Section 8.2 of the Baseline Requirements.
>>
>> In other words (paraphrasing from BR 8.2), we would need evidence that the
>> persons or entities:
>> 1. Are independent from the subject of the audit;
>> 2. Have the ability to conduct an audit that addresses the criteria;
>> 3. Have proficiency in examining Public Key Infrastructure technology,
>> information security tools and techniques, information technology and
>> security auditing, and the third-party attestation function;
>> 4. Are accredited in accordance with ISO 17065 applying the requirements
>> specified in ETSI EN 319 403  *OR*   5. Are licensed by WebTrust;
>> 6. Are bound by law, government regulation, or professional code of ethics
>> (to render an honest and objective opinion); and
>> 7. Maintain Professional Liability/Errors & Omissions insurance with
>> policy
>> limits of at least one million US dollars in coverage.
>>
>> We do some of this already when we check on an auditor's status to bring
>> an
>> auditor's record current in the CCADB.  The edits that we'll make will
>> just
>> make it easier for us to go through the list above.
>>
>> Thoughts?
>>
>
> I'm not sure this approach is very clear about the edits you're making,
> and whether pull requests or commits might be clearer, as Wayne did in the
> past. If there is a commit, happy to look at it and apologies if I missed
> it.
>
> I'm not sure this addresses the issue as raised, or at least, "or
> entities" seems to create the same issues that are trying to be addressed,
> by thinking in terms of "legal entities" rather than qualified persons.
>
> Your discussion about "auditor's" and "auditor's status" might be misread
> as "Audit firm", when I think the issue raised was thinking about "person
> performing the audit". The individual persons aren't necessarily licensed
> or accredited (e.g. #4/ #5), and may not be the ones that retain PL/E&O
> insurance (#7). Further, the individuals might be independent, but the firm
> not (#1)
>
> So I think you're really just left with wanting to have a demonstration as
> to the members of the audit team and how individual members meet (#2, #3,
> #6). Is that right? I think Kathleen's proposal from November got close to
> that, and then the remainder is clarifying the language that you've
> proposed for 2.7.1, namely "Individuals have competence, partnerships and
> corporations do not".
>
> I think the expectation goal is that "Individually, and as an audit team,
> they are independent (#1)" (e.g. you can't have a non-independent party
> running the audit with a bunch of independent parties reporting to them,
> since they're no longer independent), while that collectively the audit
> team meets #2/#3, with the burden being to demonstrate how the individuals
> on the team meet that.
>
> Is that what you were thinking? Or is my explanation a jumbled mess :)
>
___
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

[Ben Wilson via dev-security-policy]

This is a reminder that I will close discussion on this tomorrow.

On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:

> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for GlobalSign.
>
> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4 through 9).
>
> GlobalSign has four (4) new roots to include in the root store.  Two
> roots, one RSA and another ECC, are to support server authentication
> (Bugzilla Bug # 1570724
> ) while two other
> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
> ).
>
> Mozilla is considering approving GlobalSign’s request(s). 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 these two
> CCADB cases:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>
> *Root Certificate Information:*
>
> *GlobalSign Root R46 *
>
> crt.sh -
> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>
> Download - https://secure.globalsign.com/cacert/rootr46.crt
>
> *GlobalSign Root E46*
>
> crt.sh -
> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>
> Download - https://secure.globalsign.com/cacert/roote46.crt
>
> *GlobalSign Secure Mail Root R45 *
>
> crt.sh -
> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>
> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>
> *GlobalSign Secure Mail Root E45 *
>
> crt.sh -
> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>
> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>
>
> *CP/CPS:*
>
> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>
> The current GlobalSign CPS is version 9.6, published 29-December-2020.
>
> Repository location: https://www.globalsign.com/en/repository
>
> *BR Self-Assessment* (Excel) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9082310
>
> *Audits:*  GlobalSign is audited annually in accordance with the WebTrust
> criteria by Ernst & Young, Belgium, which found in June 2020 that
> “throughout the period April 1, 2019 to March 31, 2020, GlobalSign
> management’s assertion, as referred to above, is fairly stated, in all
> material respects, in accordance with the WebTrust Principles and Criteria
> for Certification Authorities - SSL Baseline with Network Security, Version
> 2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents,
> which had been previously reported as of that audit date:
>
> 1 Misissuance of QWAC certificates.
>
> 2 Issue with an OCSP responder status.
>
> 3 Some SSL certificates with US country code and invalid State/Prov have
> been issued.
>
> 4 ICAs in CCADB, without EKU extension are listed in WTCA report but not
> in WTBR report.
>
> 5 OCSP responders found to respond signed by the default CA when passed an
> invalid issuer in request.
>
> 6 Wrong business category on 3 EV SSL certificates.
>
> 7 OCSP Responder returned invalid values for some precertificates.
>
> 8 Customer running an on-premise (technically-constrained) CA that chains
> to a GlobalSign root, issued certificates without AIA extension.
>
> 9 Misissued 4 certificates with invalid CN.
>
> 10 Certificates with Subject Public Key Info lacking the explicit NULL
> parameter.
>
> 11 Untimely revocation of TLS certificate after submission of private key
> compromise.
>
> 12 Unable to revoke 2 noncompliant QWACs within 5 days.
>
> 13 Unable to revoke noncompliant ICA within 7 days
>
>
>
> *Incident Reports / Mis-Issuances *
>
> The following bugs/incidents remain open and are being worked on.
>
> 1667944 
>
> Empty SingleExtension in OCSP responses
> 
>
> 1651447 
>
> Failure to revoke noncompliant ICA within 7 days
> 
>
> 1591005 
>
> ICAs in CCADB, without EKU extension are listed in WTCA report but not in
> WTBR report 
>
> 1649937 
>
> Incorrect OCSP Delegated Responder Certificate
> 
>
> 1668007 
>
> Invalid stateOrProvinceName value
> 
>
> 16

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

[Ben Wilson via dev-security-policy]

On January 11, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store CA Application Process
] for the
above-referenced GlobalSign
inclusion request.

*Summary of Discussion and Completion of Action Items [Steps 5-8]:*

Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
Root CA hierarchy with single-purpose roots.  This will lead to less risk
due to fewer cross-dependencies from other uses of PKI. He also noted that
GlobalSign has improved the quality of its incident reporting and
remediation.  I agree on both of these points.

While GlobalSign currently has six matters open in Bugzilla, none of these
should be a reason to delay approval of this inclusion request.

1591005  – the
relevant issuing CAs have been revoked (nearly closed, waiting on a final
key destruction report)

1649937  - Incorrect
OCSP Delegated Responder Certificate issue - GlobalSign ceased including
the OCSP signing EKU in any newly generated issuing CA (approximately 10
remaining issuing CAs affected by issue are on schedule to be revoked)

1651447  –  Delayed
CA revocation, per issue # 1649937 above (GlobalSign is switching over from
old to newer infrastructure, as described in this and other bugs)

1664328  - SHA-256
hash algorithm used with ECC P-384 key (almost closed, status update needed)

1667944  – Empty
SingleExtension in OCSP responses (migration to new OCSP responders nearly
completed)

1668007  – Country
name in stateOrProvinceName field (almost closed, status update needed)

This is notice that I am closing public discussion [Step 9] and that it is
Mozilla’s intent to approve GlobalSign's request for inclusion [Step 10].

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

Thanks,

Ben

On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:

> This is a reminder that I will close discussion on this tomorrow.
>
> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>
>> This is to announce the beginning of the public discussion phase of the
>> Mozilla root CA inclusion process for GlobalSign.
>>
>> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
>> (Steps 4 through 9).
>>
>> GlobalSign has four (4) new roots to include in the root store.  Two
>> roots, one RSA and another ECC, are to support server authentication
>> (Bugzilla Bug # 1570724
>> ) while two other
>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>> ).
>>
>> Mozilla is considering approving GlobalSign’s request(s). 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 these two
>> CCADB cases:*
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>>
>> *Root Certificate Information:*
>>
>> *GlobalSign Root R46 *
>>
>> crt.sh -
>> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>>
>> Download - https://secure.globalsign.com/cacert/rootr46.crt
>>
>> *GlobalSign Root E46*
>>
>> crt.sh -
>> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>>
>> Download - https://secure.globalsign.com/cacert/roote46.crt
>>
>> *GlobalSign Secure Mail Root R45 *
>>
>> crt.sh -
>> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>>
>> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>>
>> *GlobalSign Secure Mail Root E45 *
>>
>> crt.sh -
>> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>>
>> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>>
>>
>> *CP/CPS:*
>>
>> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>>
>> The current GlobalSign CPS is version 9.6, published 29-December-2020.
>>
>> Repository location: https://www.globalsign.com/en/repository
>>
>> *BR Self-Assessment* (Excel) is located here:
>>
>> https://bugzilla.mozilla.org/attachment.cgi?id=9082310
>>
>> *Audits:*  GlobalSign is audited annually in accordance with the
>> WebTrust criteria by Ernst & Young, Belgium, which found in June 2020 that
>> “throughout the period April 1, 2019 to March 31, 2020, GlobalSign
>> management’s assertion, as referred to above, is fairly stated, in all
>> material respects, in accorda

Action on Camerfirma Root CAs

[Ben Wilson via dev-security-policy]

All,

Thank you for your continued participation in this discussion, and for
those of you who have provided very thoughtful comments.



As many of you have pointed out, there do not appear to be remediation
actions that Camerfirma can take at this time to sufficiently reduce the
risk of continuing to keep the Websites trust bit enabled for the
Camerfirma root certificates. Note that Camerfirma has indicated to us that
they are exiting the TLS certificate business.

The things that have stood out to me and Kathleen regarding Camerfirma’s
issues are:

   -

   Camerfirma has not demonstrated an ability to keep up with the
   CA/Browser Forum’s updates to the Baseline Requirements and continues to
   miss Effective Dates. (
   
https://wiki.mozilla.org/CA:Camerfirma_Issues#Issue_VV:_Certificates_without_CABForum_OV_Reserved_Policy_Identifier_.28Jan._2021.29
   )
   -

   A significant number of the issues that have been documented were caused
   by Camerfirma’s unconstrained subordinate CAs.
   -

   There is an unresolved gap in audit periods (
   
https://wiki.mozilla.org/CA:Camerfirma_Issues#Issue_JJ:_Unresolvable_Gap_in_Audits_.28Camerfirma.29_.282018_-_2019.29
   )
   -

   Incidents / Compliance Bugs did not appear to be handled with urgency,
   in regard to providing status and updates about how the CA was responding
   to each incident and what actions they were taking to ensure that each
   mistake would not be repeated in the future.
   -

   Root cause analysis results were not shared in a timely manner.
   -

   Questions were not answered quickly or with sufficient detail.
   -

   Incident reports were delayed.

Given the foregoing, we intend to turn off the Websites trust bit for the
following root certificates in our upcoming batch of changes to Mozilla’s
root store, which is expected to happen in Firefox 88 (
https://wiki.mozilla.org/Release_Management/Calendar):

- Chambers of Commerce Root - 2008 - https://crt.sh/?id=409684

- Global Chambersign Root - 2008 - https://crt.sh/?id=1044840

The Email (S/MIME) trust bit will continue to be enabled for these two root
certificates. In this regard, we ask Camerfirma to share with the community
its 2020 audit report and scope of audit controls that cover issuance and
management of S/MIME certificates, provide a migration plan for the older
2003 roots (see below), and provide an Improvement Action Plan.

We also intend to set the “Distrust for S/MIME After Date” to March 1,
2021, for the following older root certificates and request that Camerfirma
send us the number of valid certificates in their hierarchies and when they
expire:

- Chambers of Commerce Root - https://crt.sh/?id=1251

- Global Chambersign Root -  https://crt.sh/?id=10249844


We previously denied inclusion of Camerfirma’s 2016 root certificates, and
we uphold that decision --
https://bugzilla.mozilla.org/show_bug.cgi?id=986854#c62. As Wayne said in
the discussion (
https://groups.google.com/g/mozilla.dev.security.policy/c/skev4gp_bY4/m/GFpBHH63CQAJ
): “AC Camerfirma is welcome to submit a new inclusion request for a newly
generated root using a new key pair. “

Cross-signing of Camerfirma’s root certificates by another root in
Mozilla’s root store will only be acceptable after Camerfirma has completed
an Improvement Action Plan, and after section 8 of Mozilla’s root store has
been satisfied.

Also, before requesting inclusion of any new root certificates, Camerfirma
will need to complete said Improvement Action Plan to demonstrate that past
problems have been resolved and will not be repeated, and that the CA is
following best practices for operation and issuance of certificates.

Camerfirma will provide:

1) Its 2020 audit report

2) The scope document of controls audited for the 2008 roots

3) A migration plan for the older roots

4) An Improvement Action Plan

Regards,

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

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

[Ben Wilson via dev-security-policy]

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: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process, this
is notice of a "further question or concern" that has arisen concerning
GlobalSign's issuance of a 1024-bit RSA certificate. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
indicated that it will provide an incident report by next Tuesday,
9-Feb-2021.
Thanks,
Ben

On Tue, Feb 2, 2021 at 5:48 PM Ben Wilson  wrote:

> On January 11, 2021, we began the public discussion period [Step 4 of the
> Mozilla Root Store CA Application Process
> ] for the
> above-referenced GlobalSign inclusion request.
>
> *Summary of Discussion and Completion of Action Items [Steps 5-8]:*
>
> Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
> Root CA hierarchy with single-purpose roots.  This will lead to less risk
> due to fewer cross-dependencies from other uses of PKI. He also noted that
> GlobalSign has improved the quality of its incident reporting and
> remediation.  I agree on both of these points.
>
> While GlobalSign currently has six matters open in Bugzilla, none of these
> should be a reason to delay approval of this inclusion request.
>
> 1591005  – the
> relevant issuing CAs have been revoked (nearly closed, waiting on a final
> key destruction report)
>
> 1649937  -
> Incorrect OCSP Delegated Responder Certificate issue - GlobalSign ceased
> including the OCSP signing EKU in any newly generated issuing CA
> (approximately 10 remaining issuing CAs affected by issue are on schedule
> to be revoked)
>
> 1651447  –  Delayed
> CA revocation, per issue # 1649937 above (GlobalSign is switching over from
> old to newer infrastructure, as described in this and other bugs)
>
> 1664328  - SHA-256
> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>
> 1667944  – Empty
> SingleExtension in OCSP responses (migration to new OCSP responders nearly
> completed)
>
> 1668007  – Country
> name in stateOrProvinceName field (almost closed, status update needed)
>
> This is notice that I am closing public discussion [Step 9] and that it is
> Mozilla’s intent to approve GlobalSign's request for inclusion [Step 10].
>
>
> This begins a 7-day “last call” period for any final objections.
>
> Thanks,
>
> Ben
>
> On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:
>
>> This is a reminder that I will close discussion on this tomorrow.
>>
>> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>>
>>> This is to announce the beginning of the public discussion phase of the
>>> Mozilla root CA inclusion process for GlobalSign.
>>>
>>> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
>>> (Steps 4 through 9).
>>>
>>> GlobalSign has four (4) new roots to include in the root store.  Two
>>> roots, one RSA and another ECC, are to support server authentication
>>> (Bugzilla Bug # 1570724
>>> ) while two other
>>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>>> ).
>>>
>>> Mozilla is considering approving GlobalSign’s request(s). 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 these
>>> two CCADB cases:*
>>>
>>>
>>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>>>
>>>
>>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>>>
>>> *Root Certificate Information:*
>>>
>>> *GlobalSign Root R46 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>>>
>>> Download - https://secure.globalsign.com/cacert/rootr46.crt
>>>
>>> *GlobalSign Root E46*
>>>
>>> crt.sh -
>>> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>>>
>>> Download - https://secure.globalsign.com/cacert/roote46.crt
>>>
>>> *GlobalSign Secure Mail Root R45 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>>>
>>> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>>>
>>> *GlobalSign Secure Mail Root E45 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>>>
>>> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>>>
>>>
>>> *CP/CPS:*
>>>
>>> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>>>
>>> 

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

[Ben Wilson via dev-security-policy]

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.
Sincerely,
Ben

On Fri, Feb 5, 2021 at 2:36 PM Ben Wilson  wrote:

> All,
> Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process,
> this is notice of a "further question or concern" that has
> arisen concerning GlobalSign's issuance of a 1024-bit RSA certificate. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
> indicated that it will provide an incident report by next Tuesday,
> 9-Feb-2021.
> Thanks,
> Ben
>
> On Tue, Feb 2, 2021 at 5:48 PM Ben Wilson  wrote:
>
>> On January 11, 2021, we began the public discussion period [Step 4 of the
>> Mozilla Root Store CA Application Process
>> ] for the
>> above-referenced GlobalSign inclusion request.
>>
>> *Summary of Discussion and Completion of Action Items [Steps 5-8]:*
>>
>> Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
>> Root CA hierarchy with single-purpose roots.  This will lead to less risk
>> due to fewer cross-dependencies from other uses of PKI. He also noted that
>> GlobalSign has improved the quality of its incident reporting and
>> remediation.  I agree on both of these points.
>>
>> While GlobalSign currently has six matters open in Bugzilla, none of
>> these should be a reason to delay approval of this inclusion request.
>>
>> 1591005  – the
>> relevant issuing CAs have been revoked (nearly closed, waiting on a final
>> key destruction report)
>>
>> 1649937  -
>> Incorrect OCSP Delegated Responder Certificate issue - GlobalSign ceased
>> including the OCSP signing EKU in any newly generated issuing CA
>> (approximately 10 remaining issuing CAs affected by issue are on schedule
>> to be revoked)
>>
>> 1651447  –  Delayed
>> CA revocation, per issue # 1649937 above (GlobalSign is switching over from
>> old to newer infrastructure, as described in this and other bugs)
>>
>> 1664328  - SHA-256
>> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>>
>> 1667944  – Empty
>> SingleExtension in OCSP responses (migration to new OCSP responders nearly
>> completed)
>>
>> 1668007  – Country
>> name in stateOrProvinceName field (almost closed, status update needed)
>>
>> This is notice that I am closing public discussion [Step 9] and that it
>> is Mozilla’s intent to approve GlobalSign's request for inclusion [Step
>> 10].
>>
>> This begins a 7-day “last call” period for any final objections.
>>
>> Thanks,
>>
>> Ben
>>
>> On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:
>>
>>> This is a reminder that I will close discussion on this tomorrow.
>>>
>>> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>>>
 This is to announce the beginning of the public discussion phase of the
 Mozilla root CA inclusion process for GlobalSign.

 See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
 (Steps 4 through 9).

 GlobalSign has four (4) new roots to include in the root store.  Two
 roots, one RSA and another ECC, are to support server authentication
 (Bugzilla Bug # 1570724
 ) while two
 other roots are for email authentication, RSA and ECC (Bugzilla Bug #
 1637269 ).

 Mozilla is considering approving GlobalSign’s request(s). 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 these
 two CCADB cases:*


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


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

 *Root Certificate Information:*

 *GlobalSign Root R46 *

 crt.sh -
 https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

 Download - https://secure.globalsign.com/cacert/rootr46.crt

 *GlobalSign Root E46*

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

 Download - https://secure.globalsign.com/

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Ben Wilson via dev-security-policy]

In the Github document, which I'm using to track proposed language, I've
added "This applies to all non-technically constrained CA certificates,
including those that share the same key pair whether they are self-signed,
doppelgänger, reissued, cross-signed, or other roots."
https://github.com/BenWilson-Mozilla/pkipolicy/commit/5a3dd2e9d92ec689e08bf1cfa279121e2bb0478b
.

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

> As an alternative for this addition to MRSP section 5.3, please consider
> and comment on:
>
> 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.
>
>
> On Thu, Nov 12, 2020 at 11:54 AM Ben Wilson  wrote:
>
>> Jakob,
>>
>> On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> How would that phrasing cover doppelgangers of intermediary SubCAs under
>>> an included root CA?
>>>
>>>
>>> To clarify, the title of section 5.3 is "Intermediate Certificates".
>> Also, both subsection (1) and (2) under the proposed amendment reference
>> "intermediate certificates" -  "(1) ...the Subject Distinguished Name in a
>> CA certificate or *intermediate certificate* that is in scope according
>> to section 1.1 of this Policy" and "(2)... corresponding Public Key is
>> encoded in the SubjectPublicKeyInfo of that CA certificate or *intermediate
>> certificate*." And finally, additional
>> language would try and make this clear by saying, "Thus, these
>> requirements also apply to so-called reissued/doppelganger CA certificates
>> (roots *and intermediates*) and to cross-certificates."
>>
>> I hope this answers your question.
>>
>> Sincerely,
>>
>> Ben
>>
>
___
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'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 :)
>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7.1: MRSP Issue #221: Wrong hyperlink for "Material Change" in MRSP Section 8

[Ben Wilson via dev-security-policy]

All,
I am proposing for v. 2.7.1 a minor change that corrects a hyperlink issue
in MRSP section 8.

The link to "material change" here redirects to "alteration of instruments"
- https://legal-dictionary.thefreedictionary.com/Material+Changes, which is
altogether wrong since we're talking about a "material change" to CA
operations, not changes to legal documents.

Rather than replace the hyperlink, I think it is better to say what we mean
by "material change" and replace it 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."

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


Thanks,

Ben
___
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 #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

Here is an edit to proposed subparagraph 11 of MRSP section 3.1.4:

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), 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;

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

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.

Additional guidance and interpretation of the above would be available on
the wiki.

On Thu, Jan 28, 2021 at 2:05 PM Ryan Sleevi  wrote:

>
>
> On Sun, Jan 24, 2021 at 11:33 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> All,
>>
>> Based on the comments received, I am inclined to clarify the proposed
>> language under Issues #154 and #187 with reference to a CA's Bugzilla
>> compliance bugs rather than "incidents".  The existing language in section
>> 2.4 of the MRSP already requires the CA to promptly file an Incident
>> Report
>> in Bugzilla for all incidents.
>>
>> My proposal for Issue #154 is to add a final sentence to MRSP section 2.4
>> which would say, "If being audited according to the WebTrust criteria, the
>> CA’s Management Assertion letter MUST include a complete list of the CA's
>> Bugzilla compliance bugs that were unresolved at any time during the audit
>> period."
>>
>> Under Issue #187, I propose that new item 11 in MRSP section 3.1.4
>> (required
>> publicly-available audit documentation) would read:  "11.  a complete list
>> of the CA’s Bugzilla compliance bugs that were unresolved at any time
>> during the audit period."
>>
>
> I don't think this is a good change, and doesn't meet the intent of the
> problem.
>
> This implies that if Mozilla believed an incident resolved (or, as we've
> seen certain CAs do, the CA themselves mark their issue as resolved), that
> there's no requirement to disclose this to the auditor other than "Hope the
> CA is nice" (which, sadly, is not reasonable).
>
> I explicitly think incident is the right approach, and disagree that
> flagging it as compliance bugs is good or useful for the ecosystem. I
> further think that even matters flagged as "Duplicate" or "Invalid" _are_
> useful to ensure that the auditor is aware of the relevant discussion. For
> example, if evidence contrary to the facts stated on the bug (i.e. it was
> *not* a duplicate), this is absolutely relevant.
>
> So I guess I'm disagreeing with Jeff and Clemens here, by suggesting that
> incident should be any known or reported violation of Mozilla policy, which
> may be manifested as bugs, in order to ensure transparency and confirmation
> that the auditor had the necessary information and facts available and that
> it was considered as part of the statement. This still permits auditors to,
> for example, consider the issue as a duplicate/remediated, but given that
> the whole goal is to receive confirmation from the auditors that they were
> aware of all the same things the community is, I don't think the proposed
> language gets to that.
>
___
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 #187: Require disclosure of incidents in Audit Reports

[Ben Wilson via dev-security-policy]

I'm fine with that suggestion.

On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy <
dev-security-policy@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-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 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

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 hypothe

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