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

All, This mozilla.dev.security.policy group has been moved to dev-security-policy in Mozilla’s Google Workspace (formerly GSuite). New Access Points: - Mailing List: dev-security-pol...@mozilla.org -- dev-security-policy@lists.mozilla.org will automatically forward to the new mailing list

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

All, I posted the first message to the new group, with subject "WELCOME to dev-security-policy". If you do not receive the welcome message to the new group, you can subscribe to it by sending an email to dev-security-policy+subscr...@mozilla.org or to me or Ben. You can update your user

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

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

Re: Summary of Camerfirma's Compliance Issues

, as they will continue to block certificates from the Camerfirma hierarchy. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1173547 [2] https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/iAUwcFioAQAJ On Thu, Jan 28, 2021 at 10:39 PM Eric Mill via dev-security-policy <

Mozilla Root Store Policy MRSP 2.7.1 Update

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

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

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.

Re: Prioritization of Root CA Inclusion Requests

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

Job/Job Posting: Chrome Root Program

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

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

All, The CCADB update has been completed, and the "UNDER CONSTRUCTION" notice will be removed today. There is still some cleanup that we will be doing, but you may proceed with using Audit Cases and Root Inclusion Cases now. Please let me know if you run into any problems with the CCADB.

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

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

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

All, We will be applying updates to CCADB Audit Cases and Root Inclusion Cases starting tonight, March 25, and expected to be completed the afternoon of March 29. We will post the following message on the CCADB home page while the updates are in progress. -- UNDER CONSTRUCTION: Audit

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

All, This mozilla.dev.security.policy mailing list has been running on ancient custom-patched mailman software since the early Mozilla days. As many of you are aware, there are limitations and sometimes loss of data with the old configuration, so we are migrating this list to be hosted as a

Prioritization of Root CA Inclusion Requests

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

Re: New intermediate certs and Audit Statements

On 3/24/21 5:32 AM, Rob Stradling wrote: On 9th July 2019, Kathleen wrote: I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit

Re: New intermediate certs and Audit Statements

ll expect CAs to "use the Public Comment field to indicate that the new certificate will be included in the next audit statements"? Or may we stop doing that now? Thanks. From: dev-security-policy on behalf of Kathleen Wilson via dev-security-policy S

Public Discussion of Asseco's Root Inclusion Request

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

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

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.

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

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 purp

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

Name or IPAddress in a SAN or commonName MUST have been validated within the prior 398 days. -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Ben Wilson via dev-security-policy Sent: Monday, March 8, 2021 6:38 PM To: mozilla-d

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

;> "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 Messag

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

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

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of March 2021 Audit Reminder Emails Date: Tue, 16 Mar 2021 19:02:12 + (GMT) Mozilla: Audit Reminder CA Owner: certSIGN Root Certificates: certSIGN ROOT CA Standard Audit:

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

On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Said "additional" confirmation email, addressed to the domain > administrator, informs them that [Applicant Data] has requested an SSL > certificate

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

> The reason we reject human error as a root cause, which you don't seem > to understand because you mention the engineers, is that failures are > NOT the fault of humans who make mistakes. They're the fault of the > system which failed to prevent the mistakes. > The mention of the engineers,

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

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

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

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

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

On Fri, 12 Mar 2021 04:57:56 -0800 (PST) Pablo D__az via dev-security-policy wrote: > [...] > > I completely agree that "Human error" is not an acceptable analysis, > and "training improvement" is not the optimal solution. We have > worked to apply as

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

Hello Andrew, I am very aware that in the past the CA has made errors and misissuance, I fully understand the context and the seriousness of the matter. As CA we understand that it makes no sense to rely on "nothing serious ever happened", and the correct thing is to assume the importance of

Re: Clarification request: ECC subCAs under RSA Root

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

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

On Wed, 10 Mar 2021 13:43:55 -0700 Ben Wilson via dev-security-policy wrote: > This is to announce the beginning of the public discussion phase of > the Mozilla root CA inclusion process for the ANF Secure Server Root > CA. I'd like to draw attention to the first misissuance mentioned

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

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

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

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 wa

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

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 certi

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

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

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

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

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

ocumentation of the audit team's qualifications (which may be > separate from the audit letter itself). > > Ben > > > <https://github.com/BenWilson-Mozilla/pkipolicy/commit/70db4d97f674807 > 5fa760555c1eabb81bd7914ee> > > > > On Mon, Feb 15, 202

Re: Clarification request: ECC subCAs under RSA Root

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

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

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

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

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

RE: Clarification request: ECC subCAs under RSA Root

an Sleevi via dev-security-policy > Sent: Wednesday, March 10, 2021 11:00 AM > To: pfuen...@gmail.com > Cc: Mozilla > Subject: Re: Clarification request: ECC subCAs under RSA Root > > I agree with Corey that this is problematic, and wouldn't even call it a best > practice/go

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

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

Re: Clarification request: ECC subCAs under RSA Root

for it), but as Corey points out, there are times where it's both necessary and good to have such chains. On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > My understanding is that neither the BRs or any Root Pro

Re: Clarification request: ECC subCAs under RSA Root

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

RE: Clarification request: ECC subCAs under RSA Root

ew root CA with a stronger key. For that reason, this illustrative control seems problematic. Thanks, Corey -Original Message- From: dev-security-policy On Behalf Of pfuen...--- via dev-security-policy Sent: Wednesday, March 10, 2021 4:17 AM To: Mozilla Subject: Clarification request: ECC su

Clarification request: ECC subCAs under RSA Root

Hello all, I'd have an open question about the possibility (from a compliance standpoint) of having an ECC 256 subordinate under an RSA 2048 Root. If I look at the WebTrust criteria, I can see this: 4.1.3 CA key generation generates keys that: a) use a key generation algorithm as disclosed

Synopsis of Proposed Changes to MRSP v. 2.7.1

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:

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

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

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

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

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

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

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

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

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

(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@lis

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

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

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

On Fri, Mar 05, 2021 at 08:46:26AM -0800, Bruce via dev-security-policy wrote: > At the beginning, I think that CAs will generate one or many keys, but > will not assign them to CAs. The gap period could be days to years. > Since the requirement says "from the time of CA key pair g

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

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

Re: Audit Reminders for Intermediate Certs

Forwarded Message Subject: Summary of March 2021 Outdated Audit Statements for Intermediate Certs Date: Tue, 2 Mar 2021 15:00:24 + (GMT) CA Owner: SECOM Trust Systems CO., LTD. - Certificate Name: JPRS Organization Validation Authority - G3 SHA-256 Fingerprint:

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

On February 4, 2021, the public discussion period [Step 4 of the Mozilla Root Store CA Application Process ] began on e-commerce monitoring’s inclusion request. No questions or concerns have been raised and there are no open action items for

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

On Fri, Feb 26, 2021 at 5:18 PM Ryan Sleevi wrote: > I do believe it's problematic for the OCSP and CRL versions of the > repository to be out of sync, but also agree this is an area that is useful > to clarify. To that end, I filed > https://github.com/cabforum/servercert/issues/252 to make

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

On Fri, Feb 26, 2021 at 6:01 PM Aaron Gable wrote: > On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi wrote: > >> You can still do parallel signing. I was trying to account for that >> explicitly with the notion of the “pre-reserved” set of URLs. However, that >> also makes an assumption I should

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

On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi wrote: > You can still do parallel signing. I was trying to account for that > explicitly with the notion of the “pre-reserved” set of URLs. However, that > also makes an assumption I should have been more explicit about: whether > the expectation is

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

On Fri, Feb 26, 2021 at 1:46 PM Aaron Gable wrote: > If we leave out the "new url for each re-issuance of a given CRL" portion > of the design (or offer both url-per-thisUpdate and > static-url-always-pointing-at-the-latest), then we could in fact include > CRLDP urls in the certificates using

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

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

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

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 n

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

On Fri, Feb 26, 2021 at 5:49 AM Rob Stradling wrote: > > We already have automation for CCADB. CAs can and do use it for > disclosure of intermediates. > > Any CA representatives that are surprised by this statement might want to > go and read the "CCADB Release Notes" (click the hyperlink when

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

der text: https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48 From: dev-security-policy on behalf of Ryan Sleevi via dev-security-policy Sent: 26 February 2021 06:02 To: Aaron Gable Cc: Ryan Sleevi ; mozilla-dev-security-p

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

On Thu, Feb 25, 2021 at 8:21 PM Aaron Gable wrote: > If I may, I believe that the problem is less that it is a reference (which > is true of every URL stored in CCADB), and more that it is a reference to > an unsigned object. > While that's a small part, it really is as I said: the issue of

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

Similarly, snipping and replying to portions of your message below: On Thu, Feb 25, 2021 at 12:52 PM Ryan Sleevi wrote: > Am I understanding your proposal correctly that "any published JSON > document be valid for a certain period of time" effectively means that each > update of the JSON

The Ace Care Center Team has received your request []

…….. Please do not reply to this email. …….. Hello from the Ace Care Center Team! Thank you for your recent request. Because of added safety measures for our employees due to Coronavirus and increased call center traffic, there may be delays

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

months (now through the end of August), which seems reasonable. Cheers! -Clint > On Feb 25, 2021, at 11:40 AM, Ben Wilson via dev-security-policy > wrote: > > Yes - I think we could focus on the domain validations themselves and allow > domain validations to be reused for 398 d

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

On Thu, Feb 25, 2021 at 2:29 PM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'd prefer that we tie this to a date related to when the domain > validations are done, or perhaps 2 statements. As it stands (and as others > have commented)

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

Hugely useful! Thanks for sharing - this is incredibly helpful. I've snipped a good bit, just to keep the thread small, and have some further questions inline. On Thu, Feb 25, 2021 at 2:15 PM Aaron Gable wrote: > I believe that there is an argument to be made here that this plan > increases

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

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 B

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

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

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

d 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

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

2021 at 9:53 AM Ryan Sleevi wrote: > > > On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Obviously this plan may have changed due to other off-list conversations, >> but I would like t

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

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

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

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

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

On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Obviously this plan may have changed due to other off-list conversations, > but I would like to express a strong preference for the original plan. At > the scale

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

f the MRSP which references it) to include specific requirements around the cache lifetime of the JSON document and the CRLs referenced within it. Thanks, Aaron On Wed, Feb 24, 2021 at 12:36 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, &g

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

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

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

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

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

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

Re: Questions About DigiCert .onion Certificate SubjectPublicKey Hash

This is already tracked as https://github.com/cabforum/servercert/issues/190 and is waiting the completion of SC41v2 in the CA/Browser Forum Server Certificate Working Group before working on (along with a cluster of related .onion fixes) On Thu, Feb 18, 2021 at 12:05 PM SXIA via dev-security

Questions About DigiCert .onion Certificate SubjectPublicKey Hash

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

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of February 2021 Audit Reminder Emails Date: Tue, 16 Feb 2021 20:01:02 + (GMT) Mozilla: Audit Reminder CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR) Root Certificates: SZAFIR ROOT CA2 Standard Audit:

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

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

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

On Mon, Feb 15, 2021 at 6:07 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, I hope you are not suggesting I am dodging you points. That would > be absurd. Let me use different words as comparable world seems to be > tripping you up.

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

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

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

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

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

On Monday, February 15, 2021 at 1:57:11 PM UTC-6, Ryan Sleevi wrote: > On Mon, Feb 15, 2021 at 2:03 PM Jeff Ward via dev-security-policy < > dev-secur...@lists.mozilla.org> wrote: > > > I wanted to clarify a couple of points. Firms must be independent to do >

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

On Mon, Feb 15, 2021 at 2:03 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I wanted to clarify a couple of points. Firms must be independent to do > audit/assurance work. If independence is impaired, for example, by one > person in the

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

On Thursday, February 11, 2021 at 12:41:44 PM UTC-6, Ben Wilson wrote: > All, > > I've modified the proposed change to MRSP section 3.2 so that it would now > insert a middle paragraph that would read: > > "A Qualified Auditor MUST have relevant IT Security experience, or have > audited a

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

1 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, &g

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

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

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

On Thu, 11 Feb 2021 15:12:46 -0500 Ryan Sleevi via dev-security-policy wrote: > So I'd say feel free to ask your question there, which helps make > sure it's answered before the issue is closed. Good point. In this case Arvid has clarified that in fact the ticket now has an updated sheet

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

rtificates 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@lis

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

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>

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

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

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

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

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

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

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

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

  1   2   3   4   5   6   7   8   9   10   >