Re: Outdated resource links on CCADB

Thank you for reporting this Matthew. I've updated that page with the correct links: https://www.ccadb.org/resources - Wayne On Mon, Sep 23, 2019 at 8:23 AM Jos Purvis (jopurvis) via dev-security-policy wrote: > Heh--my bad, I read that as "cabforum.org". I'll correct it there as > well, but Ka

Re: DigiCert OCSP services returns 1 byte

I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob identified. I also want to acknowledge the feedback from Google on the timing of this. I can appreciate the framing of this as a new policy that's been added without due process, but I view this as a clarification of exist

Re: DigiCert OCSP services returns 1 byte

On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote: > > I propose that you update [4] to say that Mozilla won't treat > non-compliance with [4] as an "incident" whilst it remains the case that > the BRs are inconsistent with [4]. > > I could simply move [4] to a "recommended practice" (SHOULD) un

Re: Next Root Store Policy Update

Over the past 3 months, a number of other projects distracted me from this work. Now I'd like to focus on finishing these updates to our Root Store policy. There are roughly 6 issues remaining to be discussed, and I will, as always, greatly appreciate everyone's input on them. I'll be sending out i

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

gned. > > This might be something to consider more carefully. > > > Thank you, > Dimitris. > > > On 15/5/2019 3:25 π.μ., Wayne Thayer via dev-security-policy wrote: > > On Tue, May 14, 2019 at 11:21 AM Kathleen Wilson via dev-security-policy > < > &

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道： > > The BRs require EKUs in leaf TLS certs, but there is no equivalent > > requirement for S/MIME certificates. This leads to confusion

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

Thank you Ryan. Brian reviewed these changes back in May, so I've gone ahead and accepted them for the 2.7 policy update: https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27 I'll consider this issue resolved unless there are further comments. - Wayne On Fri, May

Re: DigiCert OCSP services returns 1 byte

I've gone ahead and moved [4] to the "Recommended Practices" section. The ballot to modify the BRs is now in the formal discussion period leading up to a vote [5]. I'll be resolving the existing compliance bugs on this issue as INVALID. I'd like to thank the CAs that proactively submitted inciden

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

I'd like to revisit this topic because I see it as a significant change and am surprised that it didn't generate any discussion. Taking a step back, a change [1] to notification requirements was made last year to require CAs that are signing unconstrained subordinate CAs (including cross-certs) co

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

he final few TLS sub CAs (5) and each are operating in > OCSP signing mode only. They'll all be revoked in 2020. > > Unless I'm missing something, DigiCert is continuing to issue externally operated S/MIME sub CAs, e.g. https://crt.sh/?id=1652799594 Jeremy > > > -Origi

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

I'd like to revive this discussion. So far we've established that the existing "required practice" [1] is too stringent for email address validation and needs to be changed. We can do that by removing email addresses from the scope of the requirement as Kathleen proposed, or by exempting the local

Policy 2.7 Proposal: Update Appeal Process

The last sentence of section 1.2 Policy Ownership states: CAs or others objecting to a particular decision by either team MAY appeal > to the Mozilla governance module owner > who will make a > final decision. > Last year [1], Mozilla deleg

Re: Policy 2.7 Proposal: Incident Reporting Updates

Jeremy Rowley posted the following comments in a separate thread: One suggestion on incident reports is to define "regularly update" as some > period of time as non-responses can result in additional incident reports. > Maybe something along the lines of "the greater of every 7 days, the time > pe

Re: Mozilla Policy Requirements CA Incidents

Ryan, Thank you for pointing out these incidents, and for raising the meta-issue of policy compliance. We saw similar issues with CP/CPS compliance to changes in the 2.5 and 2.6 versions of policy, with little explanation beyond "it's hard to update our CPS" and "oops". Historically, our approach

Re: Entrust Root Certification Authority - G4 Inclusion Request

On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: > > > We will update section 4.2 and 9.12.3 in the next release of the CPS. > > The CPS Has been updated to address the above is

Re: Entrust Root Certification Authority - G4 Inclusion Request

Having received no further comments, I have recommended approval of this request in bug 1480510. - Wayne On Tue, Oct 8, 2019 at 4:23 PM Wayne Thayer wrote: > On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Monday, July 29, 2

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

not use “any EKU.”" There's a > chance that the CA is not in Microsoft, but I thought Mozilla usually had > fewer CAs than Microsoft included. > > -Original Message----- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-security-policy > Sent: We

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Sat, Oct 5, 2019 at 6:32 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks Jeremy, Dimitris, > > It does help clarify. I think we're all on the same page: namely, in all > cases, the CA does the validation of (at minimum) the domain portion. > > I t

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

number issue, if a CA had to be revoked, status >> information for its issued Certificates would discontinue leading >> Relying Parties to have difficulties validating the existing signed >> e-mails that were valid when signed. >> >> This might be something to consider more c

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Mon, Oct 21, 2019 at 7:01 PM Ryan Sleevi wrote: > > On Mon, Oct 21, 2019 at 7:58 PM Wayne Thayer wrote: > >> The CA MUST verify all e-mail addresses using a process that is >>> substantially similar to the process used to verify domain names, as >>> described in the Baseline Requirements. >>>

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

s end up embedded on > smart cards, used by government institutions and pinned in weird places. > And the unfortunate part is you don't have the direct relationship with the > end-user to offer counsel against some of the practices. That extra > abstraction layer between the CA and

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Tue, Oct 22, 2019 at 10:59 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Sounds good. This was your proposed response to solving this issue > > > back on May 13, so it's full circle :) > > > > > > > > > I'm going to consider this issue

Re: Firefox removes UI for site identity

On Tue, Oct 22, 2019 at 1:38 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks Johann. Much appreciated. Would you be kind enough to email me a > screen shot to save me the trouble of installing an older version and then > waiting for an update? :) > >

Re: Firefox removes UI for site identity

The primary purpose of forwarding the Intent to Ship email to this list was to inform the community of this planned change and the reasoning behind it. Mozilla considered lots of information prior to announcing the change, and during the vigorous debate that ensued, we continued to listen without t

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi wrote: > > On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > I'm also not sure if I understand the wording correctly. Let's assume, >>

Re: Policy 2.7 Proposal: Incident Reporting Updates

Having received no comments, I did not add the proposed guidance on status update frequency, but I did make the "marked as resolved" change that Jeremy suggested: https://github.com/mozilla/pkipolicy/commit/bad3fedc10e1fe9d5237760093ad235326e3bd62 An additional related change has been proposed in

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Thu, Oct 24, 2019 at 10:33 AM Buschart, Rufus wrote: > On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi <mailto:r...@sleevi.com> > wrote: > > On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy > <mailto:dev-security-policy@lists.mozilla.org> wrote: >

Re: [FORGED] Firefox removes UI for site identity

Hi Paul, On Mon, Oct 28, 2019 at 2:41 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > [PW] So you dislike Mozilla’s implementation for the tracker icon in the > address bar? When you update to 70.0 you’re prompted with an > educational-type pop-out to draw

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus wrote: > Maybe the following could be a reasonable rewording of the paragraph that > makes the intention of the discussion clear, but isn't to 'clunky': > > For a certificate capable of being used for digitally signing or > encrypting email messages

Re: Policy 2.7 Proposal: Incident Reporting Updates

On Tue, Oct 22, 2019 at 7:41 PM Ryan Sleevi wrote: > > On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I have added this proposal to the 2.7 branch: >> >> https:/

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

On Mon, Oct 21, 2019 at 6:49 PM Wayne Thayer wrote: > Here are the proposed changes: > * Reinstate Mozilla's revocation requirements for S/MIME certificates: > https://github.com/mozilla/pkipolicy/commit/e6337bb76a4522da15aeb7c0862b6cc05d317814 > (replacing the original 2.7 proposal with the olde

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

I've opened issue #196 [1] to track Rufus' suggested clarification for a future policy update. I'll consider this issue (#175) resolved unless further comments are received. - Wayne [1] https://github.com/mozilla/pkipolicy/issues/196 On Mon, Oct 28, 2019 at 4:41 PM Wayne Thayer wrote: > On Sun

Re: Next Root Store Policy Update

We've concluded discussions on the individual issues and can begin work to finalize the version 2.7 Root Store Policy update. Here is a redline of all the changes: https://github.com/mozilla/pkipolicy/compare/master...2.7 (click on the Files Changed tab) As noted below, two of these changes inclu

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

A few more questions have come up about this change: * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why would we include them in our policy? * Related: would this detailed enumeration of requirements be better to place in the BRs than in Mozilla policy? * In that case i

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi wrote: > > On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> A few more questions have come up about this change: >> >> * Since mozilla::pkix d

How Certificates are Verified by Firefox

If you are one of the many people who have wondered how exactly Firefox handles some aspect of certificate processing, you may be interested to know that we have recently updated the information on our wiki: https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification I hope you find thi

Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

On Thu, Nov 14, 2019 at 3:24 PM Wayne Thayer wrote: > On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi wrote: > >> >> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> A few

Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

The last change I am proposing for version 2.7 of the Mozilla Root Store policy is an update to the minimum versions of audit criteria that we will accept in audits. I have conferred with the WebTrust Task Force and was informed that we can update the minimum version requirements for audit statemen

Incident Reporting Guidance

During the recent CA/Browser Forum meeting, I was asked to provide better guidance on Mozilla's expectations for incident reporting. We're adding a requirement for incident reporting to the new version of our policy [1], but in this message I'm focused on the guidance provided on our wiki [2]. The

Re: Trusted Recursive Resolver Policy in India

The only update I can provide at this time is that we're working on it. On Thu, Nov 21, 2019 at 10:08 AM rich.salz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Saturday, September 14, 2019 at 7:04:11 AM UTC+8, Wayne Thayer wrote: > > Rich: I want to acknowledge

Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

I've given the new version [1] another review, updated a few links, and set the effective date to 1-January 2020. Unless there are new comments on this or any of the other changes [2], I will have the new version published in the next few weeks. I'll also be preparing a CA Communication to announc

Re: [FORGED] Re: How Certificates are Verified by Firefox

Why not "AIA chasing considered harmful"? The current state of affairs is that most browsers [other than Firefox] will go and fetch the intermediate if it's not cached. This manifests itself as sites not working in Firefox, and users switching to other browsers. You may be further dismayed to lear

Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

A concern [1] was raised about the required version of WebTrust audit criteria. After discussing with the WebTrust folks, I have changed the minimum requirement to the previous WebTrust versions instead of the current versions [2]. - Wayne [1] https://github.com/mozilla/pkipolicy/issues/197 [2] h

Root Store Policy 2.7 Published

The new version of the Mozilla Root Store Policy has been published [1]. This version goes into effect on January 1, 2020. The prior version that is in effect for the rest of 2019 is linked from the wiki [2]. I have also just posted an announcement [3] on the Mozilla Security Blog. We will be sen

Re: Incident Reporting Guidance

g/CA/Responding_To_An_Incident#Incident_Report On Thu, Nov 21, 2019 at 10:48 AM Ryan Sleevi wrote: > > > On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> During the recent CA/Browser Forum meetin

Re: Root Store Policy 2.7 Published

On Thu, Dec 12, 2019 at 4:58 AM Malcolm Doody via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, 12 December 2019 11:07:24 UTC, Malcolm Doody wrote: > > On Wednesday, 11 December 2019 15:42:21 UTC, Wayne Thayer wrote: > > > The new version of the Mozilla Root

DRAFT January 2020 CA Communication

All, I've drafted a new email and survey that I plan to send to all CAs in the Mozilla program in early January. it focuses on compliance with the new (2.7) version of our Root Store Policy. I will appreciate your review and feedback on the draft: https://ccadb-public.secure.force.com/mozillacommu

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, 25 Nov 2019 14:12:46 -0800 > Kathleen Wilson via dev-security-policy > wrote: > > > CAs should have been keeping track of and resolving their own known > > problems in regar

Re: Incident Reporting Guidance

head and make > these changes. > > - Wayne > > [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report > > On Thu, Nov 21, 2019 at 10:48 AM Ryan Sleevi > wrote: > >> >> >> On Thu, Nov 21, 2019 at 10:54 AM Wayne Thayer via dev-security

Re: Root Store Policy 2.7 Published

You can find an explanation of Mozilla's enforcement mechanism on our wiki [1]. When a CA fails to comply, the immediate action upon discovery is the creation of an incident bug and the expectation that the CA will file an incident report [2]. - Wayne [1] https://wiki.mozilla.org/CA/Maintenance_a

Re: DRAFT January 2020 CA Communication

On Thu, Dec 19, 2019 at 3:12 PM Ryan Sleevi wrote: > > On Thu, Dec 19, 2019 at 12:10 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> All, >> >> I've drafted a new email and survey that I plan to send to a

Re: DRAFT January 2020 CA Communication

On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley wrote: > Should anything be mentioned about the allowed algorithms? That's the > largest change to the policy and confirming the AlgorithmIdentifiers in > each case may take some time. > > I'd argue that this is a clarification rather than a change,

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

On Sat, Dec 21, 2019 at 11:30 AM Nick Lamb wrote: > On Thu, 19 Dec 2019 10:23:19 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > We've included a question about complying with the intermediate audit > > requirements in the January survey, but not a mo

Re: Audit Letter Validation (ALV) on intermediate certs in CCADB

14:20:16 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > I suggest that we modify question #1 to require CAs > > to attest that they intend to FULLY comply with version 2.7 of the > > policy and if they won't fully comply, to list all non-conforrmities. &g

Re: DRAFT January 2020 CA Communication

I've made some additional improvements to the survey based on feedback from Kathleen: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW I'm planning to send this out to CAs on Tuesday. On Mon, Dec 23, 2019 at 12:39 PM Wayne

Re: DRAFT January 2020 CA Communication

On Fri, Jan 3, 2020 at 12:49 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote: > > I've made some additional improvements to the survey based on feedback > from > > Kathleen: > > > > > htt

Re: DRAFT January 2020 CA Communication

Thank you Malcolm, that is a good suggestion for consistency. I have updated the survey and am still planning to send it out tomorrow (Tuesday). - Wayne On Mon, Jan 6, 2020 at 1:14 AM Malcolm Doody via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, January 3, 20

Re: DRAFT January 2020 CA Communication

The email has been sent to all CAs in the Mozilla program requesting that they respond to the survey by the end of this month. Responses will be published on the wiki [1] as they are received. Please note that the responses for questions 2, 3, and 5 do not yet properly display the date fields that

Policy Module Ownership

I have decided to leave Mozilla, effective this Friday. I expect Mozilla to hire a replacement, but that will of course take time. In the interim, I will remain the CA Certificate Policy Module Owner and contribute to the best of my ability in a volunteer capacity. Please feel free to contact me

Re: When to accept/require revised audits for missing cert fingerprints

On Thu, Feb 6, 2020 at 5:44 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: My recommendation is that, for audit periods ending within the next 30 or > so days (meaning, effectively, for reports provided over the next 4 months, > given the three month windo

Re: About upcoming limits on trusted certificates

Thank you for sharing this Clint. I'd like to ask for input from the community: is this a requirement that we should add to the Mozilla policy at this time (effective September 1, 2020)? You may recall that a 398-day maximum validity for TLS certificates was proposed to the CA/Browser Forum by Go

Re: About upcoming limits on trusted certificates

On Wed, Mar 4, 2020 at 11:48 AM Nick Lamb wrote: > On Tue, 3 Mar 2020 13:27:59 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > I'd like to ask for input from the community: is this a requirement > > that we should add to the Mozilla policy at this ti

Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields

I have created bug #1622539 to track this issue. - Wayne On Fri, Mar 13, 2020 at 3:09 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 1. How your CA first became aware of the problem (e.g. via a problem > report submitted to your Problem Reporting Me

Re: Acceptable forms of evidence for key compromise

I've created https://github.com/mozilla/pkipolicy/issues/205 to consider adding a requirement to a future version of Mozilla policy for CAs to either support a standardized mechanism for proving key compromise, or to publish acceptable mechanism(s) in their CPS. - Wayne On Mon, Mar 2, 2020 at 2:3

Fwd: Proposal for New CA Certificate Policy Module Owner

I posted the following message in the mozilla.governance forum. If you would like, please feel free to comment here in m.d.s.p. - Wayne -- Forwarded message - From: Wayne Thayer Date: Fri, Mar 13, 2020 at 11:11 AM Subject: Proposal for New CA Certificate Policy Module Owner To:

Re: Musings on mass key-compromise revocations

Thank you Matt. I really appreciate the detailed summary and look forward to your specific improvement proposals. - Wayne On Sat, Mar 28, 2020 at 1:12 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've been asked to provide some "big-picture" thoughts o

Re: Sectigo: Failure to revoke certificate with previously-compromised key within 24 hours

I've created a bug to track this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1625715 - Wayne On Thu, Mar 26, 2020 at 11:33 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > At 2020-03-20 03:02:43 UTC, I sent a notification to sslab...@sectigo.com >

Re: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root

This issue is now documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1625767 On Tue, Mar 24, 2020 at 12:29 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Investigation of the situation: > > 2009-03-06 > Microsec Ltd. issued the foll

Re: Proposal for New CA Certificate Policy Module Owner

This change has been made and Kathleen Wilson is now the CA Certificate Policy Module Owner. On Fri, Mar 20, 2020 at 1:34 PM Wayne Thayer wrote: > I posted the following message in the mozilla.governance forum. > > If you would like, please feel free to comment here in m.d.s.p. > > - Wayne > > -

Re: Change of Root ownership structure

Thank you for making this announcement Arnold. This change of legal ownership is covered by section 8.1 of the Mozilla Root Store Policy, including the following statement: If the receiving or acquiring company is new to the Mozilla root program, > it must demonstrate compliance with the entirety

Mozilla's Expectations for OCSP Incident Reporting

It was recently reported [1] that IdenTrust experienced a multi-day OCSP outage about two weeks ago. Other recent OCSP issues have resulted in incident reports [3][4], so I am concerned that IdenTrust didn't report this, and I created a bug [5] to ensure that we track the issue (assuming the report

Re: Request to Include certSIGN Root CA G2 certificate

The ETSI audit attestation statement referenced by Ben [1] lists 6 non-conformities that were to be corrected within 3 months of the onsite audit that occurred on 2020-02-10 until 2020-02-14: Findings with regard to ETSI EN 319 401: -REQ-7.8-06–Documentation shall be improved Findings with regard

Re: Status of the bugzilla bug list

I'd just like to add or reinforce a few points based on my approach to managing open incident bugs: * I have leaned heavily to the side of leaving bugs open if there is the potential for additional questions, and always if there are any incomplete remediations. This means that bugs do tend to stay

Re: Change of Root ownership structure

Given that no other concerns have been raised, I consider this request to have been "resolved with a positive conclusion" as required by Mozilla policy section 8.1. Arnold: please update the information in CCADB (or ask Kathleen if you are unable) when this change takes effect. - Wayne On Wed, A

Re: Sectigo to Be Acquired by GI Partners

Rob: what, if any, changes will be made to the Sectigo CP/CPS as a result of this change of control? Thanks, Wayne On Thu, Oct 1, 2020 at 1:55 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As announced previously by Rob Stradling, there is an agreement

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

On Thu, Dec 17, 2020 at 10:32 AM Aaron Gable via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > One potential option (5) would be to go even further than (2), and remove > the OCSP paragraph from the MRSP§6 entirely. Given that MRSP§2.3 says "CA > operations relating to issu

Re: Summary of Camerfirma's Compliance Issues

On Sat, Dec 19, 2020 at 1:03 AM Ramiro Muñoz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ben, Ryan, Burton and all: > > Camerfirma will present its claims based on a description of the problems > found by associating the references to the specific bugs. > After mak

Re: Mozilla's Response to Camerfirma's Compliance Issues

Ben, Here are my thoughts: - First off, we have given Camerfirma the benefit of the doubt for too long and Mozilla can't continue to trust Camerfirma while they remediate these problems. With all the documented issues and Camerfirma's response, that would represent an unacceptable ongoing risk to

Re: On the value of EV

Thank you Ryan for raising this question, and to everyone who has been contributing in a constructive manner to the discussion. A number of excellent points have been raised on the effectiveness of EV in general and on the practicality of solving the problems that exist with EV. While we have conc

Re: ComSign Root Renewal Request

On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thank you for your notes, > Here are the answers to your points. > > all the "bad" points about the CPS were addressed: > Both CPS's are now changed to ver 4.1 > Looks good, thank you.

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

Thanks Rob! I went through the list and filed a bug for each CA if there wasn't one already open (with one exception that I'm still researching). All open OCSP issues are included in the list at https://wiki.mozilla.org/CA/Incident_Dashboard Wayne On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling v

Re: ComSign Root Renewal Request

gt; spoofing should be dealt with by registrars, and Web browsers should have > sensible policies for when to display the punycode versions of names." > > Doug > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+do

Re: Japan GPKI Root Renewal Request

On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote: > > This request by the Government of Japan, Ministry of Internal > > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' > > certificate and enable the Websites trust bit. This new root certificate > > h

Re: Misissued certificate with improper characters in DNSname

Stephen, Thanks for the report. I have a few questions: 1. Did you scan for any additional certificates containing this type of error that Quovadis or your subordinate CAs have issued? What were the findings? 2. Will the linting check be performed pre- or post-issuance? 3. When will the linting ch

Re: Mis-Issuance of a SSL multi-domain certificate

Thank you for reporting this issue. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1428877 to track the issue and SwissSign's response. - Wayne On Mon, Jan 8, 2018 at 5:08 AM, Reinhard Dietrich via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To whom it may

Re: 5.3.1 Technically Constrained

Ben, I'm about to use the term 'paragraph' to refer to the text within section 5.3.1 that is separated by carriage returns. The prior version of the policy contained the language in the final paragraph of section 5.3.1 - see https://github.com/mozilla/pkipolicy/commit/f96076a01ef10e5d6a84fa4b0422

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > I don't think that's true. If your host

Re: Incident report: Failure to verify authenticity for some partner requests

Thank you for the report Tim. I just created https://bugzilla.mozilla.org/show_bug.cgi?id=1429639 to track this issue. Please follow up in the bug and on this thread. - Wayne On Wed, Jan 10, 2018 at 2:24 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Thu, Jan 11, 2018 at 3:28 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > https://community.letsencrypt.org/t/2018-01-11-update-regard > ing-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > Speaking for myself, this is an excellent game plan that

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Doug, I have some questions: > > c.The hosting company must allow you to manually create and upload > a CSR for a site you don’t own > > Did you mean to say 'certificate' here instead of 'CSR'? d. The user must be able to trick the hosting provider to enable SNI > for this domain a

Re: Taiwan GRCA Root Renewal Request

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote: > On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote: > > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote: > > All, > > > > I requested that this CA perform a BR Self Assessment, and they

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie wrote: > > > Normally a web hosting provider should not let you set SNI for a domain > someone else is using, especially on that IP address. I think this is > where method 9 deviates from method 10. > > > I agree, it seems somewhat less likely that

Re: ComSign Root Renewal Request

To recap, we've established that this root was first BR audited on 26-April 2015 and has received clean period-of-time audits over the next two years. ComSign has disclosed 36 certificates issued by this root prior to the BR point-in-time audit, of which one remains unexpired. This does not meet

Updating Root Inclusion Criteria

I would like to open a discussion about the criteria by which Mozilla decides which CAs we should allow to apply for inclusion in our root store. Section 2.1 of Mozilla’s current Root Store Policy states: CAs whose certificates are included in Mozilla's root program MUST: > 1.provide some

Re: Camerfirma's misissued certificate

Thank you for reporting this misissuance. Since this is a different issue than described in bug 1390977, I have created a new bug to track this problem and your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also post your incident report here. Also, the crt.sh link above is

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek wrote: > I support "encouraging" those who are currently using the public web PKI > for > internal uses to move to their own private PKIs. The current situation is > an > artifact of the old notion that there should be a global "One CA List to > Rul

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor wrote: > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the > right rules for inclusion were. > > Yes, that is the challenge. So I decided to approach this from a different perspective: which is that I > think we shoul

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/2018 23:03, Jonathan Rudenberg wrote: > > You seem to be stuck inside some kind of ivory tower world where > computers are king and everything is done by robots. > > This

Re: Taiwan GRCA Root Renewal Request

This root inclusion request is currently in the public discussion phase [1] After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the following comments: ==Good== 1. GRCA has requested that this root be constrained to issuing certificates for .tw domains. 2. The BR Self Assess

Re: TLS-SNI-01 and compliance with BRs

Peter, On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or h

  1   2   3   4   5   6   7   >