Re: Policy 2.8: Final Review of MRSP v. 2.8

corresponding certificate" > (and also about a certificate and its "corresponding precertificate"). > > Even though there are no deployments of RFC9162 at this time (AFAIK), I > think it's reasonable to consider RFC9162's terminology as > "industry-accepted". > &

Re: Policy 2.8: Final Review of MRSP v. 2.8

See an additional comment below: On Tue, Apr 19, 2022 at 2:11 PM Ben Wilson wrote: > See responses below. > > On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos > wrote: > >> >> Hi Ben, >> >> Here are the comments from the HARICA

Re: Policy 2.8: Final Review of MRSP v. 2.8

See responses below. On Tue, Apr 19, 2022 at 2:56 AM Dimitris Zacharopoulos wrote: > > Hi Ben, > > Here are the comments from the HARICA team: > > > ### 5.4 Precertificates ### > *Certificate Transparency precertificates are considered by Mozilla to be > a binding intent to issue a certificate,

Re: Policy 2.8: Final Review of MRSP v. 2.8

licy/compare/master...BenWilson-Mozilla:2.8#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6R741 > > > > > > *From:* dev-security-policy@mozilla.org *On > Behalf Of *Ben Wilson > *Sent:* Wednesday, April 13, 2022 1:18 PM > *To:* dev-secur...@mozilla.org > *Subject:* Policy 2.8: Final Review of MR

Re: Policy 2.8: Final Review of MRSP v. 2.8

d, thanks! > > Regards, > Andrew > > On Thu, 14 Apr 2022 13:28:13 -0600 > Ben Wilson wrote: > > > Thanks, Andrew > > > > Would this address your comments? > > > > 5.4 Precertificates > > > > Certificate Transparency precertificates are

Re: Policy 2.8: Final Review of MRSP v. 2.8

cy/c/Co65loD9i-0/m/Trt4N9QQAgAJ > > Regards, > Andrew > > On Wed, 13 Apr 2022 11:18:24 -0600 > Ben Wilson wrote: > > > All, > > > > Here are links helpful during your final review of version 2.8 of the > > Mozilla Root Store Policy (MRSP) : > > > > &g

Policy 2.8: Draft April 2022 CA Communication Survey

All, Below is a draft survey about Mozilla Root Store Policy v. 2.8 that I will be sending through the CCADB mailer to all CAs in the Mozilla program. I also have a cover letter for the CA communication, which is boilerplate similar to that used in previous CA communications - see e.g.

Policy 2.8: Final Review of MRSP v. 2.8

All, Here are links helpful during your final review of version 2.8 of the Mozilla Root Store Policy (MRSP) : https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 (redlined) Please review the

Re: DRAFT of New Policy and Process for Externally-operated Subordinate CAs

, Apr 6, 2022 at 5:01 PM Ben Wilson wrote: > Hi all, > > We think we have addressed all of your comments in edits that we've made > to the following two documents: > > Proposed edits to MRSP section 8.4 - > > https://docs.google.com/document/d/1MY_0t-gOhhvP_D0YbhOHf0HstLds

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

All, Here is an edit I've made: https://github.com/BenWilson-Mozilla/pkipolicy/commit/b897f32c9f542011e846438418490a3f39beacd2 Ben On Thu, Apr 7, 2022 at 4:07 PM Ryan Sleevi wrote: > > > On Thu, Apr 7, 2022 at 5:03 PM Moudrick M. Dadashov < > m.m.dadas...@gmail.com> wrote: > >> "*Conformity

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

FWIW - Here is Ryan's presentation from the CA/Browser Forum's Shanghai F2F (Oct. 2018) where he compares ETSI and WebTrust - *see from Slide 56 on*. https://cabforum.org/wp-content/uploads/CABF45-Sleevi-Whats-Wrong-With-the-Ecosystem.pdf Also, FWIW, I plan on creating a Mozilla wiki page that

Re: DRAFT of New Policy and Process for Externally-operated Subordinate CAs

ink it's important to view this policy through the lens of MCS > Holdings and CNNIC. CNNIC issued the subordinate CA to MCS that was only > valid for 2 weeks, and within those two weeks, users had their TLS > connections intercepted, as discussed and summarized in > https://blog.mozilla.org/

Policy 2.8: MRSP Issue #238: Clarify that CAs can generate their own keys

issue, add to the end of the phrase above, "unless the certificate is being issued to the CA itself." https://github.com/BenWilson-Mozilla/pkipolicy/commit/e243b8252d19ba25f73dc56b9db3dc634f562e2b Please review. Thanks, Ben Wilson -- You received this message because you are subscribed

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

Here is an edit to address this - https://github.com/BenWilson-Mozilla/pkipolicy/commit/10946b7133bf57818638fdee95d38c8696baca63 On Tue, Mar 29, 2022 at 9:28 AM Ben Wilson wrote: > Should I add language that says ", regardless of changes in ownership or > control of the root CA

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

Please see language proposed to address Issue #219 here: https://github.com/BenWilson-Mozilla/pkipolicy/commit/907b54de5b811bbd1def8208e2f72b43f1e21048 . On Tue, Mar 29, 2022 at 9:35 AM Ben Wilson wrote: > Adriano, > > Right now, we're considering the following language: > &

Public Discussion of Certainly's Root Inclusion Request

posted. This email begins the 3-week comment period, which I’m scheduling to close on or about April 25, 2022, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10). Sincerely yours, Ben Wilson Mozilla Root Program Mana

Re: [elixir-core:10851] [Proposal] - Add an option to deps.get to force failure on lock mismatch

Yup, I also see the value in a human check. I think it's analogous to `mix format --checked` where the option explicitly exists to allow systems to enforce expectations. +1 from me. On Friday, April 1, 2022 at 1:51:12 PM UTC-4 ma...@jonrowe.co.uk wrote: > If I'm understanding the original

DRAFT of New Policy and Process for Externally-operated Subordinate CAs

All, The topic of externally-operated subordinate CAs is complex and needs to be further explained, and the process for approving such subordinate CAs needs to be described in more detail. Therefore, we propose adding a new section 8.4 to MRSP (v.2.8) and re-writing

Re: Public Discussion of DigiCert's Inclusion Request

On March 9, 2022, we began a three-week public discussion on DigiCert's request to include four new root certificates.[1] (Step 4 of the Mozilla Root Store CA Application Process[2]). *Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:* One commenter noted

Public Discussion of e-Tuğra's Inclusion Request

2, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10). Sincerely yours, Ben Wilson Mozilla Root Program Manager -- You received this message because you are subscribed to the Google Groups "dev-security-policy

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

; problems for the CAs that are nearing their next audit cycle. > > Adriano > > ACTALIS S.p.A. > > > Il 03/02/2022 23:31, Ben Wilson ha scritto: > > Regarding "Relying on a non-official source for accreditation information > has its own risks that should be tak

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

Should I add language that says ", regardless of changes in ownership or control of the root CA,"? "CA operators SHALL maintain links to older versions of each CP and CPS (or CP/CPS)*, regardless of changes in ownership or control of the root CA, *until *the entire* root CA certificate hierarchy

Re: Prioritization of Root CA Inclusion Requests

All, I've re-ordered the factors to emphasize (prioritize) CAs that are proposing separate roots. I also added to the lists "previously approved" "subordinate CA operator" - for those CA operators that have been through the public-review-and-discussion process. See

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

ges? Take for example the >>>> GTE Cybertrust Root that was valid from 1998 to 2018. How should those >>>> CPSes have been maintained when the root was transferred from GTE -> >>>> Baltimore -> BeTrusted -> Cybertrust -> Verizon -> DigiCert? >&

Re: Policy 2.8: MRSP Issue #227: Clarify Meaning of "CP/CPS"

ection was physically > carried out in person at each location, and which audit criteria were > checked (or not checked) at each location*". > > Even though CP/CPS is a merged document, we need to clarify which sections > of this document: > > 1) constitute a CP; > > 2) ar

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

Yes - thanks! > > > Thanks - Arvid > > > > *From:* dev-security-policy@mozilla.org *On > Behalf Of *Ben Wilson > *Sent:* Friday, 25 March 2022 18:41 > *To:* Pedro Fuentes > *Cc:* dev-security-policy@mozilla.org > *Subject:* Re: Policy 2.8: MRSP Issue #185: Requi

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

e >> GTE Cybertrust Root that was valid from 1998 to 2018. How should those >> CPSes have been maintained when the root was transferred from GTE -> >> Baltimore -> BeTrusted -> Cybertrust -> Verizon -> DigiCert? >> >> On Tue, Jan 18, 2022 at 4:03 PM Ben W

Policy 2.8: MRSP Issue #234: Add Policy about CRL Revocation Reason Codes

All, I've copied the work that Kathleen and others have done on adding CRL Revocation Reason Code requirements as a new section 6.1.1 in the Mozilla Root Store Policy. It can be reviewed here in the current draft version of MRSP v.2.8 - see

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

the GTE Cybertrust Root that was valid from 1998 to 2018. How should those CPSes have been maintained when the root was transferred from GTE -> Baltimore -> BeTrusted -> Cybertrust -> Verizon -> DigiCert? On Tue, Jan 18, 2022 at 4:03 PM Ben Wilson wrote: > Here is anothe

Re: Policy 2.8: MRSP Issue 195: Require public discussion when an organization receives a new subCA

e of certificate to be issued; or ·the new CA certificate will be issued with the same issuance capabilities by the same root CA to replace a CA certificate that was issued prior to [date]. Thoughts? Thanks, Ben On Fri, Feb 11, 2022 at 4:13 PM Ben Wilson wrote: > All, > >

Prioritization of Root CA Inclusion Requests

All, I am considering tweaking the prioritization criteria for inclusion requests to prioritize applicants who have been previously approved as externally operated intermediate CAs (and that are then requesting direct inclusion). So https://wiki.mozilla.org/CA/Prioritization would be updated.

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

rstand this process as part of their due > diligence. > > - Wayne > > On Sun, Mar 6, 2022 at 8:24 AM Ryan Sleevi wrote: > >> >> >> On Fri, Mar 4, 2022 at 5:07 PM Ben Wilson wrote: >> >>> All, >>> >>> Today I read through the Cer

Public Discussion of DigiCert's Inclusion Request

to all questions that are posted. This email begins the 3-week comment period, which I’m scheduling to close on or about March 31, 2022, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10). Sincerely yours, Ben Wils

Re: [elixir-core:10833] [Proposal] Add `List.pop/2`

I would benchmark to make sure that you're actually gaining something. If you are relying on it to be small, then at that specific size a list might also just be fine, and you won't be relying on behavior that could change in a future release. On Monday, March 7, 2022 at 11:49:06 AM UTC-5 Max

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

Ryan, The language I read states, "Certainly validates domain control primarily in an automated fashion using the ACME protocol." The other language is no longer there. Ben On Fri, Mar 4, 2022 at 4:16 PM Ben Wilson wrote: > Ryan, > Let me compare what I reviewed (CP/CPS dat

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

> On Fri, Mar 4, 2022 at 5:07 PM Ben Wilson wrote: > >> All, >> >> Today I read through the Certainly CP/CPS and reviewed the Compliance >> Self-Assessment and GoDaddy's review documents. I did not see anything in >> the CP/CPS that did not conform to the Mozill

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

All, Today I read through the Certainly CP/CPS and reviewed the Compliance Self-Assessment and GoDaddy's review documents. I did not see anything in the CP/CPS that did not conform to the Mozilla Root Store Policy or the CA/B Forum's Baseline Requirements. I also looked at the GoDaddy-Fastly

Re: Netlock incident from 19.02.2022

I reached out to Netlock when we were made aware of this attack. I don't believe that this constitutes an "incident" as defined in the Mozilla Root Store Policy, so I haven't requested that anything be filed. Here is Netlock's explanation: In the early morning of the 19th of February 2022

Re: Use of crt.sh ID in Incident Reports

othered about the extra CPU cycles that it takes for crt.sh to > execute the heuristic approach described above. Rather, ISTM that a > "?sha256=" > URL is more self-descriptive than a "?q=" URL, and clarity is important. > > -- > *

Re: Public Discussion of GoDaddy cross-signing two Certainly Intermediate Certificates

All, Here are some of my thoughts. The current policy allows cross-signing of externally operated CAs. What GoDaddy proposes to do with Certainly is the current practice. In this case, Certainly happens to have an application to have its root trusted directly in the root store, which is

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

to suggestions. For example, should the above language be placed at the bottom of Section 5.1.3 instead? (I already tried placing the language after every relevant case in section 5.1.3, but that was unnecessarily repetitive.) Thanks, Ben On Thu, Feb 17, 2022 at 11:09 AM Ben Wilson wrote: > Every

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

Everyone, Here is what I'd like to propose: Effective July 1, 2022, S/MIME certificates cannot be signed using SHA1 (Apple’s deadline is April 1, 2022). Effective July 1, 2023, all certificates (including OCSP responders), CRLs (including ARLs), and OCSP responses cannot be signed using SHA1.

Re: Policy 2.8: MRSP Issue 195: Require public discussion when an organization receives a new subCA

decide to have public discussions concerning such CA operators. Thanks, Ben On Fri, Jan 21, 2022 at 7:57 PM Ben Wilson wrote: > All, > > This email introduces public discussion regarding additions/clarifications > to be included in the next version of the Mozilla Root Store Policy (MS

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

r or email certificates. On Wed, Feb 9, 2022 at 4:19 PM Ben Wilson wrote: > Elsewhere in the Policy, we use the phrases "certificate capable of being > used for TLS [server authentication] ..." and "certificate capable of being > used for digitally signing or encrypting e

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

Elsewhere in the Policy, we use the phrases "certificate capable of being used for TLS [server authentication] ..." and "certificate capable of being used for digitally signing or encrypting email messages". Are those better? Thanks, Ben On Wed, Feb 9, 2022 at 2:20 PM 'Tim Hollebeek' via

Re: Clarification related to the scope of Mozilla Root Store Policy

لذا لن يكون المُرسل خاضعاً للمساءلة حال انتقال المعلومات في هذا البريد > بصورة غير ملائمة أو منتقصة، ولا تجاه أي تأخير في وصوله، أو تجاه أي عطل في > جهازك. إن مركز دبي للأمن الإلكتروني لا يتحمل مسؤولية أي أضرار ناتجة عن أي > فيروس أو برنامج قد يرسل بواسطة هذا البريد الإلكتروني. > >

Re: Policy 2.8: MRSP Issues List

All, Here is a comparison between version 2.7.1 and proposed version 2.8 (without language yet for sunsetting SHA1 and requiring CRLReason codes). https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 Ben On Thu, Feb 3, 2022 at 2:56 PM Ben Wilson wrote: > All, > &

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

does not sign SHA-1 > hashes for any purpose, and would be amenable to any sunset date. > > > > We do accept signatures over SHA-1 hashes of CSRs provided by subscribers, > and of course accept SHA-1 hashes for the issuerKeyHash and issuerNameHash > in OCSP requests, but those are not re

Re: Clarification related to the scope of Mozilla Root Store Policy

Dear Mohamed, You have asked about whether an intermediate CA certificate with an EKU constraint of clientAuth and document signing (and no EKU for email security or serverAuth), would pull it out of scope for Mozilla, even if the end entity certificates do not have a standard EKU. I think it

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

o SHA-256 will bring minimal, perhaps even zero, > disruption to relying parties. Therefore, we'll be happy with whatever > sunset date Mozilla chooses. > > -- > *From:* dev-security-policy@mozilla.org > on behalf of Ben Wilson > *Sent:* 02

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

does not sign SHA-1 > hashes for any purpose, and would be amenable to any sunset date. > > > > We do accept signatures over SHA-1 hashes of CSRs provided by subscribers, > and of course accept SHA-1 hashes for the issuerKeyHash and issuerNameHash > in OCSP requests, but those are

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

Regarding "Relying on a non-official source for accreditation information has its own risks that should be taken seriously." - That isn't how it works - in the third column over on https://www.acab-c.com/members/, the link is to the official source, which is what we review. On Thu, Feb 3, 2022 at

Policy 2.8: MRSP Issues List

All, Below is a list of the current MRSP issues for version 2.8. I believe we're getting closer to finalizing the language. There appear to be things to discuss for highlighted Issues #178 (Sunsetting SHA1), #219 (Requiring ETSI Auditors to be ACAB'c members), #226 (clarifying section 5.2),

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

elationship might be awkward, into joining an organization >> simply to check a box on Mozilla’s compliance list, will not improve >> anything. People will join for the checkbox, and then ignore the >> organization and not participate. >> >> >> >> -Tim >&

Re: Policy 2.8: MRSP Issue #232: Add policy about old root certificates

emoving old roots from the trust store, but is using the >> hash algorithm on the root the right criteria? I was under the impression >> that the root programs really embedded the public key and that the >> signature on the root was “irrelevant” from a security perspective once it &

Re: Revocation Reason Codes for TLS End-Entity Certificates

I might say instead, "... the CA SHOULD revoke all certificates associated with that subscriber that contain that public key. The CA SHOULD NOT assume that it has evidence of private key compromise for the purposes of: revoking the certificates of other subscribers or blocking issuance of future

Policy 2.8: MRSP Issue #232: Add policy about old root certificates

All, Originally, I scoped version 2.8 of the Mozilla Root Store Policy (MRSP) to include criteria and timeframes for when certain old root CA certificates would be removed from the trust store (prior to their expiry date). In Github, I am taking off the "2.8" Label from Issue #232

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

arify what we're talking about in MRSP section 5.3.2. Ben On Mon, Nov 15, 2021 at 11:42 AM Ben Wilson wrote: > 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. >

Re: Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

no operational CRL or OCSP service exists. (It might be nice to have a third bullet to this second list - issues only found with certificates and not also in CRLs / OCSP responses.) Thanks in advance. Ben On Wed, Jan 26, 2022 at 11:30 AM Ben Wilson wrote: > See responses inline below. > &g

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

I have emailed CAs in the Mozilla program asking them to respond here. On Wed, Jan 26, 2022 at 12:41 PM Ryan Sleevi wrote: > > > On Wed, Jan 26, 2022 at 2:00 PM Ben Wilson wrote: > >> See responses inline below. >> >> On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

; ACAB-C member? >> >> Thanks, >> M.D. >> >> On Wed, Jan 26, 2022, 20:37 Ben Wilson wrote: >> >>> I agree that a "MUST" is better. Does anyone have a stronger case for >>> making it a "SHOULD"? >>> >>>

Re: Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

Based on conversations with Kathleen, I have simplified the changes made to address these issues. See https://github.com/BenWilson-Mozilla/pkipolicy/commit/7b0cb570fdf5b423b1b267fd01bc2bbb5aced7a9 On Thu, Jan 27, 2022 at 11:22 AM Ben Wilson wrote: > Hi Ryan, > I have attempted to incor

Re: Public Discussion of D-Trust Root Inclusion Requests

-security-policy/c/0Ljc_EkPsiQ/m/9XLIROdXBAAJ [2] https://wiki.mozilla.org/CA/Application_Process#Process_Overview On Thu, Jan 6, 2022 at 11:55 AM Ben Wilson wrote: > *D-Trust GmbH, a member of the Bundesdruckerei Group and wholly owned > subsidiary of Bundesdruckerei GmbH (“D

Re: Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

needs to be from thinking about "Sanctions for incidents" (which > 7.3 mostly covers), and instead being clear that "Sometimes, additional > audits are needed". I grouped these two cases (audits for remediation and > audits because crappy auditors) into 3.3, because it m

Re: Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

cates to OneCRL, removing trust bits from root certificates, or removing root certificates from the trust store." On Wed, Jan 26, 2022 at 12:37 PM Ryan Sleevi wrote: > > > On Wed, Jan 26, 2022 at 1:26 PM Ben Wilson wrote: > >> As my comment on the issue at the time tr

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

? (Date) Do you still sign OCSP responses for SMIME certificates using the SHA1 algorithm? (Y/N) When should CAs be prohibited from signing OCSP responses for SMIME certificates using the SHA1 algorithm? (Date) Thanks, Ben > On Tue, Jan 25, 2022 at 10:29 PM Ben Wilson wrote: > >&

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

ed nor incentivized to do, but at least ACAB-c has been > willing to try. > > On Tue, Jan 25, 2022 at 10:53 PM Ben Wilson wrote: > >> I am proposing that we make this a "SHOULD". ETSI auditors SHOULD be >> members of ACAB'c. >> >

Re: Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

coped CRLs that lack a > distributionPoint in a critical issuingDistributionPoint extension” > Thanks for the suggestion. I'll work on it. > > I raise that as an example of something we saw several CAs do in the past, > in violation of RFC 5280. > > On Wed, Jan 26, 2022 at 12:13 AM

Re: Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

I'm inviting comments and suggestions on improving the language. > > Like I said, I’m very confused here about the goals of this change, as > proposed. > > On Tue, Jan 25, 2022 at 10:25 PM Ben Wilson wrote: > >> Here is some draft language to address this issue #155. >> &g

Re: Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

tName extension” > > > > Thanks, > > Corey > > > > *From:* 'Aaron Gable' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org> > *Sent:* Thursday, January 13, 2022 8:12 PM > *To:* Ben Wilson > *Cc:* dev-secur...@mozilla.org >

Re: Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

by members of the armed forces, of the police or of the > administration of the State. > > Thanks, > M.D. > > On Wed, Dec 15, 2021, 00:37 Ben Wilson wrote: > >> All, >> >> This email starts discussion of whether ETSI auditors should be requir

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

to all CAs in the Mozilla program, and it will ask the relevant questions that will help us determine appropriate sunset dates for SHA1. Thanks, Ben On Fri, Jan 21, 2022 at 12:54 PM Ben Wilson wrote: > All, > > This email launches a new discussion related to sunsetting the future use > of SH

Re: Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

o sanctions. If a CA operator has failed to remediate the causes giving rise to an incident, Mozilla MAY impose sanctions, including but not limited to: adding certificates to OneCRL; removing trust bits from root certificates; and removing root certificates from the trust store. On Sun, Jan 16, 2

Re: [elixir-core:10725] Re: Wrapper for receive block.

For that purpose, I feel like: {:ok, %{pattern: [match, here]}} = Foo.await(item) would work right? Can you help me understand why the patterns themselves need to be passed to your `await` function? On Monday, January 24, 2022 at 12:09:56 PM UTC-5 mateus...@swmansion.com wrote: > Hi there, >

Policy 2.8: MRSP Issue #198: Outline Policy Update Process

All, This email introduces a minor change to the Mozilla Root Store Policy (MRSP). This is Github Issue #198 . Here is a redline: https://github.com/BenWilson-Mozilla/pkipolicy/commit/2ba1ff1f134db1c600c04805c33d2fb903ce32a9 It adds these two

Policy 2.8: MRSP Issue 195: Require public discussion when an organization receives a new subCA

bootstrapping" or "grandfathering" for CA operators who have not previously undergone a public-review-and-discussion process by Mozilla). https://github.com/BenWilson-Mozilla/pkipolicy/commit/8f53485a00b9289f9f6b05158647b74ad3ab We welcome your comments and suggestions. Thanks, B

Policy 2.8: MRSP Issue #178: Sunset SHA1

All, This email launches a new discussion related to sunsetting the future use of SHA1 in the Mozilla Root Store Policy (MRSP) . It is related to GitHub Issue #178

Re: [elixir-core:10716] [Proposal] Add a shortcut to access a struct within the module where it is defined

__MODULE__ is the right answer here IMHO. It is consistent with the other "meta constants" like __ENV__, __DIR__ __FILE__ and so on in that they desugar to constants, but are file / code relative. It isn't a super common pattern, but last time I checked generated phoenix code does a

Re: Public Discussion: Inclusion of Telia Root CA v2

A operations of company B. Together, these two >>> audit reports prove that all audited functions have been performed and >>> nothing is missing. >>> >>> If I understand one of Moudrick's concerns (obviously he has plenty of >>> concerns but I only focus on the au

Re: Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

I have prepared draft language stating, "CAs SHALL maintain links to >> older versions of their CPs and CPSes for as long as any related CA >> certificate hierarchy is in the Mozilla root program." See >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/3b217f923582f7cfd8

Re: [cabfpub] Draft CA/Browser Forum agenda - Thursday, January 20, 2021 at 11:30 am Eastern Time

We might want to have an item and time allocated for the Network Security Committee report, which will meet tomorrow. On Sun, Jan 16, 2022 at 5:31 PM Dean Coclin via Public wrote: > *Here is the draft agenda for the subject call* > > *CA/Browser Forum Agenda* > > *Time* > > *Start(ET)* > >

Policy 2.8: MRSP Issue #155: Describe actions Mozilla may take upon receipt of a qualified audit

All, This email introduces discussion of GitHub Issue #155 - Describe actions Mozilla may take upon receipt of a qualified audit. The list below includes enforcement actions that Mozilla might take for any set of non-compliance events (not just

Policy 2.8: MRSP Issue #138: Make it clear that RFC 9162 precertificates are covered by Mozilla policy

All, This email introduces discussion of Github Issue #138 , which is to add section 5.4 to the Mozilla Root Store Policy to address Certificate Transparency precertificates. While Mozilla does not have a policy requiring pre-publication of

Policy 2.8: MRSP Issue #131: Improve terminology and style

All, This email introduces several language changes 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 #131 .

Policy 2.8: MRSP Issue #184: Change Terminology from SSL to TLS

All, This email introduces discussion of a change from the term "SSL" to the term "TLS" in the Mozilla Root Store Policy. Also, when talking about trust bits, the term "SSL" is changed to "websites". This is Github Issue #184 . Here is a

Policy 2.8: MRSP Issue #185: Require publication of outdated CA policy documents

e Please review and comment on the clarity of this proposed language. Thanks, Ben Wilson Mozilla Root Store 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 rece

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

that Mozilla and Apple will converge on using the same >> language to require that one of those two fields in that section be filled >> out for the sake of minimizing confusion. >> >> Aaron >> >> On Wed, Nov 17, 2021 at 8:06 PM Ben Wilson wrote: >> >>&

Public Discussion of D-Trust Root Inclusion Requests

this email begins a three-week public discussion period, which I’m scheduling to close on or about January 28, 2022. Sincerely yours, Ben Wilson Mozilla Root Program Manager -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org&quo

Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

All, This email introduces discussion of another issue to be resolved by the next version of the Mozilla Root Store Policy (MSRP), version 2.8. (See https://github.com/mozilla/pkipolicy/labels/2.8) This is Github Issue #226 . Section 5.2 of the

Re: FW: RE: Public Discussion: Inclusion of Telia Root CA v2

ing resources from many Telia affiliates. And all is owned by Telia > Company AB. All Telia CA employees belong legally to one of the Telia > affiliates. > > 2) does "Telia CA Policy Management Team" mean Telia Finland Oyj? > > Telia CA Policy Management team is also a Telia

Re: [elixir-core:10648] Introduce let and reduce qualifiers to for

To revisit the example situation from the original post: ``` {sections, _acc} = for let {section_counter, lesson_counter} = {1, 1}, section <- sections do lesson_counter = if section["reset_lesson_position"], do: 1, else: lesson_counter {lessons, lesson_counter} = for let lesson_counter, lesson

[elixir-core:10641] Re: Introduce let and reduce qualifiers to for

I believe this nicely addresses my concerns from the first proposal. Inner refactoring into functions is 100% possible, and there are no strange reassignment behaviors introduced that don't extend to the rest of the language. As for the questions outlined in the guide: 1) To Paren or not

Re: [cabfpub] Voting Period Begins: Ballot FORUM-17: Create Network Security Working Group

Mozilla vote "YES" on Ballot FORUM-17. On Thu, Dec 16, 2021 at 11:39 AM Ben Wilson wrote: > Ballot FORUM-17, Create Network Security Working Group, is proposed by > Ben Wilson of Mozilla and endorsed by Tim Hollebeek of DigiCert and David > Kluge of Google. > > The

[cabfpub] Voting Period Begins: Ballot FORUM-17: Create Network Security Working Group

Ballot FORUM-17, Create Network Security Working Group, is proposed by Ben Wilson of Mozilla and endorsed by Tim Hollebeek of DigiCert and David Kluge of Google. The Voting Period for Ballot FORUM-17 begins today at 19:00 UTC and ends on 23-Dec-2021 at 19:00 UTC. *Overview* In January 2013

[elixir-core:10601] Re: Introduce :let in for-comprehensions

I am with Louis and Paul so far I think. I won't repeat their comments but I think I can extend the issue by pointing out that this breaks refactoring for the inner contents of `for`. Previously, if you have: ``` for lesson <- section["lessons"], reduce: 0 do counter -> # complex

Policy 2.8: MRSP Issue #219: Require ETSI auditors to be ACAB-c members

y for any auditor using ETSI criteria to review CAs that issue publicly trusted server certificates, and therefore, ACAB'c membership should be a requirement stated in the MRSP. Please provide your responses and comments in this thread. Thanks. Sincerely, Ben Wilson Mozilla Root Store Program

Policy 2.8: MRSP Issue #227: Clarify Meaning of "CP/CPS"

Greetings, This email introduces discussion of another issue selected to be addressed 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 Issue #227

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

All, I moved this section to its own wiki page - https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained. I also added a link to it from the CA Program home page - https://wiki.mozilla.org/CA#Information_for_CAs. Ben On Fri, Nov 19, 2021 at 4:12 PM Ben Wilson wrote: > I h

[cabfpub] Discussion Period Begins on Ballot FORUM-17: Create Network Security Working Group

The following ballot is proposed by Ben Wilson of Mozilla and endorsed by Tim Hollebeek of DigiCert and David Kluge of Google. *Ballot Forum-17: Create Network Security Working Group* *Overview* In January 2013 the CA/Browser Forum’s “Network and Certificate System Security Requirements

New Mozilla Security Blog Post on Intermediate Certificates

All, Today, Kathleen and I published a new Mozilla Security blog post - Improving the Quality of Publicly Trusted Intermediate CA Certificates with Enhanced Oversight and Automation

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