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

[Ben Wilson via dev-security-policy]

On March 10, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store CA Application Process
] for ANF’s inclusion
request.

One commenter recounted some of ANF's certificate misissuance events and
expressed concern that CAs trusted in the Mozilla program must provide
"assurance to its users that they won't be harmed by the CA" and "a CA
which has lax technical controls, a poor understanding of PKI, and an
inability to learn from and improve when mistakes are made is at heightened
risk of exploitation by malicious actors that would harm Mozilla users."  ANF
responded

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

.

Another community member asked about ANF's explanations of its domain
validation procedures and possible gaps / insecure implementations in those
domain validation processes.  ANF responded

to those questions and provided clarifications about its use of additional
mechanisms to address those potential gaps, including CAPTCHA, email
address construction, and use of random values.

Based on this review of the public discussion, I do not believe there are
any open action items for ANF to complete under Steps 5-8 of the
application process.

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

This begins a 7-day “last call” period (through April 8, 2021) for any
final objections.

Thanks,

Ben

On Wed, Mar 17, 2021 at 12:45 PM Pablo Díaz via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > - Sending a link that must be accessed to approved is known-insecure, as
> > automated mail scanning software may automatically dereference links in
> > e-mail (in order to do content inspection). Confirm/Reject buttons alone
> > shouldn't be seen as sufficient to mitigate this, as that may vary based
> on
> > how the crawler works. Requiring explicit entry of the random value is a
> > necessary "human" measure (aka similar to a CAPTCHA)
>
> We do actually have a CAPTCHA above the [CONFIRM] / [REJECT] buttons,
> which must be filled before proceeding. Is this not considered sufficient?
> I wonder because I have recently seen this same email DCV method process
> in other CAs (link that must be accessed to approve), and no captcha nor
> explicit entry of the random value is required; just “approve” button (not
> even “reject”).
> If it was deemed necessary, instead of including the RV in the link, we
> could include the RV in the email, and require the applicant explicitly
> enter this RV in the webpage.
>
> > - You haven't described how the email address is constructed for these
> > cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2,
> and
> > if and only if the domain contact is the same for all of the requested
> > domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it
> > would be inappropriate if hostm...@apex1.example could approve a
> request
> > for apex2.example, yet, as currently described, that seems to be
> possible,
> > in that both hostm...@apex1.example and hostm...@apex2.example will
> > receive the same Request ID to approve/reject the request.
>
> For *each* of the domains to be included in the certificate, a email for
> DCV purpose has to be chosen from the ones the system automatically lists:
> 1) Constructed emails, using admin@, administrator@, webmaster@,
> hostmaster@, or postmaster@ + apex domain. (method 3.2.2.4.4)
> 2) Result of the WHOIS lookup previously made, for the “technical
> contact”, or “administrative contact” (method 3.2.2.4.2). The WHOIS lookup
> is performed automatically by making a query to the whois service
> corresponding to the tld. This method can only be used when there is public
> information available and the registrar/WHOIS provider has not masked it,
> otherwise, this option is not available.
>
> We do not reuse the Random Value. Each DCV email receives an independent
> email with a unique RV.
>
> Following your example, let the domains be apex1.example, apex2.example,
> and apex3.example. It would show 3 dropdown lists (one for each domain)
> with the emails to choose form:
> · apex1.example:   acceptable emails as listed above. - e.g. Chosen email
> is hostmaster @apex1.example
> · apex2.example:   acceptable emails as listed above. - e.g. Chosen email
> is admin @apex2.example
> · apex3.example:   acceptable emails as listed above. - e.g. Chosen email
> is webmaster 

Mozilla Root Store Policy MRSP 2.7.1 Update

[Ben Wilson via dev-security-policy]

All,

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

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

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

Thanks,

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

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

[Ben Wilson via dev-security-policy]

All,

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

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

Please also let me know if you have any questions.

Thanks,

Ben

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

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

Re: Prioritization of Root CA Inclusion Requests

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

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

Prioritization of Root CA Inclusion Requests

[Ben Wilson via dev-security-policy]

All,

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

Thanks,

Ben

---

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

   -

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


   -

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


   -

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


   -

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


   -

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

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

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

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

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

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

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

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


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

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


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

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

Public Discussion of Asseco's Root Inclusion Request

[Ben Wilson via dev-security-policy]

l-2021.



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



Sincerely yours,

Ben Wilson

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

That works, too.  Thoughts?

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

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

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

[Ben Wilson via dev-security-policy]

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



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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

Here you go:

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

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

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

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

All,

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

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

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

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

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

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

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

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

*Root Certificate Information:*

ANF Secure Server Root CA

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

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



*CP/CPS:*

Current CP is Version 3.3.1 / January 8, 2021

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

Current CPS is Version 31 /  February 1, 2021

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

Repository location:

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



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

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

*Audits:*

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


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

*Incidents: *

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

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

We encourage you to participate in the review and discussion.

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

Sincerely yours,

Ben Wilson

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

Synopsis of Proposed Changes to MRSP v. 2.7.1

[Ben Wilson via dev-security-policy]

All,


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


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


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


Thanks for your contributions.


Sincerely yours,


Ben


--


#130 resolved - updates required to current audit versions

References to updated audit criteria are found here:

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


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

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


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

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

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

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

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

Resolved with:

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

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


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

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

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

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

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


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

Resolved with:

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

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


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

Resolved with:

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

https://github.com/BenWilson-Moz

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

All,

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

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

Ben

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

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

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

[Ben Wilson via dev-security-policy]

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


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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

<https://github.com/BenWilson-Mozilla/pkipolicy/commit/a69aa03fb92d1b0c3f74fd560dffefdeed934b45>

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

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

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

[Ben Wilson via dev-security-policy]

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


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

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

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

[Ben Wilson via dev-security-policy]

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


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

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

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

[Ben Wilson via dev-security-policy]

On February 4, 2021, the public discussion period [Step 4 of the Mozilla
Root Store CA Application Process
<https://wiki.mozilla.org/CA/Application_Process>] began on e-commerce
monitoring’s inclusion request.

No questions or concerns have been raised and there are no open action
items for e-commerce monitoring to complete under Steps 5-8 of the
application process.

This is notice that I am closing the public discussion period [Step 9] and
that it is Mozilla’s intent to approve e-commerce monitoring’s request for
inclusion [Step 10].

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

Thanks,

Ben

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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

All,

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

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

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


Ben

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

> All,
>
> I have started a similar, simultaneous discussion with the CA/Browser
> Forum, in order to gain traction.
>
> <http://goog_583396726>
>
> 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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

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

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

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

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

[Ben Wilson via dev-security-policy]

All,

I have edited the proposed resolution of Issue #192

as follows:

Subsection 3 of MRSP Section 3.1.4. would read:

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

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

Section 3.2 would read:

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

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

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

Ben





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

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

Re: 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
>> > > <https://github.com/mozilla/pkipolicy/issues/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 b

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 

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

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

<https://github.com/BenWilson-Mozilla/pkipolicy/commit/57063dc07f5b753184c94dbf5d0d30d0b9b90789>
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

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: 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
>> <https://wiki.mozilla.org/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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> – the
>> relevant issuing CAs have been revoked (nearly closed, waiting on a final
>> key destruction report)
>>
>> 1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> - SHA-256
>> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>>
>> 1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> – Empty
>> SingleExtension in OCSP responses (migration to new OCSP responders nearly
>> completed)
>>
>> 1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=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
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while two
>>>> other roots are for email authentication, RSA and ECC (Bugzilla Bug #
>>>> 1637269 <https://bugzilla.mozilla.org/show_bug.cgi?id=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

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
> <https://wiki.mozilla.org/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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> – the
> relevant issuing CAs have been revoked (nearly closed, waiting on a final
> key destruction report)
>
> 1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> - SHA-256
> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>
> 1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> – Empty
> SingleExtension in OCSP responses (migration to new OCSP responders nearly
> completed)
>
> 1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=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
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while two other
>>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=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
&g

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
<https://bugzilla.mozilla.org/show_bug.cgi?id=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

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

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
<https://wiki.mozilla.org/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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> – the
relevant issuing CAs have been revoked (nearly closed, waiting on a final
key destruction report)

1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> - SHA-256
hash algorithm used with ECC P-384 key (almost closed, status update needed)

1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> – Empty
SingleExtension in OCSP responses (migration to new OCSP responders nearly
completed)

1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=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
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while two other
>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=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://ww

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
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while two other
> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
> <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944>
>
> Empty SingleExtension in OCSP responses
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944>
>
> 1651447 <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447>
>
> Failure to revoke noncompliant ICA within 7 days
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447>
>
> 1591005 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005>
>
> ICAs in CCADB, without EKU extension are l

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

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

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

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]

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

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 <https://github.com/mozilla/pkipolicy/issues/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
> > <https://github.com/mozilla/pkipolicy/issues/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 #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 #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: 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 #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 unde

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

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 <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
> <https://github.com/mozilla/pkipolicy/issues/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

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

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
> > > <https://github.com/mozilla/pkipolicy/issues/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 loc

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

[Ben Wilson via dev-security-policy]

h US country code and invalid State/Prov
<https://bugzilla.mozilla.org/show_bug.cgi?id=1575880>



No misissuances were found under these roots, and the CA certificates
passed technical tests.

Thus, this email begins a three-week public discussion period, which I’m
scheduling to close on or about Tuesday, 2-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

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

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
<https://github.com/mozilla/pkipolicy/issues/211>.

Effective September 30, 2020, as a result of the Browser Alignment Ballot
<https://cabforum.org/2020/07/16/ballot-sc31-browser-alignment/>, section
4.9.10 of the CA/Browser Forum’s BaselineRequirements
<https://cabforum.org/baseline-requirements-documents/> (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
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation>
(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 #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

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

On November 17, 2020, the public discussion period [Step 4 of the Mozilla
Root Store CA Application Process
<https://wiki.mozilla.org/CA/Application_Process>] began on FNMT’s
inclusion request.

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

On November 18, 2020, FNMT clarified that it is audited to both ETSI EN 319
411-2 and ETSI 319 411-1.

Also, on that day, a comment was received with the following observations:

(1) certificate profiles could not be located for review - as indicated
subsequently in the thread, FNMT provided links to the certificate profiles
for end entity certificates;

(2) cross-references to a document called the “DGPC” were difficult to
follow - an overall comment was that FNMT’s Certification Practices
Statement (CPS) was confusing with its numerous cross-references to its
DGPC (CPS for its Root CA). FNMT republished its CPS with these
cross-references removed and replaced them with applicable text.  There
were also references to the "DPPP" (FNMT’s CPS), which were replaced by
“CPS”;

(3) there were numerous observations about the CPS (e.g. it lacked a
commitment to communicate back to third parties within 24 hours of
receiving a Certificate Problem Report, etc.) - see
https://groups.google.com/g/mozilla.dev.security.policy/c/T5bYrPznCXQ/m/Rv4ddGh6BQAJ,
and the subsequent response from FNMT, and my similar summary of these
issues in this thread; and

(4) a final suggestion was “[to] have them compare [the CPS] side-by-side
with the BR, and have it at least document their commitment to each of the
baseline requirements explicitly in their CPS”.  FNMT responded, “We have
updated a new BRs Self-Assessment document with CPS v1.6:
https://bug1559342.bmoattachments.org/attachment.cgi?id=9189942”.  I
believe that the BR self-assessment serves this purpose.

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

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

Thanks,

Ben

On Wed, Dec 9, 2020 at 12:09 PM Ben Wilson  wrote:

> Just a reminder - today, the public discussion period will close and then
> I'll be preparing a summary of the discussion.  In addition to reviewing
> FNMT's response of 27-November, I also reviewed the CPS v. 1.6 and make the
> following observations:
> Matthias van de Meent wrote:
>
> 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.
>
> I was able to review the end entity certificate profiles at
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> and
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>
> 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.
>
> I noticed that the acronym "DPPP" has been replaced with "CPS" and that
> language from the "DGPC" has been copied into the CPS.
>
> CPS s4.9.2 and s1.5.2 both mention that third parties may send certificate
> problem reports, and select parties may send revocation requests, which
> is great; but I cannot find a commitment to communicating a preliminary
> report within 24 hours to the reporter as stipulated by BR 4.9.5.
>
> CPS section 4.9.5 now states that "Within 24 hours after receiving a CPR,
> the CA will investigate the facts and circumstances related to the CPR and
> provide a preliminary report to both the Subscriber and the entity who
> filed the CPR."
>
> CPS / DGPC s5.2.2 includes by reference an internal policy, which may or
> may not comply with the "at least dual control for CA private key 
> backup/storage/recovery"
> requirement of BR 5.2.2.
>
> CPS section 5.2.2 now states, "The FNMTs Private Key are backed up,
> stored, and recovered only by personnel in trusted roles using, at least,
> dual control in a physically secured environment."
>
> CPS / DGPC s5.3.1 only guarantee the "ex

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

[3]
and may add requirements, but those requirements need not meet the baseline
of the BR.

CPS Section 6.1.1.1 now specifies, "Following this procedure, the FNMT-RCM
will prepare and follow a Key Generation Script, have a Qualified Auditor
witness the CA Key Pair generation process, and have a Qualified Auditor
issue a report opining that the CA followed its key ceremony during its Key
and Certificate generation process and the controls used to ensure the
integrity and confidentiality of the Key Pair."

CPS s6.2 points to a section s6.2 in the DGPC, which is blank. Therefore,
I'm missing the documentation on that the CA is committed to securing the
CA private key material in a BR-compliant manner.

Section 6.2 now states, "FNMT-RCM shall protect its Private Key(s) in
accordance with the provisions of this CPS and in a compliance with
CA/Browser Forum's Baseline Requirements"

CPS / DGPC s6.2.4 does not apply the requirements of BR 6.2 nor 5.2.2 to
their private key backup procedure.

Section 6.2.4 of the CPS now states, "Backup copies of CA Private Keys
shall be backed up by multiple persons in Trusted Role position sand only
be stored in encrypted form on cryptographic modules that meet the
requirements specified in Section 6.2.1."

CPS delegates s6.2.5 fully to the DGPC, but that s6.2.5 requires the CPS to
at least specify a maximum number of copies of the private key, which is
not specified.

Section 6.2.5 now states, "Only the FNMT-RCM may make a backup of the
Private keys, guaranteeing that the security level of the copied data is at
least equal to that of the original data and that the number of data
duplicated does not exceed the minimum necessary to assure service
continuity. The Signature creation data are not duplicated for any other
purpose."

CPS / DGPC s6.2.6 has the interesting construction "Consequently, the Keys
cannot be transferred, although there is a recovery procedure", which
implies a procedure to extract and transfer keys exists.

CPS Section 6.2.6 now states, "The Certification Authorities’ Private keys
are generated as described in point “6.1 Key generation and installation”.
In the 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:
> > >
> > > Matthia

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

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

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

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

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

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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1626805>.
>
> *Incident Reports / Mis-Issuances *
>
> *The following bugs/incidents (closed) have been reported. *
>
> Bug 1495507 <https://bugzilla.mozilla.org/show_bug.cgi?id=1495507> (filed
> 10/1/2018) OU field exceeding 64 characters
>
> Bug 1544586 <https://bugzilla.mozilla.org/show_bug.cgi?id=1544586> (filed
> 4/15/2019) 2019 audit findings
>
> Bug 1596949 <https://bugzilla.mozilla.org/show_bug.cgi?id=1596949> (filed
> 11/15/2019) CP/CPS lack CAA processing details
>
> Bug 1626805 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 c

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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1626805>.

*Incident Reports / Mis-Issuances *

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

Bug 1495507 <https://bugzilla.mozilla.org/show_bug.cgi?id=1495507> (filed
10/1/2018) OU field exceeding 64 characters

Bug 1544586 <https://bugzilla.mozilla.org/show_bug.cgi?id=1544586> (filed
4/15/2019) 2019 audit findings

Bug 1596949 <https://bugzilla.mozilla.org/show_bug.cgi?id=1596949> (filed
11/15/2019) CP/CPS lack CAA processing details

Bug 1626805 <https://bugzilla.mozilla.org/show_bug.cgi?id=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: 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

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: 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 #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 <https://github.com/mozilla/pkipolicy/issues/186>
> > 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 <https://github.com/mozilla/pkipolicy/issues/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

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

10/6/2020; no comments yet

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

10/6/2020; no comments yet

#152 <https://github.com/mozilla/pkipolicy/issues/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 <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.

10/15/2020; comments

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

10/22/2020; no comments yet

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

10/28/2020; no comments yet

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

10/28/2020; comments

#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;”

10/22/2020; comments

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

11/3/2020; comments

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

11/5/2020; no comments yet

#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;”

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

#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

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

#211 <https://github.com/mozilla/pkipolicy/issues/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 <https://github.com/mozilla/pkipolicy/issues/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 discu

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

This email closes public discussion and is notice that it is Mozilla’s
intent to approve NAVER's request for inclusion. (This starts a 7-day
period of last call for objections.)

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

> Step 6 of CA Application Process
> <https://wiki.mozilla.org/CA/Application_Process>:  *Summary of
> Discussion and Resulting Decision:*
>
> One commenter stated that it appeared that a few certificates were
> misissued, i.e. that the stateOrProvinceName field (“S” field) should
> probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city.  A
> NAVER representative responded that it had fixed the DN structure with L
> equal to "Seongnam-si" as city name and S field as "Gyeonggi-do" for
> province name.  NAVER also added a procedure, in compliance with ISO
> 3166-2, to put province information correctly in the S field of user DN for
> newly issued certificates.
>
> A second commenter noted that: (1) wording in the CPS could allow NAVER to
> avoid revoking problematic certificates by relying on Korean law; (2)
> “relevant legislation” was not referenced in
> sections 9.14 and 9.16.3 as required by BR section 9.16.3; and (3) the
> list of events logged did not include "All verification activities" as
> required by BR section 5.4.1(2).
>
> Responses to the foregoing included the following: (1) a certificate not
> revoked because of Korean law would be a BR violation and the CA would be
> required to previously disclose this according to BR section 9.16.3 (the
> conflicting requirement could be modified “to the minimum extent necessary
> to make the requirement valid and legal” and the CA would have to notify
> the CA/Browser Forum of such practice change so that the Forum could react
> appropriately. NAVER also stated, “we found that there are no South Korea’s
> laws and regulations which affect or refuse the revocation of certificates
> that violated the BRs issued by a commercial CA”.  (2) A third commenter
> stated, “Note that, in this case, the particular language you're concerned
> about is part of the BRs themselves, in 4.9.5. However, this is about
> ‘when’ to revoke.  I think you raise an interesting point that would
> benefit from clarification from NAVER, because I think you're correct that
> we should be concerned that the shift from ‘when’ to revoke has become
> ‘whether’ to revoke, and that is an important difference.” As a result of
> these comments, NAVER amended sections 4.9.5, 9.14, and 9.16.3.
>
> Section 4.9.5 of the NAVER CPS now reads, “The period from receipt of the
> Certificate Problem Report or revocation-related notice to published
> revocation must not exceed the time frame set forth in Section 4.9.1.1. The
> date selected by NAVER Cloud will consider the following criteria: …
> Relevant legislation.”
>
> Section 9.14 of the NAVER CPS now states, “This CPS is governed, construed
> and interpreted in accordance with the laws of Republic of Korea. This
> choice of law is made to ensure uniform interpretation of this CPS,
> regardless of the place of residence or place of use of NAVER Cloud
> Certificates or other products and services. The law of Republic of Korea
> applies also to all NAVER Cloud commercial or contractual relationships in
> which this CPS may apply or quoted implicitly or explicitly in relation to
> NAVER Cloud products and services where NAVER Cloud acts as a provider,
> supplier, beneficiary receiver or otherwise.”
>
> (Note that section 1.1 of the NAVER CPS states, “In the event of any
> inconsistency between this CPS and the Baseline Requirements, the Baseline
> Requirements take precedence over this document.”)
>
> Section 9.16.3 has been amended by adding a paragraph reading, “In the
> event of a conflict between CABF Baseline Requirements and a law,
> regulation or government order (hereinafter ‘Law’) of any jurisdiction in
> which a CA operates or issues certificates, NAVER Cloud modifies any
> conflicting requirement to the minimum extent necessary to make the
> requirement valid and legal in the jurisdiction. This applies only to
> operations or certificate issuances that are subject to that Law. In such
> event, NAVER Cloud immediately (and prior to issuing a certificate under
> the modified requirement) includes in Section 9.16.3 of this CPS a detailed
> reference to the Law requiring a modification of these Requirements under
> this section, and the specific modification to these Requirements
> implemented by NAVER Cloud.”
>
> (3) Section 5.4.1 now states that “NAVER Cloud records at least the
> following events:  … 2. Subscriber Certificate lifecycle management
> events, including:  … b. All verification activities stipulated in th

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]

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

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
> > <https://www.mozilla.org/about/forums/#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 

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
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation>.


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
<https://groups.google.com/g/mozilla.dev.security.policy/c/DeztURyCHPo/m/1IZnDsMuAQAJ>
this past year.

According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements
<https://cabforum.org/baseline-requirements-documents/>, 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 <https://problemreport.digicert.com/key-compromise/report>
and Sectigo <https://secure.sectigo.com/products/RevocationPortal>) 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 <https://github.com/mozilla/pkipolicy/issues/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
<https://tools.ietf.org/html/rfc3647#section-6> 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

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

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

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

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

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

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

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

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

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

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

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

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

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