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

2021-01-26 Thread Wayne Thayer via dev-security-policy
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

Re: Summary of Camerfirma's Compliance Issues

2020-12-22 Thread Wayne Thayer via dev-security-policy
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

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

2020-12-21 Thread Wayne Thayer via dev-security-policy
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

Re: Sectigo to Be Acquired by GI Partners

2020-10-01 Thread Wayne Thayer via dev-security-policy
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

Re: Change of Root ownership structure

2020-05-26 Thread Wayne Thayer via dev-security-policy
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,

Re: Status of the bugzilla bug list

2020-05-22 Thread Wayne Thayer via dev-security-policy
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

Re: Request to Include certSIGN Root CA G2 certificate

2020-05-08 Thread Wayne Thayer via dev-security-policy
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

Mozilla's Expectations for OCSP Incident Reporting

2020-05-08 Thread Wayne Thayer via dev-security-policy
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

Re: Change of Root ownership structure

2020-04-29 Thread Wayne Thayer via dev-security-policy
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

Re: Proposal for New CA Certificate Policy Module Owner

2020-03-30 Thread Wayne Thayer via dev-security-policy
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: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root

2020-03-29 Thread Wayne Thayer via dev-security-policy
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

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

2020-03-28 Thread Wayne Thayer via dev-security-policy
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: Musings on mass key-compromise revocations

2020-03-28 Thread Wayne Thayer via dev-security-policy
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

Fwd: Proposal for New CA Certificate Policy Module Owner

2020-03-20 Thread Wayne Thayer via dev-security-policy
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: Acceptable forms of evidence for key compromise

2020-03-14 Thread Wayne Thayer via dev-security-policy
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

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

2020-03-14 Thread Wayne Thayer via dev-security-policy
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

Re: About upcoming limits on trusted certificates

2020-03-04 Thread Wayne Thayer via dev-security-policy
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 time (e

Re: About upcoming limits on trusted certificates

2020-03-03 Thread Wayne Thayer via dev-security-policy
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

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

2020-02-07 Thread Wayne Thayer via dev-security-policy
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

Policy Module Ownership

2020-01-21 Thread Wayne Thayer via dev-security-policy
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: DRAFT January 2020 CA Communication

2020-01-07 Thread Wayne Thayer via dev-security-policy
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

Re: DRAFT January 2020 CA Communication

2020-01-06 Thread Wayne Thayer via dev-security-policy
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,

Re: DRAFT January 2020 CA Communication

2020-01-03 Thread Wayne Thayer via dev-security-policy
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: > > > > >

Re: DRAFT January 2020 CA Communication

2020-01-03 Thread Wayne Thayer via dev-security-policy
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: Audit Letter Validation (ALV) on intermediate certs in CCADB

2019-12-24 Thread Wayne Thayer via dev-security-policy
: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. > >

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

2019-12-23 Thread Wayne Thayer via dev-security-policy
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 more ge

Re: DRAFT January 2020 CA Communication

2019-12-23 Thread Wayne Thayer via dev-security-policy
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: DRAFT January 2020 CA Communication

2019-12-23 Thread Wayne Thayer via dev-security-policy
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 all CA

Re: Root Store Policy 2.7 Published

2019-12-23 Thread Wayne Thayer via dev-security-policy
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]

Re: Incident Reporting Guidance

2019-12-19 Thread Wayne Thayer via dev-security-policy
hese 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-policy < >>

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

2019-12-19 Thread Wayne Thayer via dev-security-policy
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

DRAFT January 2020 CA Communication

2019-12-19 Thread Wayne Thayer via dev-security-policy
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:

Re: Root Store Policy 2.7 Published

2019-12-16 Thread Wayne Thayer via dev-security-policy
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

Re: Incident Reporting Guidance

2019-12-11 Thread Wayne Thayer via dev-security-policy
n_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 meeting, I was asked to pr

Root Store Policy 2.7 Published

2019-12-11 Thread Wayne Thayer via dev-security-policy
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

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

2019-12-06 Thread Wayne Thayer via dev-security-policy
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]

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

2019-12-02 Thread Wayne Thayer via dev-security-policy
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

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

2019-11-25 Thread Wayne Thayer via dev-security-policy
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

Re: Trusted Recursive Resolver Policy in India

2019-11-21 Thread Wayne Thayer via dev-security-policy
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

Incident Reporting Guidance

2019-11-21 Thread Wayne Thayer via dev-security-policy
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

Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

2019-11-20 Thread Wayne Thayer via dev-security-policy
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

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

2019-11-20 Thread Wayne Thayer via dev-security-policy
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

How Certificates are Verified by Firefox

2019-11-19 Thread Wayne Thayer via dev-security-policy
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

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

2019-11-14 Thread Wayne Thayer via dev-security-policy
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

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

2019-11-08 Thread Wayne Thayer via dev-security-policy
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

Re: Next Root Store Policy Update

2019-10-30 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-30 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-28 Thread Wayne Thayer via dev-security-policy
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

Re: Policy 2.7 Proposal: Incident Reporting Updates

2019-10-28 Thread Wayne Thayer via dev-security-policy
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: Forbid Delegation of Email Validation for S/MIME Certificates

2019-10-28 Thread Wayne Thayer via dev-security-policy
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

Re: [FORGED] Firefox removes UI for site identity

2019-10-28 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-24 Thread Wayne Thayer via dev-security-policy
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: Policy 2.7 Proposal: Incident Reporting Updates

2019-10-22 Thread Wayne Thayer via dev-security-policy
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

2019-10-22 Thread Wayne Thayer via dev-security-policy
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, >> an >&

Re: Firefox removes UI for site identity

2019-10-22 Thread Wayne Thayer via dev-security-policy
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

Re: Firefox removes UI for site identity

2019-10-22 Thread Wayne Thayer via dev-security-policy
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: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

2019-10-22 Thread Wayne Thayer via dev-security-policy
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: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

2019-10-22 Thread Wayne Thayer via dev-security-policy
es. > 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 root store program ends up adding a > lot more complexity than you'd initially think. Delega

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

2019-10-22 Thread Wayne Thayer via dev-security-policy
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: Clarify Revocation Requirements for S/MIME Certificates

2019-10-21 Thread Wayne Thayer via dev-security-policy
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 carefully. >> &

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

2019-10-21 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-21 Thread Wayne Thayer via dev-security-policy
“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: Wednesday, Octobe

Re: Entrust Root Certification Authority - G4 Inclusion Request

2019-10-17 Thread Wayne Thayer via dev-security-policy
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,

Re: Entrust Root Certification Authority - G4 Inclusion Request

2019-10-08 Thread Wayne Thayer via dev-security-policy
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

Re: Mozilla Policy Requirements CA Incidents

2019-10-08 Thread Wayne Thayer via dev-security-policy
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: Policy 2.7 Proposal: Incident Reporting Updates

2019-10-04 Thread Wayne Thayer via dev-security-policy
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 >

Policy 2.7 Proposal: Update Appeal Process

2019-10-04 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-04 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-04 Thread Wayne Thayer via dev-security-policy
. 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 > > > -Original Message- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-s

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

2019-10-03 Thread Wayne Thayer via dev-security-policy
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)

Re: DigiCert OCSP services returns 1 byte

2019-10-03 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-02 Thread Wayne Thayer via dev-security-policy
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: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

2019-10-02 Thread Wayne Thayer via dev-security-policy
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

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

2019-10-02 Thread Wayne Thayer via dev-security-policy
> > 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 > < > > d

Re: Next Root Store Policy Update

2019-10-02 Thread Wayne Thayer via dev-security-policy
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

Re: DigiCert OCSP services returns 1 byte

2019-10-01 Thread Wayne Thayer via dev-security-policy
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)

Re: DigiCert OCSP services returns 1 byte

2019-09-30 Thread Wayne Thayer via dev-security-policy
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

Re: Outdated resource links on CCADB

2019-09-30 Thread Wayne Thayer via dev-security-policy
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

Re: DigiCert OCSP services returns 1 byte

2019-09-20 Thread Wayne Thayer via dev-security-policy
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos wrote: > > > Using the following practice as described in RFC 6960 should not be a > violation of the BRs. That is, answering revoked where a pre-certificate > has been issued but not the final certificate should be OK as long as the >

Re: Apple: Precertificates without corresponding certificates return OCSP value of "unknown"

2019-09-19 Thread Wayne Thayer via dev-security-policy
Thank you for the notification. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1582519 to track this issue. - Wayne On Fri, Sep 13, 2019 at 4:24 PM Apple CA via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We’ve been following the discussions regarding how

Re: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Wayne Thayer via dev-security-policy
I have gone ahead and added a section titled "Precertificates" [1] to the Required Practices wiki page. I have also updated a policy issue [2] suggesting that this be moved into the Root Store policy, and added a new issue [3] suggesting that we clarify the acceptable use of the "unknown" OCSP

Re: DigiCert OCSP services returns 1 byte

2019-09-18 Thread Wayne Thayer via dev-security-policy
Thanks Curt. Reading between the lines of Ryan's and your response, I'm thinking that we should specifically ban or limit the scope of "unknown" responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves some room for a CA to argue that they are permitted to use that response in

CCADB Policy Update: Exceptions to Policies, Practices, and Audit Information

2019-09-18 Thread Wayne Thayer via dev-security-policy
When Rob Stradling announced the excellent addition of the "inconsistent Audit details" and Inconsistent CP/CPS Details" sections to the crt.sh Mozilla CA Certificate Disclosures report [1], we discovered some inconsistencies between Mozilla's expectations and CCADB policy [2]. To correct this,

Re: DigiCert OCSP services returns 1 byte

2019-09-17 Thread Wayne Thayer via dev-security-policy
Version 3 of my proposal replaces Jeremy's suggested examples with Andrew and Ryan's: The current implementation of Certificate Transparency does not provide any > way for Relying Parties to determine if a certificate corresponding to a > given precertificate has or has not been issued. It is

Re: CRL for decommissioned CA

2019-09-17 Thread Wayne Thayer via dev-security-policy
On Tue, Sep 17, 2019 at 8:23 AM nenyotoso--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi, > > While Japanese ApplicationCA2 Root has been rejected as a Root CA [1] and > is no longer in operation [2], > I become aware of CRL endpoint of both the CA and at least

Re: DigiCert OCSP services returns 1 byte

2019-09-16 Thread Wayne Thayer via dev-security-policy
On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: > > > If a certificate (with embedded SCTs and no CT poison extension) is > "presumed to exist" but the CA has not actually issued it, then to my > mind that's a "certificate

Re: Trusted Recursive Resolver Policy in India

2019-09-13 Thread Wayne Thayer via dev-security-policy
Rich: I want to acknowledge your question, which I think is really "what is the right forum for Mozilla TRR (DNS over HTTPS) policy [1] discussions?" I don't currently have an answer for you, but will respond when I do. - Wayne [1] https://wiki.mozilla.org/Security/DOH-resolver-policy On Wed,

Re: DigiCert OCSP services returns 1 byte

2019-09-13 Thread Wayne Thayer via dev-security-policy
Thanks everyone for your feedback! I'm sensing that the proposed language is generally helpful. I've made two updates: * Accepted Jeremy's proposed language for the examples in the last paragraph. * attempted to address Tim Shirley's point that a precertificate is not literally "proof" that a

Re: Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

2019-09-13 Thread Wayne Thayer via dev-security-policy
Thank you for the report and follow-up Andy. I created https://bugzilla.mozilla.org/show_bug.cgi?id=1581183 to track this issue. - Wayne On Fri, Sep 13, 2019 at 10:19 AM Andy Warner via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A quick follow-up to close this out. >

Re: Request to Include 4 Microsoft Root CAs

2019-09-11 Thread Wayne Thayer via dev-security-policy
Having received no further comments, I have recommended approval of this request in bug 1448093. - Wayne On Thu, Sep 5, 2019 at 5:16 PM Wayne Thayer wrote: > Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV. > > Unless a CA has an existing EV policy OID associated with root(s) in our >

Re: DigiCert OCSP services returns 1 byte

2019-09-11 Thread Wayne Thayer via dev-security-policy
d "good" unless the pre-cert is > revoked? Responding unknown means the CA wouldn't know that they issued the > cert, which means they disagree with the proof that a corresponding cert > has been issued. > > Jeremy > > -Original Message----- > From: dev-security-poli

Re: DigiCert OCSP services returns 1 byte

2019-09-11 Thread Wayne Thayer via dev-security-policy
Mozilla has, to-date, not published policies related to Certificate Transparency, but this is a case where a clarification would be helpful. I propose adding the following language to our "Required Practices" wiki page [1]: The current implementation of Certificate Transparency does not provide

Re: Auditor letters and incident reports

2019-09-06 Thread Wayne Thayer via dev-security-policy
Thanks for the response Jeff. On Fri, Sep 6, 2019 at 4:17 PM jeffwardpki--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, August 21, 2019 at 11:46:37 PM UTC-5, Jeremy Rowley wrote: > > Hey all, > > > > An interesting issue came up recently with audits.

Re: Request to Include 4 Microsoft Root CAs

2019-09-05 Thread Wayne Thayer via dev-security-policy
Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV. Unless a CA has an existing EV policy OID associated with root(s) in our program, we have been strongly encouraging the use of the CAB Forum OID. This request is past the 3-week minimum discussion period. If no significant comments are

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-26 Thread Wayne Thayer via dev-security-policy
On Mon, Aug 26, 2019 at 5:39 AM Josef Schneider via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane: > > On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote: > > > Deploying a Stripe Inc EV SSL from a

Re: Nation State MITM CA's ?

2019-08-21 Thread Wayne Thayer via dev-security-policy
(resending because the first attempt was not posted to the list) Mozilla has announced our response to the Kazakhstan MITM: https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/ and

Re: Nation State MITM CA's ?

2019-08-21 Thread Wayne Thayer via dev-security-policy
Mozilla has announced our response to the Kazakhstan MITM: https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/ and https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/ Note: we're in the process of adding the "Qaznet" root

Request to Include 4 Microsoft Root CAs

2019-08-13 Thread Wayne Thayer via dev-security-policy
This request is for inclusion of the Microsoft RSA Root Certificate Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate Authority 2017 trust anchors as documented in the following bug:

Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-12 Thread Wayne Thayer via dev-security-policy
Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which is expected to be released on 22-October. Details below. If the before and after images are stripped from the email, you can view them here: Before:

Entrust Root Certification Authority - G4 Inclusion Request

2019-07-26 Thread Wayne Thayer via dev-security-policy
This request is to include the Entrust Root Certification Authority - G4 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480510 * BR Self Assessment is here: https://bug1480510.bmoattachments.org/attachment.cgi?id=8997108 * Summary of Information Gathered and

  1   2   3   4   5   6   7   >