Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses

Thanks for the comments received so far. I'd like to close discussion on this next Tuesday, 14-Dec-2021. Discussion of Issue #3 (discourage CA certificate renewal/modification and encourage new CAs for crypto agility) could be started in a new thread. We could also submit the issue on Github - see

Re: Public Discussion: Inclusion of Telia Root CA v2

t; other countries)? > > Thanks, > M.D. > > > Sent from my Galaxy > > > Original message > From: Ben Wilson > Date: 12/6/21 20:12 (GMT+02:00) > To: md > Cc: "dev-secur...@mozilla.org" > Subject: Re: Public Discussion:

Re: Public Discussion: Inclusion of Telia Root CA v2

ns, its not clear what is Telia? > > Actually the same clarification needed for all other countries listed in > the Bug. > > Thanks, > M.D. > > > > Sent from my Galaxy > > > Original message > From: Ben Wilson > Date: 12/1/21 17:16 (GMT+02

Re: Public Discussion of Netlock's Request for EV Enablement

of the Application Process] and that it is Mozilla’s intent to approve the inclusion request [Step 10]. This begins a 7-day “last call” period (through Dec. 9, 2021) for any final objections. Thanks, Ben On Thu, Nov 11, 2021 at 11:08 AM Ben Wilson wrote: > This is to announce the beginn

Public Discussion: Inclusion of Telia Root CA v2

period, which I’m scheduling to close on December 22, 2021. Sincerely yours, Ben Wilson Mozilla Root Program -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails fr

Root Replacement with digitalSignature Key Usage to Sign OCSP responses

All, This is a new thread that I'm branching off of the discussion that started here - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/K8NsiO-VCQAJ . Additional background for this new discussion can also be found here:

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

Thanks, Rob, for raising this issue here for discussion on the list. From a root program perspective, I think we will want to narrowly scope whatever we consider and decide. I'd also like to start a new discussion thread for the issues narrowly outlined therein. I'll attempt to paraphrase the

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

org/CA/Subordinate_CA_Checklist#Third-Party_Subordinate_CAs_that_are_not_Technically_Constrained), so I will continue making changes based on comments received. Thanks, Ben On Mon, Nov 15, 2021 at 3:21 PM Ben Wilson wrote: > Thanks, Wayne. I'll work on clarifying these points. > > On Thu, Nov 11,

Re: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB

All, I came across this section in the wiki that will need to be replaced - https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Non-disclosable_Intermediate_Certificates. Are there any convincing reasons for keeping the current policy of non-disclosure? Thanks, Ben On Thu, Nov 18, 2021 at 8:02

Re: [cabfpub] Draft Working Group Charter for Network Security WG

Hi Dimitris, Our IPR Policy is not perfect, so it doesn't have a solution for every possible scenario. It was written with a goal of balancing the interests of IP holders and the Forum membership. From the IPR Policy, "Working Groups will ordinarily not approve a Guideline if they are aware that

Policy 2.8: MRSP Issue #235: Require CCADB Disclosure of Full CRLs (or equivalent JSON array) for CRLite

All, This email introduces public discussion regarding a new requirement to be included in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8) Github Issue #235

Use of crt.sh ID in Incident Reports

All, In an incident report recently, there was discussion about the right way to report the certificates involved in the incident. See https://bugzilla.mozilla.org/show_bug.cgi?id=1736064 In section 5 of https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report, it currently says,

Re: Policy 2.8: Candidate Issues to Address in MRSP v. 2.8

ctices#Precertificates . Thanks, Ben On Mon, Oct 4, 2021 at 11:12 AM Kathleen Wilson wrote: > Hi Ben, > > I added one more for the CRLs section: > > + #235 <https://github.com/mozilla/pkipolicy/issues/235>- Add Policy > requiring Full CRLs (or equivalent JSON arr

Re: [cabfpub] Draft Working Group Charter for Network Security WG

I'd like to get two endorsers for this ballot, unless people feel that there are comments/concerns that still need to be resolved. On Mon, Nov 15, 2021 at 9:28 AM Ben Wilson via Public wrote: > I am striking the following from the proposal: "If the ballot to change > the NC

Re: Sysnet Global Solutions acquires SecureTrust

All, The discussion period has closed without comment. Since no concerns were raised, we will update our records in the CCADB. Thanks, Ben On Fri, Oct 29, 2021 at 2:31 PM Ben Wilson wrote: > This email from Andrea will begin a two-week public discussion period that > will end on Frid

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

gt;> subCA certificate, the requirement for a public discussion and approval for >> its replacement would likely be an impediment to the timely revocation and >> replacement process. >> >> >> >> Thanks, >> >> Corey >> >> >> >> *Fro

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

Thanks, Dimitris. I am trying to make as few changes as necessary to the current MRSP, and I am still considering your suggested reformatting of MRSP section 5.3.1. Meanwhile, I changed the "SHOULD" to "encourage," as you suggested. I also deleted the "not inconsistent" language so that the

Re: [cabfpub] Draft Working Group Charter for Network Security WG

l not enforcing all > Working Groups to adopt the updated Guideline, it just completes the IP > Review phase in the NetSec WG in a more effective/efficient way. > > > Dimitris. > > > -Tim > > *From:* Ben Wilson > *Sent:* Wednesday, November 10, 2021 10:31 AM > *To

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

nd approval for > its replacement would likely be an impediment to the timely revocation and > replacement process. > > > > Thanks, > > Corey > > > > *From:* Dimitris Zacharopoulos > *Sent:* Thursday, November 11, 2021 11:47 AM > *To:* Corey Bonnell ; Ben

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

On Thu, Nov 11, 2021 at 9:47 AM Dimitris Zacharopoulos wrote: > > Also, where would the information about the unconstrained external SubCAs > that have passed public discussion and have been approved or denied be > located? > > Thanks, > Dimitris. > There is a field in the CCADB for SubCAs that

Public Discussion of Netlock's Request for EV Enablement

ng to close on or about 2-December-2021. A representative of Netlock must promptly respond directly in the discussion thread to all questions that are posted. Sincerely yours, Ben Wilson Mozilla Root Program -- You received this message because you are subscribed to the Google Groups "dev-securi

Re: Public Discussion of Firmaprofesional's Inclusion Request

ctions. Thanks, Ben On Wed, Oct 20, 2021 at 11:12 AM Ben Wilson wrote: > 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) for Firmapro

Policy 2.8: MRSP Issue #230: Clarifying Trust Transfer

All, This email introduces a relatively minor change to be made in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8) This is Github Issue #230 .

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

cal capability and audit > requirements of the subordinate CAs. > > > > Is this an accurate read of the proposed language? > > > > Thanks, > > Corey > > > > *From:* dev-security-policy@mozilla.org *On > Behalf Of *Ben Wilson > *Sent:* Monday, November 1, 2021 2:58

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

be present." (I realize that this is slightly contradictory with 2 above.) I'll give everyone a week to make any additional comments. See https://github.com/BenWilson-Mozilla/pkipolicy/blob/Issue228-5/rootstore/policy.md (and please let me know if I've missed anything discussed). Thank

Re: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB

I will close discussion on this matter next Friday, 19-Nov-2021. Right now, I am leaning toward adopting the language presented below. On Tue, Nov 2, 2021 at 10:41 AM Ben Wilson wrote: > All, > > This email introduces another issue selected to be addressed in the next > version of

Re: Policy 2.8: MRSP Issue #129: Require non-discriminatory CA conduct

ity is violating the T but refuses to admit it, as the entity can >> claim they are exempt from revocation because they “agreed to the T”. >> That would be a very unfortunate circumstance. >> >> >> >> -Tim >> >> >> >> *From:* dev-security-

Re: [cabfpub] Draft Working Group Charter for Network Security WG

t is not allowed. Chartered Working > Groups have the necessary isolation from the Bylaws so that one CWG doesn't > affect the work of another CWG, so I'm afraid this language is inconsistent > with the current Bylaws. > > > Dimitris. > > Nov 10, 2021 05:20:40 Ben Wilson via Public

Re: [cabfpub] Draft Working Group Charter for Network Security WG

ps. While each working group does have its own unique needs > and needs to have the ability to maintain their own requirements, there are > lots of other cases beyond the NCSSRs where uniformity is more important, > and now that we’re close to having all the policies in 3647 format

Re: [cabfpub] Draft Working Group Charter for Network Security WG

f the > working groups. While each working group does have its own unique needs > and needs to have the ability to maintain their own requirements, there are > lots of other cases beyond the NCSSRs where uniformity is more important, > and now that we’re close to having all the policies in 364

Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB

e audit documentation.) Please provide any additional comments you may have regarding the requirement that CAs disclose all subordinate CAs, regardless of whether they are technically constrained. Thanks, Ben Wilson Mozilla Root Program Manager -- You received this message because you are

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

values that the CA is allowed to use, that are not inconsistent with id-kp-emailProtection, and that are documented in the CA’s CPS MAY be present On Mon, Nov 1, 2021 at 2:10 PM Ben Wilson wrote: > Thinking about this more, we will need to address this for SMIME, too. I > might need to pu

Re: Policy unclear for CA "TWCA Secure SSL Certification Authority"

plain your findings. Alternatively, you can post your findings here, and I will open the Bug in Bugzilla for you. Thanks, Ben Wilson On Mon, Nov 1, 2021 at 2:15 PM Oscar Koeroo wrote: > Ryan and Ben, > > Thank you for your thorough analyses in your replies. How do I best > proceed i

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

at 1:43 PM Ben Wilson wrote: > I could a parenthetical - (For Subordinate CA Certificates that will be > used to issue TLS certificates, the clientAuth EKU MAY be present.) > > On Mon, Nov 1, 2021 at 1:37 PM Ryan Sleevi wrote: > >> >> >> On Mon, Nov 1, 2021 a

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

I could a parenthetical - (For Subordinate CA Certificates that will be used to issue TLS certificates, the clientAuth EKU MAY be present.) On Mon, Nov 1, 2021 at 1:37 PM Ryan Sleevi wrote: > > > On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell > wrote: > >> > I'm accepting your suggestion and

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

ill relevant here, because Mozilla allows it for cross-certificates, > and so it's possible to construct a case where a TCSC is seen as a Cross > Certificate and that it's acceptable to Mozilla. It's almost certain that A > is the desired end state, and so it's just a question of whether to

Re: Policy 2.8: MRSP Issue #233: Wiki page documenting process for reviewing externally operated subordinate CAs

5G1bzOwZQ/m/v4i0_wj9BAAJ> > . > > Please provide any additional comments you may have regarding the review > and approval process for externally operated subordinate CAs. > > Thanks, > > Ben Wilson > Mozilla Root Program Manager > > > -- You received

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

xtended Key Usage (EKU) extension specifying the extended key usage(s) allowed for the type of end entity certificates that the subordinate CA is authorized to issue."? On Mon, Oct 25, 2021 at 11:19 AM Ben Wilson wrote: > Thanks, Ryan. > > On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi

Re: Policy unclear for CA "TWCA Secure SSL Certification Authority"

One of their CPSes says that Policy OID is for a "Device Certificate" (Assurance Level 2), which is separate than a TLS server certificate with an OID of 1.3.6.1.4.1.40869.1.1.21 (Assurance Level 3), both are very similar, but I don't know what the distinction is between the two types. On Mon,

Re: Sysnet Global Solutions acquires SecureTrust

This email from Andrea will begin a two-week public discussion period that will end on Friday, 12-November-2021. On Fri, Oct 29, 2021 at 1:57 PM Andrea Holland wrote: > [Posting for SecureTrust] > > All, > > There is an agreement in place for Sysnet Global Solutions to acquire > SecureTrust, a

[cabfpub] Draft Working Group Charter for Network Security WG

All, Here is a draft charter for a Network Security Working Group. Please provide your comments, and then we will finalize this work in the form of a Forum Ballot and Server Certificate WG Ballot. Thanks, Ben Overview In January 2013 the CA/Browser Forum’s “Network and Certificate System

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

equest will be approved. Thanks, Ben On Mon, Oct 4, 2021 at 3:00 PM Ben Wilson wrote: > *Summary of Discussion and Resulting Decisions or Action Items* > > Public discussion on the iTrusChina inclusion application began on April > 7, 2021.[1] iTrusChina is seeking inclusion of an R

Re: Policy 2.8: MRSP Issue #129: Require non-discriminatory CA conduct

what behavior this > proposal is intended to prevent. With examples, if possible. It might > make it easier to understand if anything ought to be done, and if so, > what language would be most appropriate. > > On Tue, Oct 19, 2021 at 4:54 PM Ben Wilson wrote: > > > > As an

Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs

Thanks, Ryan. On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi wrote: > > > On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson wrote: > >> I am proposing that we replace the sentence above with, "A technically >> constrained intermediate CA certificate uses a specific Extended

Public Discussion of Firmaprofesional's Inclusion Request

espond directly in the discussion thread to all questions that are posted. Again, this email begins a three-week public discussion period, which I’m scheduling to close on or about November 11, 2021. Sincerely yours, Ben Wilson Mozilla Root Program -- You received this message becau

Re: Policy 2.8: MRSP Issue #129: Require non-discriminatory CA conduct

terms and conditions". See https://github.com/BenWilson-Mozilla/pkipolicy/commit/fab61408608feed365a9446ac47560a34c06cf85 On Thu, Oct 7, 2021 at 6:06 PM Ben Wilson wrote: > All, > > This email is the first in a series of discussions concerning the next > version of the Mozilla R

Re: Policy 2.7.1: Published

Dear Sandor, I have added the new versions of the ETSI EN 411-1 and EN 411-2 to the CCADB. Thanks, Ben On Mon, Oct 18, 2021 at 11:44 AM dr. Szőke Sándor wrote: > Hi Ben, > > > > I hope that you are doing well. > > I would like to ask your help regarding an Audit Case. > > > > I got the

Re: Public Discussion of ISRG/Let's Encrypt's Inclusion Request

gi?id=1701317 [3] https://wiki.mozilla.org/CA/Application_Process#Process_Overview On Mon, Sep 20, 2021 at 11:13 AM Ben Wilson wrote: > A root inclusion request has been submitted by Internet Security Research > Group (Let’s Encrypt). This is to announce the beginning of the public > dis

Re: OCSP responder behavior for HTTP GET requests

Could this possibly be the same as the problem I'm encountering with OCSP response for the SERPRO test site (OCSP response not found) when I run this command? curl --verbose --url

Policy 2.8: MRSP Issue #129: Require non-discriminatory CA conduct

All, This email is the first in a series of discussions concerning the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8) Issue #129 in GitHub

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

, Sep 23, 2021 at 10:28 AM Ben Wilson wrote: > All, > I have completed an EV-Guidelines review [1] of iTrusChina's updated CPS, > v.1.4.7 [2]. > I will be closing public discussion and writing up a summary of the public > discussion. > Thanks, > Ben > [1] https://bugzilla.moz

Re: Policy 2.8: Candidate Issues to Address in MRSP v. 2.8

-browser-forum(140) certificate-policies(1)} (2.23.140.1). … Certificate Policy Identifier: 2.23.140.1.1 If the Certificate complies with these Requirements and has been issued and operated in accordance with the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validatio

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

All, I should have noted during public discussion that GTS was seeking enablement of both the websites and the email trust bits for the roots involved. I am re-opening public comment for another week until October 6 to gather any comments about this aspect of GTS' request. Thanks, Ben On Fri, Sep

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

; and summarize the public discussion, or ask follow-up questions, if >> necessary. >> Ben >> >> On Fri, Sep 10, 2021 at 2:57 PM Ben Wilson wrote: >> >>> All, >>> >>> In preparing my summary of the public discussion of iTrusChina's >&g

BR Self Assessment renamed to Compliance Self Assessment

All, I have updated the BR self-assessment template and renamed it to "Compliance Self Assessment" because now the self-assessment also references Mozilla's Root Store Policy and the EV Guidelines (when applicable). Here are the links to the updated page and the self-assessment template:

Public Discussion of ISRG/Let's Encrypt's Inclusion Request

2> Open 1729567 <https://bugzilla.mozilla.org/show_bug.cgi?id=1729567> Delay updating OCSP responses <https://bugzilla.mozilla.org/show_bug.cgi?id=1729567> Open Thus, this email begins a three-week public discussion period, which I’m scheduling to close on or about 11-October-2021. A rep

Re: Public Discussion of Chunghwa Telecom's Root Inclusion Request

at 11:00 AM Ben Wilson wrote: > I have reviewed the changes to Chunghwa Telecom's CP and CPS. Minor > amendments were made to CP Sections 6.6.2 and 8. Other changes were made to > the CPS to change some terminology, to clarify actual validation and > CAA-checking practices, and to up

Re: Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

On August 25, 2021, we began a three-week public discussion[1] on GTS’ request to replace 5 GTS root CA certificates.[2] (Step 4 of the Mozilla Root Store CA Application Process[3]). *Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:* On 31-Aug-2021, Andrew

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

and summarize the public discussion, or ask follow-up questions, if necessary. Ben On Fri, Sep 10, 2021 at 2:57 PM Ben Wilson wrote: > All, > > In preparing my summary of the public discussion of iTrusChina's > application for inclusion of its RSA and ECC roots with the websites trust >

Re: Public Discussion of Chunghwa Telecom's Root Inclusion Request

I have reviewed the changes to Chunghwa Telecom's CP and CPS. Minor amendments were made to CP Sections 6.6.2 and 8. Other changes were made to the CPS to change some terminology, to clarify actual validation and CAA-checking practices, and to update the CPS to comply with CABF Ballot SC48. See

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

e, Sep 7, 2021 at 9:28 PM Ben Wilson wrote: > All, > > My review of CPS v. 1.4.6 and other comments appear inline below. > > On Wed, Aug 25, 2021 at 12:48 AM yutian zheng > wrote: > >> Hi Ryan, >> >> Thank you very much for these questions, and we have che

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

All, My review of CPS v. 1.4.6 and other comments appear inline below. On Wed, Aug 25, 2021 at 12:48 AM yutian zheng wrote: > Hi Ryan, > > Thank you very much for these questions, and we have checked our CP/CPS > and corresponding business for these items, the answers are as follows: > > *1.

[elixir-core:10421] Re: Proposal: built-in DynamicSupervisor partitioning

Implemented this way, options like max_restarts max_children and so on would occur per partition. I take it the plan would be to simply note that in the docs? I don't see any easy way to enforce those values across all partitions, which I think is just fine. which_children/1 and so on won't

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

n, it notes that one of the sources is the >> Unified Social Credit Code Certificate. It also lists Dun and Bradstreet as >> a source, which is highly questionable with respect to EV certificates and >> the use of qualified information sources. >> >> Andrew previously not

Public Discussion of Google Trust Services' Request to Replace Root CA Certificates

are posted. Sincerely yours, Ben Wilson Mozilla Root Program -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+uns

Re: Public Discussion re: Inclusion of the TunTrust Root CA

?id=9228562 [11] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/0FN9hAYkAgAJ On Wed, Aug 11, 2021 at 2:40 PM Ben Wilson wrote: > All, > > For your review, here is my own, abridged version of TunTrust’s value > justification. > > See https://w

Re: Public Discussion of Chunghwa Telecom's Root Inclusion Request

All, I will leave the public discussion phase open in order for Chunghwa Telecom to provide an updated CPS. Ben On Tue, Aug 24, 2021 at 10:16 AM Li-Chun CHEN wrote: > Hi, Andrew, > > We have implemented the automatic domain validation functionality to > our RA system to prevent a high

Policy 2.8: Candidate Issues to Address in MRSP v. 2.8

All, Below are listed the Mozilla Root Store Policy (MRSP) issues currently slated to be addressed in the next version (2.8) of the MRSP. (In GitHub, related to the MRSP, there are currently 58 issues and 2 pull requests: https://github.com/mozilla/pkipolicy

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

ntrol refers to BR >> Chapter 5, including physical control, program control, personnel control, >> audit log program and other dimensions, and meets the WT audit >> requirements. iTC also follows the Chinese Ministry of Industry and >> Information Technology and the State Cryptograph

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

Sincerely yours, Ben On Tue, Aug 10, 2021 at 9:20 AM Ben Wilson wrote: > All, > Are there any additional comments? > Thanks, > Ben > > On Sun, Jul 4, 2021 at 7:11 PM yutian zheng > wrote: > >> Hi All， >> >> iTrusChina submitted a document to

Re: Public Discussion re: Inclusion of the TunTrust Root CA

All, For your review, here is my own, abridged version of TunTrust’s value justification. See https://wiki.mozilla.org/CA/Quantifying_Value and https://bugzilla.mozilla.org/attachment.cgi?id=9226817 . *Ownership and Management Structure* The beneficial owner of the TunTrust Root CA is the

Re: Public Discussion re: Inclusion of the iTrusChina Root CAs

; specific time to focus on just a single CA. >>> >>> It's an entirely reasonable goal, but the effect of running these in >>> parallel does not mean both CAs undergo three weeks of review; it means >>> both CAs undergo a week and a half, or less, since these

Re: Public Discussion re: Inclusion of the TunTrust Root CA

All, Are there any further comments? Ben On Mon, Aug 9, 2021 at 11:12 AM Syrine Tlili wrote: > > Hi: > > Our inclusion request has been in public discussion since April 7. > We have provided all requested information as a first-time root inclusion > applicant. > Kindly, we would like to move

Public Discussion of Chunghwa Telecom's Root Inclusion Request

plying under the subject heading above. A representative of Chunghwa Telecom must promptly respond directly in the discussion thread to all questions that are posted. Again, this email begins a three-week public discussion period, which I’m scheduling to close on August 24, 2021. Sincerely yours,

Re: [cabfpub] Code signing and Time stamping

Just a few thoughts to move this conversation forward, and speaking as a CSCWG interested party and not to advocate any position of Mozilla, I think the answer depends on how strict or flexible the CABF wants to be as an organization when it comes to interpreting the scope of a working group

Re: [elixir-core:10200] Proposal: Warn on duplicated specs

Right, and this is why I think Jose is arguing that this is a job for Dialyzer. The only way to know that two specs are duplicate is if they are logically duplicate. Elixir does not know about the logic of specs today, that's dialyzer's job. eg: @type one :: 1 @spec foo(1) :: "one" @spec

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

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

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)

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

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 request

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

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

Public Discussion of Asseco's Root Inclusion Request

, misissuances, and EV compatibility, and they passed those tests. Thus, this email begins a three-week public discussion period, which I’m scheduling to close on or about Wednesday, 14-April-2021. A representative of Asseco must promptly respond directly

Re: [elixir-core:10160] Ranges with steps

The 1..9//2 structure feels like the best of the presented options to me. I think it reads well out loud, since .. often means "to" and / is often rendered as "by" so that would read 1 to 9 by 2. To make sure I'm clear about the semantics: If I have: ``` 1..x//1 |> Enum.to_list ``` Then if

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

gt;> >> >> 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: T

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 wrote: > That works, too. Thoughts? > > On Tue, Mar 16, 2021 a

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: [elixir-core:10121] [Proposal] range pattern matching in case without when

I think eksperimental was dead on when he said what you really want is `cond`. ``` cond do val in ?a..?z val in ?A..?Z ``` Changing `case` to have an implicit `where` in certain special cases is going to make it behave inconsistently compared to other places that take patterns. Optimizing the

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

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 bee

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

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

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

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

-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

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

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,

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

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

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

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

, 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

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

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

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

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

<    1   2   3   4   5   6   7   8   9   10   >