https://wiki.mozilla.org/api.php?action=feedcontributions&user=Gerv&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T05:43:29ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=MOSS/Friends&diff=1189238MOSS/Friends2018-02-20T20:14:24Z<p>Gerv: Change contact details</p>
<hr />
<div>Whether your MOSS application is successful or not, you may be interested in (additional) ways of raising money to support your project. We know of the following organizations which may be able to provide financial support or help you raise it, or provide infrastructure for doing so. (The text about each organization was supplied by that organization.)<br />
<br />
==Core Infrastructure Initiative==<br />
<br />
The [https://www.coreinfrastructure.org/ Core Infrastructure Initiative] (CII) is a program within the Linux Foundation to substantially improve security outcomes for the FOSS projects on which the internet, and the businesses built on it, depend. The CII supports a variety of projects ranging from security specific tools and libraries such as OpenSSH and OpenSSL to core components such as ntpd. The CII also supports projects to identify key, at risk projects, to locate and responsibly report vulnerabilities, create tooling to make development more secure by default and to improve security process in FOSS projects.<br />
<br />
==Liberapay==<br />
<br />
[https://liberapay.com/ Liberapay] is an [https://github.com/liberapay open source] recurrent donations platform whose primary purpose is to help fund FOSS. Its currency is the euro and its legal structure is a non-profit organization based in France. The service was launched in early 2016, it has quite a few features and is translated into several languages. Everyone is welcome on Liberapay: individuals, nonprofits, businesses, and even [https://liberapay.com/about/teams collectives that don't have a legal entity].<br />
<br />
==Gratipay==<br />
<br />
[https://gratipay.com/ Gratipay] helps companies sustain the open-source ecosystem they depend on, through weekly recurring funding. As of late 2016 there are over 200 projects on Gratipay, which have collectively received more than $1M over the past four years. Gratipay itself is an [http://inside.gratipay.com/big-picture/welcome open organization], and is [https://gratipay.com/Gratipay/ funded] on Gratipay. [https://gratipay.com/new Apply here].<br />
<br />
==OpenCollective==<br />
<br />
[https://opencollective.com/ OpenCollective] helps open source projects, online communities and meetups to raise money through donations and spend it transparently. No need of a legal entity or bank account. Open Collective acts as their fiscal sponsor providing a dedicated page to manage the funds, submit expenses and invoices and get reimbursed for them. <br />
<br />
An Open Collective is an group of people with a shared mission that handles its financials transparently. Many open source projects have set up collectives to allow their community to chip and make their work sustainable for the future. [https://opencollective.com/create Apply here].<br />
<br />
==Open Technology Fund==<br />
<br />
The [http://www.opentech.fund Open Technology Fund] (OTF) supports open technologies and communities that increase free expression, circumvent censorship, and obstruct repressive surveillance as a way to promote human rights and open societies. OTF funding mechanisms include support for both organizations and individuals working on technologies that expand internet freedom globally.<br />
<br />
OTF focuses on funding efforts that increase access to the internet (including tools to circumvent website blocks, connection blackouts, and widespread censorship); enhance privacy (including the ability to be free from repressive observation and enable online anonymity); strengthen digital security (including encryption tools and holistic security assessments); and raise awareness among at-risk users and communities of the aforementioned technologies. [http://www.opentech.fund/apply Apply here].<br />
<br />
==snowdrift.coop==<br />
<br />
[https://snowdrift.coop/ Snowdrift.coop] funds public goods through their sustainable crowdmatching system. Patrons pledge to donate to their chosen projects a tiny amount monthly, multiplied by the number of patrons who donate together. This mutual assurance helps address the freerider / public-goods dilemmas faced by public goods including software, art, research, journalism, educational resources, and more.<br />
<br />
While not fully operating yet (as of late 2016), Snowdrift.coop hopes to have a successful prototype launch and then begin full operations soon. The core requirements include free/libre/open licensing, and the focus will be on downstream, ongoing projects that have the potential to reach a wide audience. The platform itself will run as a non-profit cooperative with membership open to all participants.<br />
<br />
==Software Freedom Conservancy==<br />
<br />
-----<br />
<br />
If you think your organization should be mentioned here, email jochai at mozilla dot com.</div>Gervhttps://wiki.mozilla.org/index.php?title=Modules/Activities&diff=1189125Modules/Activities2018-02-17T12:14:32Z<p>Gerv: Move self to emeritus</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Governance<br />
|description=Policies and process for how we distribute authority and govern ourselves; including:<br />
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility<br />
* Management of the source tree<br />
* Balancing different constituencies of the Mozilla project<br />
* Maintaining the Mozilla identity as we take on new activities<br />
<br />
[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=governance<br />
|url=https://wiki.mozilla.org/GovernanceIssues<br />
|components=mozilla.org::Governance<br />
}}<br />
<br />
===Governance Sub Modules===<br />
<br />
{{Module<br />
|name=Module Ownership System<br />
|description=Healthy operation of the module ownership system, including topics such as:<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve.<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners <br />
|owner= [mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:dmose@mozilla.org Dan Mosedale], [mailto:kairo@kairo.at Robert Kaiser], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dbaron@dbaron.org David Baron], [mailto:dascher@mozilla.com David Ascher], [mailto:mitchell@mozilla.org Mitchell Baker], Guillermo Movia (as 'observer'. This is a new role we're trying out as of Jan 2012. The observers are watching and learning how the module operates, since there's no code in this module to serve as a learning /participation tool.)<br />
|ownersemeritus=Brendan Eich<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Policy<br />
|description=<br />
|owner=[mailto:mconnor@mozilla.com Mike Connor]<br />
|peers=<br />
|ownersemeritus=Mitchell Baker<br />
|group=<br />
|url=http://www.mozilla.org/hacking/committer/<br />
|components=mozilla.org::Miscellaneous<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Implementation<br />
|description= Governance structure for the work of enforcing and implementing Mozilla's commit access policy.<br />
|owner=[mailto:marcia@mozilla.com Marcia Knous]<br />
|peers=[mailto:jmatthews@mozilla.com Josh Matthews]<br />
|group=<br />
|url=https://wiki.mozilla.org/Commit_Access_Implementation_module<br />
|components=mozilla.org::Repository Account Requests<br />
}}<br />
<br />
{{Module<br />
|name=Security Policy<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:security@mozilla.org Al Billings]<br />
|group=dev-security<br />
|url=http://www.mozilla.org/security/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla CA Certificate Policy<br />
|description=Definition and enforcement of policies governing Certification Authorities, their root certificates included in Mozilla software products, and intermediate and end-entity certificates within those CA hierarchies.<br />
|owner=[mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|peers=[mailto:gerv@mozilla.org Gervase Markham], [mailto:wthayer@mozilla.com Wayne Thayer]<br />
|ownersemeritus=Frank Hecker<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes<br />
|group=dev-security-policy<br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Code Review Policy<br />
|description=<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=<br />
|url=http://www.mozilla.org/hacking/reviewers.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Performance Regression Policy<br />
|description=<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|group=<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Planet Mozilla<br />
|description=Content and policy for planet.mozilla.org, including topics such as:<br />
* which blogs are syndicated to planet.mozilla.org<br />
* which content from syndicated blogs is included<br />
* other planet.mozilla.org policy issues <br />
|owner=[mailto:mhoye@mozilla.com Mike Hoye]<br />
|peers=[mailto:asa@reedloden.org Asa Dotzler]<br />
|group=<br />
|url=<br />
|components=Websites::planet.mozilla.org<br />
|ownersemeritus=Robert Accettura<br />
|peersemeritus=Reed Loden<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla Public License<br />
|description=Maintenance and development of the MPL<br />
* changes in the legal landscape which could /should be reflected<br />
* changes in FLOSS development practices which could / should be reflected <br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:handerson@mozilla.com Harvey Anderson], [mailto:MeekerH@gtlaw.com Heather Meeker], [mailto:villalu@gtlaw.com Luis Villa]<br />
|peersemeritus=Gervase Markham<br />
|group=governance-mpl-update<br />
|url=<br />
|components=mozilla.org::Licensing<br />
}}<br />
<br />
{{Module<br />
|name=CA Certificates<br />
|description=Determine which root certificates should be included in Mozilla software products, which trust bits should be set on them, and which of them should be enabled for EV treatment. Evaluate requests from Certification Authorities (CAs) for inclusion or removal of root certificates, and for updating trust bit settings or enabling EV treatment for already included root certificates.<br />
|owner=[mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|peers=[mailto:gerv@mozilla.org Gervase Markham], [mailto:sleevi@google.com Ryan Sleevi], [mailto:wthayer@mozilla.com Wayne Thayer]<br />
|ownersemeritus=Frank Hecker<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes<br />
|group=dev-security-policy <br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=mozilla.org::CA Certificates<br />
}}<br />
<br />
{{Module<br />
|name=Participation Metrics<br />
|description=Develop, monitor and analyze metrics relating to participation in the Mozilla project, including such things as:<br />
* determining which questions are most important to ask (how many people do X?)<br />
* determining what data is relevant to answer these questions<br />
* designing and operating a system to generate the requested data<br />
* analyzing the resulting metrics<br />
* notifying appropriate people when participation starts to change significantly<br />
* assisting various groups to understand and use the metrics to strengthen participation<br />
* produce periodic report/analysis of participation metrics <br />
|owner=[mailto:ppapadeas@mozilla.com Pierros Papadeas]<br />
|peers=[mailto:dboswell@mozilla.com David Boswell], [mailto:asa@mozilla.com Asa Dotzler], [mailto:deinspanjer@mozilla.com Daniel Einspanjer], [mailto:aelliott@mozilla.com Annie Elliott], [mailto:david@eaves.ca David Eaves], [mailto:michelle@mozillafoundation.org Michelle Thorne], [mailto:ryan@mozillafoundation.org Ryan Merkley]<br />
|group=<br />
|url=https://wiki.mozilla.org/Contribute/Dashboards<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Productive Communications Module (aka the "Conductors")<br />
|description=Promotion of productive communications styles within Mozilla, where "productive" means simultaneously honest and civil. This includes topics such as:<br />
*coaching people on who to respond to nasty settings;<br />
*coaching people to think a little before they hit post/send/submit.<br />
*coaching people on how to be direct and yet civil, notifying people they are at or past the boundary;<br />
*coaching people to recognize legitimate comments/ complaints / differences of opinion despite poor communication style<br />
*redirecting conversations into a better place,<br />
*building a culture of respect in how we communicate with difficult and contentious issues<br />
*when necessary, letting people know they've gone beyond the boundaries.<br />
|owner=Stormy Peters<br />
|peers=David Ascher , Dietrich Ayala, Mike Beltzner, Matt Claypotch, David Eaves, Gen Kanai, Michelle Luna, Kev Needham, Johnathan Nightingale, Melissa Shapiro, Gavin Sharp, Benjamin Smedberg, Mike Taylor (Bear), David Tenser, Daniel Veditz, [mailto:conductors@mozilla.org conductors@mozilla.org] (collectively)<br />
|group=mozilla.governance<br />
|url=http://wiki.mozilla.org/Conductors<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Internet Public Policy<br />
|description=Mozilla activities related to Public Policy issues that affect the health of the Internet. Our working definition of Public Policy is taken from Wikipedia: "courses of action, regulatory measures, laws, and funding priorities concerning a given topic promulgated by a governmental entity or its representatives." <br />
This includes topics such as:<br />
*determining if Mozilla should take an official position on a particular public policy issue<br />
*determining what that position is <br />
*determining how mozilla communicates our position <br />
**global, multi-regional, regional or local action<br />
**direct action, or support of action by other aligned groups<br />
**public campaigns or opinion pieces or educational activities, dialog with policy makers, other techniques TBD<br />
*strengthening local community capabilities to address public policy issues <br />
|owner=[mailto:handerson@mozilla.com Harvey Anderson]<br />
|peers=[mailto:mitchell@mozilla.org Mitchell Baker], [mailto:afowler@mozilla.com Alex Fowler], [mailto:mark@mozillafoundation.org Mark Surman]<br />
|url=https://wiki.mozilla.org/Netpolicy<br />
|group=https://mail.mozilla.org/listinfo/netpolicy<br />
|components=<br />
|notes=Area Expert Advisors: Katharina Borchert, Andrew Bridges, Hanno Kaiser, Andrew McLaughlin, Danny Weitzner, Gene Kimmelman, and Ronaldo Lemos<br />
}}<br />
Area Expert Advisors are people with particular expertise who have agreed to assist Mozilla with their area-specific expertise. The Area Expert Advisors are different from peers. A peer is someone to whom the module owner has delegated some of her/his authority and a peer is expected to provide leadership for Mozilla within our specific context. Area Expert Advisors are advisors to Mozilla. They may become peers, but they need not. <br />
<br />
<br />
{{Module<br />
|name=Weekly Project All Hands Meeting<br />
|description=Responsibility for the weekly meetings, including:<br />
* determining and implementing the best organization and structure for the meeting<br />
* Determining and implementing the most useful content<br />
* Identifying and implementing technical means to make the meeting accessible and interactive for participants around the globe<br />
|owner=[mailto:potch@mozilla.com Matt Claypotch]<br />
|peers=[mailto:asa@mozilla.org Asa Dotzler], MoCo Desktop IT services<br />
|group=mozilla.governance<br />
|url=https://wiki.mozilla.org/WeeklyUpdates<br />
|components=<br />
}}<br />
<br />
(It's a new thing to have a group such as "MoCo Desktop IT services" as a<br />
"peer." We're trying this based on the idea that anyone in the Desktop IT group<br />
should be able to resolve problems and make fixes to the systems.)<br />
<br />
===Other===<br />
<br />
{{Module<br />
|name=Popcorn Events<br />
|description=Events to support and grow the popcorn project. These include hack days pairing web developers and media creators, as well as Learning Labs to teach popcorn.js and Popcorn Maker.<br />
|owner=[mailto:brett@mozillafoundation.org Brett Gaylor]<br />
|peers=[mailto:michelle@mozillafoundation.org Michelle Thorne]<br />
|group=mozilla.community.popcorn<br />
|url=http://www.mozillapopcorn.org/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Tree Sheriffs<br />
|description=Tree Sheriffs aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines. <br />
|owner=[mailto:rvandermeulen@mozilla.com Ryan VanderMeulen] (RyanVM)<br />
|peers=[mailto:wkocher@mozilla.com Wes Kocher (KWierso)], [mailto:cbook@mozilla.com Carsten Book (Tomcat)]<br />
|group=dev-tree-management<br />
|url=https://wiki.mozilla.org/Sheriffing<br />
|components=Tree Management::Visibility Requests<br />
}}</div>Gervhttps://wiki.mozilla.org/index.php?title=Modules/Bugzilla&diff=1188874Modules/Bugzilla2018-02-12T17:10:30Z<p>Gerv: Make myself a Bugzilla peer emeritus, rather than a peer, as I have resigned</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Bugzilla<br />
|description=The bug-tracking web application from Mozilla<br />
|owner=[mailto:justdave@bugzilla.org Dave Miller]<br />
|ownersemeritus=Terry Weissman, Tara Hernandez<br />
|peers=[mailto:dylan@mozilla.com Dylan Hardison]<br />
|peersemeritus=Gervase Markham, Mark Côté, Byron Jones, Simon Green, Max Kanat-Alexander, Frédéric Buclin, Chris Yeh, Dan Mosedale<br />
|group=dev-apps-bugzilla<br />
|source_dirs=[http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=summary bugzilla/]<br />
|url=http://www.bugzilla.org/<br />
|components=<br />
}}<br />
<br />
===Sub Modules===<br />
<br />
{{Module<br />
|name=Administration<br />
|description=Pages related to the administration of a Bugzilla installation, features oriented. <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Administration<br />
}}<br />
<br />
{{Module<br />
|name=Attachments<br />
|description=Attachment creation and management<br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Attachments & Requests<br />
}}<br />
<br />
{{Module<br />
|name=Authentication<br />
|description=Authentication API, communication and interactions between Bugzilla installations<br />
|owner=<br />
|peers=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Bug creation and modification <br />
|description=Creating, changing, and viewing bugs <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Creating/Changing Bugs<br />
}}<br />
<br />
{{Module<br />
|name=Charting system<br />
|description=Old and new chart systems <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Reporting/Charting<br />
}}<br />
<br />
{{Module<br />
|name=Databases<br />
|description=Interface with databases, database support <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Database<br />
}}<br />
<br />
{{Module<br />
|name=Documentation<br />
|description=Bugzilla documentation <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Documentation<br />
}}<br />
<br />
{{Module<br />
|name=Email notifications <br />
|description=Emails sent during bug changes, including flags <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Email Notifications<br />
}}<br />
<br />
{{Module<br />
|name=Exporting and Importing <br />
|description=Importing and exporting bug reports with another Bugzilla installation <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Bug Import/Export & Moving<br />
}}<br />
<br />
{{Module<br />
|name=Extensions and Hooks <br />
|description=Everything related to extensions, including adding/modifying hooks <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Extensions<br />
}}<br />
<br />
{{Module<br />
|name=Flags and Requests <br />
|description=Flag system <br />
|owner=<br />
|peers=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Installation and Upgrading <br />
|description=Installing a fresh copy of Bugzilla, or upgrading from an older installation <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Installation & Upgrading<br />
}}<br />
<br />
{{Module<br />
|name=Search system and Queries <br />
|description=Mostly include Search.pm code and the way data are passed to it and returned <br />
|owner=<br />
|peers=<br />
|components=Bugzilla::Query/Bug List<br />
}}<br />
<br />
{{Module<br />
|name=Security<br />
|description=Security related stuff <br />
|owner=bugzilla-security group<br />
|peers=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=User Interface <br />
|description=Design of Bugzilla pages, as well as workflow <br />
|owner= <br />
|peers=<br />
|components=Bugzilla::User Interface<br />
}}<br />
<br />
<noinclude><br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Bugzilla project have not been assigned to a module:<br />
<br />
<pre><br />
Bugzilla::Bugzilla-General<br />
Bugzilla::bugzilla.org<br />
Bugzilla::Dependency Views<br />
Bugzilla::Incoming Email<br />
Bugzilla::Testing Suite<br />
Bugzilla::User Accounts<br />
Bugzilla::WebService<br />
Bugzilla::Whining<br />
</pre><br />
</noinclude></div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS/Talking_About_Your_MOSS_Award&diff=1188691MOSS/Talking About Your MOSS Award2018-02-07T20:05:19Z<p>Gerv: </p>
<hr />
<div>So you've been awarded a MOSS award - congratulations! The continued viability of the MOSS program depends on people continuing to apply, and Mozilla continuing to want to fund it. Both of these things are assisted if you mention MOSS positively when you talk about the MOSS-funded work you are doing or the audit you had, whether in a blog post, conference talk or other medium. People who hear your talk or read your blog post may want to apply, and Mozilla is more likely to continue to fund the program if it can see that it generates positive goodwill for Mozilla, and that we get appropriate recognition for the money we are awarding.<br />
<br />
== General Guidance ==<br />
<br />
* Please don't start telling the world you've been awarded a MOSS award until after the contract is fully signed by all parties. (Your contract signer should be notified when this happens.) While we want very much to make all the awards we approve, this way, no-one ever gets disappointed or misled.<br />
* Please refer to it as a MOSS "award", not a MOSS "grant" or MOSS "contract". The word "grant" is not appropriate for some types of award, and we like to keep the language neutral. So this means you were "awarded" it, not "given" it.<br />
* The first time you mention MOSS, expand the acronym. So:<br />
<br />
<blockquote><br />
We recently were awarded a Mozilla Open Source Support (MOSS) award to improve our API documentation. MOSS is a program from Mozilla...<br />
</blockquote><br />
<br />
* If your project got an SOS Fund audit, use instead "an audit from Mozilla's SOS Fund".<br />
* The best URL to link back to is https://mozilla.org/moss . That link works for all award types, is a professional-looking site rather than a wiki, and helps people get their heads around the program.<br />
* If you are able to, please include the call-to-action with words something like the following: <br />
<br />
<blockquote><br />
MOSS has a number of types of award, which are open to different sorts of open source/free software project. If your project is looking for financial support, do check &lt;a href="<nowiki>https://mozilla.org/moss</nowiki>"&gt;the website&lt;/a&gt; to see if you qualify.<br />
</blockquote><br />
<br />
== Contracts ==<br />
<br />
=== Confidentiality ===<br />
<br />
Some MOSS contracts have the following clause:<br />
<br />
<blockquote><br />
3. CONFIDENTIALITY<br />
<br />
3.1. Definition. The Parties agree that the terms of this Agreement shall be considered “Confidential Information.”<br />
<br />
3.2. Obligations. The Parties agree: (i) to hold and maintain in strict confidence the Confidential<br />
Information and not to disclose it to any third party other than their employees and<br />
subcontractors who have a need to know and have executed confidentiality agreements with the<br />
Party that are no less protective of the Confidential Information than this section; and (ii) to<br />
protect the Confidential Information from disclosure with the same degree of care they use to<br />
protect their own proprietary information similar in nature, but in no event less than a reasonable<br />
degree of care.<br />
</blockquote><br />
<br />
Mozilla does not consider "this Agreement" to cover the SoW attached to the agreement. So you are welcome to tell the world about your planned work, milestones and financial remuneration in as much detail as you choose. Mozilla will normally (but not always) speak publicly about the total amount of the award and the work involved, but not any financial breakdown.<br />
<br />
=== Press Releases ===<br />
<br />
Some MOSS contracts have the following clause:<br />
<br />
<blockquote><br />
6. PRESS RELEASES<br />
<br />
Neither Party will issue any press releases regarding this Agreement or relationship without the prior review by and written approval of the other Party.<br />
</blockquote><br />
<br />
We consider a press release to be any document released by you where you draw to it the specific attention of any newswire, newspaper, online news source, or other organization or person who could be reasonably called a journalist. Otherwise, there is no need to notify. A post on your or a project blog, for example, would not normally fall under this clause. If your posting does require this approval, email Gerv with the details, the outlet(s) concerned and the full text.<br />
<br />
<hr><br />
<br />
If you are uncertain about how to talk about your MOSS award, please do contact Gerv who would be happy to help you.</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS&diff=1188608MOSS2018-02-06T17:25:28Z<p>Gerv: /* Applicant/Awardee Resources */</p>
<hr />
<div>Mozilla Open Source Support (MOSS) has a [https://www.mozilla.org/moss new website] - see there for a program overview. You can also read our [https://blog.mozilla.org/wp-content/uploads/2017/04/MOSS_2016_review_april_25-v.1.0.pdf 2016 Review and 2017 Strategic Plan].<br />
<br />
MOSS currently has 3 tracks:<br />
<br />
* MOSS Track 1 - [[MOSS/Foundational Technology|Foundational Technology]]<br />
* MOSS Track 2 - [[MOSS/Mission Partners|Mission Partners]]<br />
* MOSS Track 3 - [[MOSS/Secure Open Source|Secure Open Source]]<br />
<br />
Use the links above to find out about each track, including details on how to apply. To stay informed about and involved with MOSS in general, please join the MOSS [https://www.mozilla.org/en-US/about/forums/#moss discussion forum]. And whether you apply successfully or not, if your open source project is looking for support you may be interested in contacting some of our [[MOSS/Friends|friends]].<br />
<br />
==Application Deadlines==<br />
<br />
We consider MOSS applications in batches; deadline for the next batch is the last day of January 2018, and then every three months thereafter. Missing a deadline may cause a delay in the consideration of your application.<br />
<br />
==Selection Committee==<br />
<br />
We have formed a selection committee of 8 participants to assess awards on Tracks 1 and 2, as follows:<br />
<br />
* '''Current Committed Mozillians''' - they bring a good working knowledge of Mozilla's day-to-day activities and how various open source projects are used.<br />
** [https://mozillians.org/en-US/u/lthomson/ Laura Thomson]<br />
** [https://ritter.vg/ Tom Ritter]<br />
<br />
* '''Senior Mozilla Alumni''' - they are no longer actively involved with Mozilla on a day-to-day basis but have a deep understanding of our project and a different/outside perspective.<br />
** [http://stormyscorner.com/ Stormy Peters]<br />
** [http://shaver.off.net/diary/ Mike Shaver]<br />
** [https://mozillians.org/en-US/u/rbarnes/ Richard Barnes]<br />
<br />
* '''Other Open Source Experts''' - they bring knowledge of the role of different projects within the open source ecosystem.<br />
** [http://www.cmu.edu/iii/innovators/faculty-staff/wasserman.html Tony Wasserman]<br />
** [https://www.justindorfman.com/ Justin Dorfman]<br />
<br />
==Applicant/Awardee Resources==<br />
<br />
The application form has an "Outcomes" section, and any award will require a contract or agreement with a Schedule of Work (SoW) which defines what work is to be done. Both of those things might benefit from examining a sample Schedule of Work.<br />
<br />
* [[Media:Tor-sow.odt|Sample Schedule of Work (SoW) for Tor Project Metrics]]<br />
* [[Media:Kea-sow.pdf|Sample Schedule of Work (SoW) for Kea DHCP Server]]<br />
<br />
If your application is successful and you find yourself doing a blog post or conference talk about your work, we would appreciate a mention. Find some useful guidance at [[MOSS/Talking About Your MOSS Award|Talking About Your MOSS Award]].<br />
<br />
==Mentors==<br />
<br />
Some projects may want to apply for a MOSS award but be nervous about preparing a proposal. We have identified some mentors who are willing to help with this, and you should feel free to contact any of them: <br />
<br />
* [https://mozillians.org/u/dbryant/ David Bryant]. David is Mozilla's VP of Platform Engineering, so he is obviously clueful about software, and he’s also signed on to assist with the topics of project needs, possible solutions and appropriate amounts.<br />
* [https://mozillians.org/u/pfinette/ Pascal Finette]. Pascal launched [http://webfwd.org WebFWD] when he was a Mozilla employee and now runs Singularity University’s [http://startup.singularityu.org/accelerator/ accelerator program]. Pascal has a long history and an abiding love of working with people to build things. He has great expertise in this type of task, matching by his abiding interest in contributing to Mozilla.<br />
<br />
==Recipients==<br />
<br />
* [https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/ 2015-12-10]: Buildbot, CodeMirror, Discourse, Read The Docs, Mercurial, Django, Bro<br />
* [https://blog.mozilla.org/blog/2016/04/13/mozilla-open-source-support-moss-update-q1-2016/ 2016-04-13]: Django REST Framework, The Intern<br />
* [https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/ 2016-06-22]: Tor, Tails, Caddy, Mio, DNSSEC/DANE Chain Stapling, Godot Engine, PeARS, NVDA<br />
* [https://blog.mozilla.org/blog/2016/08/04/mozilla-awards-585000-to-nine-open-source-projects-in-q2-2016/ 2016-08-04]: PyPy<br />
* [https://blog.mozilla.org/blog/2016/10/03/moss-supports-four-more-open-source-projects-with-300k/ 2016-10-03]: Redash, Review Board, Kea, Speech Rule Engine<br />
* [https://blog.mozilla.org/blog/2017/04/10/mozilla-awards-365000-to-open-source-projects-as-part-of-moss/ 2017-04-10]: SecureDrop, libjpeg-turbo, LLVM, LEAP Encryption Access Project, Tokio<br />
* [https://blog.mozilla.org/blog/2017/10/03/mozilla-awards-half-million-open-source-projects/ 2017-10-03]: Ushahidi, webpack, RiseUp, Phaser, mod_md<br />
* ...</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS/Talking_About_Your_MOSS_Award&diff=1188593MOSS/Talking About Your MOSS Award2018-02-06T15:20:46Z<p>Gerv: Initial version</p>
<hr />
<div>So you've been awarded a MOSS award - congratulations! The continued viability of the MOSS program depends on people continuing to apply, and Mozilla continuing to want to fund it. Both of these things are assisted if you mention MOSS positively when you talk about the MOSS-funded work you are doing or the audit you had, whether in a blog post, conference talk or other medium. People who hear your talk or read your blog post may want to apply, and Mozilla is more likely to continue to fund the program if it can see that it generates positive goodwill for Mozilla, and that we get appropriate recognition for the money we are awarding.<br />
<br />
* Please don't start telling the world you've been awarded a MOSS award until after the contract is fully signed by all parties. (Your contract signer should be notified when this happens.) While we want very much to make all the awards we approve, this way, no-one ever gets disappointed or misled.<br />
* Please refer to it as a MOSS "award", not a MOSS "grant" or MOSS "contract". The word "grant" is not appropriate for some types of award, and we like to keep the language neutral. So this means you were "awarded" it, not "given" it.<br />
* The first time you mention MOSS, expand the acronym. So:<br />
<br />
<blockquote><br />
We recently were awarded a Mozilla Open Source Support (MOSS) award to improve our API documentation. MOSS is a program from Mozilla...<br />
</blockquote><br />
<br />
* If your project got an SOS Fund audit, use instead "an audit from Mozilla's SOS Fund".<br />
* The best URL to link back to is https://mozilla.org/moss . That link works for all award types, is a professional-looking site rather than a wiki, and helps people get their heads around the program.<br />
* If you are able to, please include the call-to-action with words something like the following: <br />
<br />
<blockquote><br />
MOSS has a number of types of award, which are open to different sorts of open source/free software project. If your project is looking for financial support, do check &lt;a href="<nowiki>https://mozilla.org/moss</nowiki>"&gt;the website&lt;/a&gt; to see if you qualify.<br />
</blockquote><br />
<br />
If you are uncertain about how to talk about your MOSS award, please do contact Gerv who would be happy to help you.</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS/Secure_Open_Source/Completed&diff=1188436MOSS/Secure Open Source/Completed2018-02-02T17:39:41Z<p>Gerv: Add Knot DNS</p>
<hr />
<div>Secure Open Source has completed the following audits.<br />
<br />
==2018==<br />
<br />
===Knot DNS===<br />
<br />
Dates: September 2017 - January 2018<br />
<br />
[https://www.knot-dns.cz/ Knot DNS] is a high-performance authoritative-only DNS server which supports all key features of the modern domain name system. Also audited was [https://www.knot-resolver.cz/ Knot Resolver], a caching full DNS resolver implementation, including both a resolver library and a daemon. The audit was performed by [https://leastauthority.com/ Least Authority].<br />
<br />
The team found the following problems:<br />
<br />
* 4 Medium<br />
* 7 Low<br />
* 2 Informational<br />
<br />
Least Authority made the following comment on the code quality: "Overall, we found the code to be well structured and cleanly written. Additionally Knot makes good use of available tools, such as fuzzers and compiler sanitizers."<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Knot-dns-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1FUlxVZdtlr6cDNtsHlzBI1d0IpGA_ey7zY-_xv-VWRM/edit# Fix and validation log]<br />
<br />
==2017==<br />
<br />
===CakePHP===<br />
<br />
Dates: July - November 2017<br />
<br />
[https://cakephp.org/ CakePHP] is an open source web framework in PHP. The audit was performed by [https://www.nccgroup.trust/ NCC Group].<br />
<br />
The team found the following problems:<br />
<br />
* 1 High<br />
* 5 Medium<br />
* 9 Low<br />
* 5 Informational<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Cakephp-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1oJg5XqEZasm6RE-Ql7D7OUSiUhXFKApCPMwZxFaq0W8/edit# Fix and validation log]<br />
<br />
===chrony===<br />
<br />
Dates: June - September 2017<br />
<br />
[http://chrony.tuxfamily.org/ chrony] is an implementation of the Network Time Protocol, used either to set the time on a particular machine or act as an NTP server for other machines on the network. The audit was performed by [https://cure53.de/ Cure53], and kindly funded by [https://www.coreinfrastructure.org/ CII].<br />
<br />
The team found the following problems:<br />
<br />
* 2 Low<br />
<br />
Cure53 write: The overwhelmingly positive result of this security assignment performed by three Cure53 testers can be clearly inferred from a marginal number and low-risk nature of the findings amassed in this report. Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind. The software boasts sound design and is secure across all tested areas. It is quite safe to assume that untested software in the Chrony family is of a similarly exceptional quality. In general, the software proved to be well-structured and marked by the right abstractions at the appropriate locations. While the functional scope of the software is quite wide, the actual implementation is surprisingly elegant and of a minimal and just necessary complexity. In sum, the Chrony NTP software stands solid and can be seen as trustworthy.<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Chrony-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1HpGgX4r-81BWfPmas7L2WGfByJrVEIc4hAOXLEaaV_4/edit# Fix and validation log]<br />
<br />
===expat===<br />
<br />
Dates: February - July 2017<br />
<br />
[https://libexpat.github.io/ expat] is a stream-oriented XML parser library written in C. The audit was performed by [https://radicallyopensecurity.com/ Radically Open Security]. <br />
<br />
The team found the following problems:<br />
<br />
* 4 Medium<br />
* 3 Low<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Libexpat-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1DECt3DQYT_12oJwSFLCf-szGmM-l5JtZK7jwCujskqQ/edit# Fix and validation log]<br />
<br />
===GNU libmicrohttpd===<br />
<br />
Dates: January - May 2017<br />
<br />
[https://www.gnu.org/software/libmicrohttpd/ GNU libmicrohttpd] is a small embeddable HTTP 1.1 server written in C which supports TLS and IPv6. The audit was performed by [https://leastauthority.com/ Least Authority]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 2 Low<br />
* 1 Informational<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Libmicrohttpd.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1Pq5GQMZreKOPxcvtUwJI3jts2YjtVgCHM6MB4d_eBcg/edit# Fix and validation log]<br />
<br />
===oauth2-server===<br />
<br />
Dates: December 2016 - January 2017<br />
<br />
[https://github.com/thephpleague/oauth2-server oauth2-server] is a standards compliant implementation of an OAuth 2.0 authorization server written in PHP. The audit was performed by independent auditor Brian Carpenter. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Low<br />
<br />
There is no fix and validation log; the subsystem in which the issue was found is [https://github.com/thephpleague/oauth2-server/issues/684#issuecomment-261058564 being removed].<br />
<br />
* [[Media:Oauth2-server-report.pdf|Audit report]]<br />
<br />
===dovecot===<br />
<br />
Dates: October 2016 - January 2017<br />
<br />
[http://www.dovecot.org/ dovecot] is a POP and IMAP mailserver; it is used in 68% of IMAP server deployments worldwide. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 Low<br />
<br />
The Cure53 team were extremely impressed with the quality of the dovecot code. They wrote: "Despite much effort and thoroughly all-encompassing approach, the Cure53 testers only managed to assert the excellent security-standing of Dovecot. More specifically, only three minor security issues have been found in the codebase, thus translating to an exceptionally good outcome for Dovecot, and a true testament to the fact that keeping security promises is at the core of the Dovecot development and operations."<br />
<br />
* [[Media:Dovecot-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1rhzV_2Mw-7qbhXkGfyREzhxi51Rqwt2br8dZBNvI64U/edit# Fix and validation log]<br />
* [http://www.dovecot.fi/impressive-results-from-mozilla-sponsored-dovecot-security-audit/index.html Developer blog post]<br />
<br />
===ntp===<br />
<br />
Dates: December 2016 - March 2017<br />
<br />
[http://www.ntp.org/ ntp] is a implementation of the Network Time Protocol. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Critical<br />
* 2 High<br />
* 1 Medium<br />
* 8 Low<br />
* 2 Informational<br />
<br />
This audit was performed at the same time as an audit of ntpsec, which is based on a version of the ntp code.<br />
<br />
* [[Media:Ntp-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1nyD8j_Q-rhksUgJvIVog7xlID-ktyiuuve-VFVqWXOI/edit# Fix and validation log]<br />
* [http://support.ntp.org/bin/view/Main/SecurityNotice#March_2017_ntp_4_2_8p10_NTP_Secu Developer security announcement]<br />
<br />
===ntpsec===<br />
<br />
Dates: December 2016 - March 2017<br />
<br />
[http://www.ntpsec.org/ ntpsec] is a implementation of the Network Time Protocol, a fork of ntp. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 High<br />
* 1 Medium<br />
* 3 Low<br />
* 1 Informational<br />
<br />
This audit was performed at the same time as an audit of ntp, of which this codebase is a fork.<br />
<br />
* [[Media:Ntpsec-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1_Kps7NGnXUUuiJ8Q7dInryzuPz8qmrgNetAtxmJjOmU/edit# Fix and validation log]<br />
* [https://blog.ntpsec.org/2017/03/21/version-0-9-7.html Developer blog post]<br />
<br />
==2016==<br />
<br />
===PCRE===<br />
<br />
Dates: October 2015 - June 2016<br />
<br />
[http://www.pcre.org/ PCRE] (Perl-Compatible Regular Expressions) is a C library for implementing [https://en.wikipedia.org/wiki/Regular_expression regular expressions] in a codebase. It is used in various open source projects including Exim, Apache, PHP and KDE, as well as Apple Safari. We audited PCRE2, a newer version which is currently less commonly-used but which is expected to become increasingly common. The audit was performed by [https://cure53.de/ Cure53].<br />
<br />
The team found the following problems:<br />
<br />
* 1 Critical<br />
* 5 Medium<br />
* 20 Low<br />
* 3 Informational<br />
<br />
The critical vulnerability was a stack buffer overflow which could have led to arbitrary code execution when compiling untrusted regular expressions.<br />
<br />
* [[Media:Pcre-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1FEGCOGPWt9lVsuFsER9EmkkTU-LIH9ggtWSDhgvwr0Q/edit Fix and validation log]<br />
<br />
===libjpeg-turbo===<br />
<br />
Dates: November 2015 - June 2016<br />
<br />
[http://www.libjpeg-turbo.org/ libjpeg-turbo] is a fork of the libjpeg codebase which is particularly focussed on speed, and on compatibility with the most commonly-used standard profiles of JPEG. It is used by a number of open source projects, including Chrome, LibreOffice, Firefox and various flavours of VNC. The audit was performed by [https://cure53.de/ Cure53].<br />
<br />
The team found the following problems:<br />
<br />
* 1 High<br />
* 2 Medium<br />
* 2 Low<br />
<br />
The high vulnerability was an out-of-bounds read. It is unclear exactly how exploitable it was. However, more interesting were the two medium vulnerabilities, which were initially reported as DoS bugs in the libjpeg-turbo library but on further investigation were found to be issues with the JPEG standard itself. These issues were reproduced across multiple JPEG implementations, can be triggered by entirely legal JPEGs, and so are not easy to mitigate in any JPEG library itself. We have written up these issues in a separate report, along with our suggestions as to how applications using JPEG can mitigate them in their own code.<br />
<br />
* [[Media:Libjpeg-turbo-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1uxETuTL7_tVgE8EB49RhxxHuCyDIbcsS9fHNimBixm4/edit Fix and validation log]<br />
* [https://docs.google.com/document/d/17exDyGr2txYJ5Ntv4Q8B3MnLSvbcSfs5dje_xuDZPNA/edit Special report on issues in the JPEG standard]<br />
<br />
===phpMyAdmin===<br />
<br />
Dates: May - June 2016<br />
<br />
[https://www.phpmyadmin.net/ phpMyAdmin] is a web-based administration tool for MySQL databases. The audit was performed by [https://www.nccgroup.trust/ NCC Group]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 Medium<br />
* 5 Low<br />
* 1 Informational<br />
<br />
NCC Group found no serious issues in this codebase.<br />
<br />
* [[Media:Phpmyadmin-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1mrKwVKkcC22JeYIcXQeTNbq_kjTLlMIfHAxdffFMDXk/edit Fix and validation log]<br />
* [https://www.phpmyadmin.net/news/2016/6/13/phpmyadmin-project-successfully-completes-security-audit/ Developer blog post]<br />
<br />
===dnsmasq===<br />
<br />
Dates: May - August 2016<br />
<br />
[http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] is a lightweight implementation of DNS, DHCP, router advertisement and network boot. It is used in resource-constrained environments such as routers and firewalls (e.g. openWRT and DD-WRT), Android, and OpenStack. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 5 Low<br />
<br />
* [[Media:Dnsmasq-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/14y2kiXgB69fLBY0xuMeqc-YiZg4UDCw2xd4-mZspoP8/edit Fix and validation log]<br />
<br />
===zlib===<br />
<br />
Dates: July - September 2016<br />
<br />
[http://www.zlib.net/ zlib] is a compression library implementing the 'deflate' compression algorithm, used in countless applications. The audit was performed by [https://www.trailofbits.com/ Trail of Bits]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 4 Low<br />
<br />
* [[Media:Zlib-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit Fix and validation log]<br />
<br />
One of the Low severity issues is still under discussion between the zlib development team and the auditors, as they are working out how to resolve it without performance degradation.<br />
<br />
===curl===<br />
<br />
Dates: August - November 2016<br />
<br />
[https://curl.haxx.se/ curl] is a command-line application for transferring data, most usually over HTTP or HTTPS. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 4 High<br />
* 5 Medium<br />
* 9 Low<br />
* 5 Informational<br />
<br />
8 of the vulnerabilities resulted in [https://curl.haxx.se/docs/security.html security advisories] being produced by the curl team on November 2nd, 2016.<br />
<br />
* [[Media:Curl-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/17EvPM_LHJiOQPGC8cZ7nd2_7Hs7PIhrQqa7s9-pylm0/edit Fix and validation log]<br />
* [https://daniel.haxx.se/blog/2016/11/23/curl-security-audit/ Developer blog post]</div>Gervhttps://wiki.mozilla.org/index.php?title=File:Knot-dns-report.pdf&diff=1188435File:Knot-dns-report.pdf2018-02-02T17:31:39Z<p>Gerv: </p>
<hr />
<div></div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Additional_Trust_Changes&diff=1188338CA/Additional Trust Changes2018-02-01T12:55:11Z<p>Gerv: Remove CNNIC - now gone from NSS</p>
<hr />
<div>The Mozilla Root Program's official repository of the roots it trusts is [https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt certdata.txt]. Some information about the level of trust in each root is included in that file - for example, whether it's trusted for server SSL, S/MIME or both. However, not all restrictions recommended by Mozilla on the roots can be or are encoded in certdata.txt. Some are implemented in our security library, "NSS", or in Firefox and Thunderbird (so-called "PSM").<br />
<br />
Sometimes, other companies and organizations decide to use Mozilla's root store in their products. As the [[CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F|CA FAQ]] notes, Mozilla does not promise to take into account the needs of other users of its root store when making decisions. However, for the benefit of such users and on a best-efforts basis, this page documents the additional trust settings that Mozilla recommends.<br />
<br />
==Extended Validation (EV)==<br />
<br />
The status of whether a root is approved to issue EV certificates or not is [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp stored in PSM] rather than certdata.txt.<br />
<br />
==OneCRL==<br />
<br />
While not technically a modification to the root store as we don't use it for un-trusting roots, Mozilla's [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL] system is used for communicating information about the revocation of intermediate certificates (and high-profile misissued end-entity certificates) to Firefox clients.<br />
<br />
==ANSSI==<br />
<br />
The French Government CA is name-constrained to those ccTLDs whose geographies are under the jurisdiction of France - that is, .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, and .tf. The code for that [https://hg.mozilla.org/projects/nss/annotate/1feb89a254de/lib/certdb/genname.c#l1595 is in NSS].<br />
<br />
==Kamu SM==<br />
<br />
The Turkish Government CA is name-constrained to a set of turkish toplevel domains - that is, .gov.tr, .k12.tr, .pol.tr, .mil.tr, .tsk.tr, .kep.tr, .bel.tr, .edu.tr and .org.tr. The code for that [https://hg.mozilla.org/projects/nss/annotate/1feb89a254de/lib/certdb/genname.c#l1622 is in NSS].<br />
<br />
==Symantec==<br />
<br />
Symantec certificate issued before 1 June 2016 are distrusted starting in Firefox 60 unless they are issued by certain whitelisted intermediate CAs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1409257 Bug 1409257]). This is in accordance [https://groups.google.com/d/topic/mozilla.dev.security.policy/FLHRT79e3XE/discussion with the distrust plan of 2017].</div>Gervhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates&diff=1187827WeeklyUpdates2018-01-29T18:43:06Z<p>Gerv: 29th</p>
<hr />
<div>:''These updates concern Mozilla as a whole. For the weekly Firefox meetings, see [[Firefox/DeliveryMeetings]], for Gecko progress, see [[Platform#Meeting_Notes]].''<br />
<br />
==Meeting Details==<br />
*Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
*Mozilla HQ, Ten Forward commons area <br />
{{conf|8600}}<br />
*http://air.mozilla.org/ to watch and listen <br />
*join irc.mozilla.org #airmozilla for backchannel discussion<br />
*'''Presenters only''': Vidyo room "Brownbags". Do ''not'' use this room if you're not planning to speak.<br />
<br />
'''Agenda:''' [[WeeklyUpdates/{{#time: Y-m-d | monday}}|Next Week's Agenda]]<br />
<br />
When you call in, you'll be muted by default, to keep phone noise down. Use "*1" (including the star) to unmute yourself if you want to say something. <br />
<br />
Full notes below. <!-- See https://wiki.mozilla.org/WeeklyUpdates/Template for create new page --><br />
<br />
==Meeting Notes==<br />
[[Template:WeeklyUpdates]] - <nowiki>{{subst:WeeklyUpdates}}</nowiki><br />
<!--*[[WeeklyUpdates/Template]]--><br />
<br />
Create a new weekly agenda from the [[Template:WeeklyUpdates|template]]:<br />
<createbox><br />
align=left<br />
type=create<br />
preload=Template:WeeklyUpdates<br />
default={{#time: Y-m-d | monday}}<br />
prefix=WeeklyUpdates/<br />
</createbox><br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2018<br />
|-<br />
|<br />
* [[WeeklyUpdates/2018-01-29|January 29th, 2018]]<br />
* [[WeeklyUpdates/2018-01-22|January 22nd, 2018]]<br />
* January 15th, 2018 (No meeting due to Martin Luther King Jr. Day in the US)<br />
* [[WeeklyUpdates/2018-01-08|Janurary 8th, 2018]]<br />
|}<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! 2017<br />
|-<br />
|<br />
* [[WeeklyUpdates/2017-12-04|December 4th, 2017]]<br />
* [[WeeklyUpdates/2017-11-27|November 27th, 2017]]<br />
* [[WeeklyUpdates/2017-11-20|November 20th, 2017]]<br />
* [[WeeklyUpdates/2017-11-13|November 13th, 2017]]<br />
* [[WeeklyUpdates/2017-11-06|November 6th, 2017]]<br />
* [[WeeklyUpdates/2017-10-30|October 30th, 2017]]<br />
* [[WeeklyUpdates/2017-10-23|October 23th, 2017]]<br />
* [[WeeklyUpdates/2017-10-16|October 16th, 2017]]<br />
* [[WeeklyUpdates/2017-10-09|October 9th, 2017]]<br />
* [[WeeklyUpdates/2017-10-02|October 2nd, 2017]]<br />
* [[WeeklyUpdates/2017-09-25|September 25th, 2017]]<br />
* [[WeeklyUpdates/2017-09-18|September 18th, 2017]]<br />
* [[WeeklyUpdates/2017-09-11|September 11th, 2017]]<br />
* [[WeeklyUpdates/2017-08-28|August 28th, 2017]]<br />
* [[WeeklyUpdates/2017-08-21|August 21th, 2017]]<br />
* [[WeeklyUpdates/2017-08-14|August 14th, 2017]]<br />
* [[WeeklyUpdates/2017-08-07|August 7th, 2017]]<br />
* [[WeeklyUpdates/2017-07-31|July 31st, 2017]]<br />
* [[WeeklyUpdates/2017-07-24|July 24th, 2017]]<br />
* [[WeeklyUpdates/2017-07-17|July 17th, 2017]]<br />
* [[WeeklyUpdates/2017-07-10|July 10th, 2017]]<br />
* July 3rd, 2017 (No meeting due to All-Hands SF Recovery)<br />
* June 26th, 2017 (No meeting due to All-Hands SF)<br />
* [[WeeklyUpdates/2017-06-19|June 19th, 2017]]<br />
* [[WeeklyUpdates/2017-06-12|June 12th, 2017]]<br />
* [[WeeklyUpdates/2017-06-05|June 5th, 2017]]<br />
* May 29th, 2017 (No meeting due to US holiday for Memorial Day)<br />
* [[WeeklyUpdates/2017-05-22|May 22nd, 2017]]<br />
* [[WeeklyUpdates/2017-05-15|May 15th, 2017]]<br />
* [[WeeklyUpdates/2017-05-08|May 8th, 2017]]<br />
* [[WeeklyUpdates/2017-05-01|May 1st, 2017]]<br />
* [[WeeklyUpdates/2017-04-24|April 24th, 2017]]<br />
* [[WeeklyUpdates/2017-04-17|April 17th, 2017]]<br />
* [[WeeklyUpdates/2017-04-10|April 10th, 2017]]<br />
* [[WeeklyUpdates/2017-04-03|April 3rd, 2017]]<br />
* [[WeeklyUpdates/2017-03-27|March 27th, 2017]]<br />
* [[WeeklyUpdates/2017-03-20|March 20th, 2017]]<br />
* [[WeeklyUpdates/2017-03-13|March 13th, 2017]]<br />
* [[WeeklyUpdates/2017-03-06|March 6th, 2017]]<br />
* [[WeeklyUpdates/2017-02-27|February 27th, 2017]]<br />
* [[WeeklyUpdates/2017-02-13|February 13th, 2017]]<br />
* [[WeeklyUpdates/2017-02-06|February 6th, 2017]]<br />
* [[WeeklyUpdates/2017-01-30|January 30th, 2017]]<br />
* [[WeeklyUpdates/2017-01-23|January 23rd, 2017]]<br />
* January 16th, 2017 (no meeting due to US holiday)<br />
* [[WeeklyUpdates/2017-01-09|January 9th, 2017]]<br />
* January 2nd, 2017 (no meeting due to US New Year's Day holiday)<br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2016 <br />
|-<br />
|<br />
* [[WeeklyUpdates/2016-12-26|December 26th, 2016]] (silent updates only. no meeting due to US Holiday observed)<br />
* [[WeeklyUpdates/2016-12-19|December 19th, 2016]]<br />
* [[WeeklyUpdates/2016-12-12|December 12th, 2016]]<br />
* December 5th, 2016 (no meeting due to All-Hands travel)<br />
* [[WeeklyUpdates/2016-11-28|November 28th, 2016]]<br />
* [[WeeklyUpdates/2016-11-21|November 21st, 2016]]<br />
* [[WeeklyUpdates/2016-11-21|November 21th, 2016]]<br />
* [[WeeklyUpdates/2016-11-14|November 14th, 2016]]<br />
* [[WeeklyUpdates/2016-11-07|November 7th, 2016]]<br />
* [[WeeklyUpdates/2016-10-31|October 31st, 2016]]<br />
* [[WeeklyUpdates/2016-10-24|October 24th, 2016]]<br />
* [[WeeklyUpdates/2016-10-17|October 17th, 2016]]<br />
* [[WeeklyUpdates/2016-10-10|October 10th, 2016]]<br />
* [[WeeklyUpdates/2016-09-26|September 26th, 2016]]<br />
* [[WeeklyUpdates/2016-09-19|September 19th, 2016]]<br />
* [[WeeklyUpdates/2016-09-12|September 12th, 2016]]<br />
* There was no meeting on September 5 because of the US Labor Day holiday.<br />
* [[WeeklyUpdates/2016-08-29|August 29nd, 2016]]<br />
* [[WeeklyUpdates/2016-08-22|August 22nd, 2016]]<br />
* [[WeeklyUpdates/2016-08-15|August 15th, 2016]]<br />
* [[WeeklyUpdates/2016-08-08|August 8th, 2016]]<br />
* [[WeeklyUpdates/2016-08-01|August 1st, 2016]]<br />
* [[WeeklyUpdates/2016-07-25|July 25th, 2016]]<br />
* [[WeeklyUpdates/2016-07-18|July 18th, 2016]]<br />
* [[WeeklyUpdates/2016-07-11|July 11th, 2016]]<br />
* [[WeeklyUpdates/2016-06-27|June 27th, 2016]]<br />
* [[WeeklyUpdates/2016-06-20|June 20th, 2016]]<br />
* [[WeeklyUpdates/2016-06-06|June 6th, 2016]]<br />
* [[WeeklyUpdates/2016-05-23|May 23rd, 2016]]<br />
* [[WeeklyUpdates/2016-05-16|May 16th, 2016]]<br />
* [[WeeklyUpdates/2016-05-09|May 9th, 2016]]<br />
* [[WeeklyUpdates/2016-05-02|May 2nd, 2016]]<br />
* [[WeeklyUpdates/2016-04-25|April 25th, 2016]]<br />
* [[WeeklyUpdates/2016-04-18|April 18th, 2016]]<br />
* [[WeeklyUpdates/2016-04-11|April 11th, 2016]]<br />
* [[WeeklyUpdates/2016-04-04|April 4th, 2016]]<br />
* [[WeeklyUpdates/2016-03-28|March 28th, 2016]]<br />
* [[WeeklyUpdates/2016-03-21|March 21st, 2016]]<br />
* [[WeeklyUpdates/2016-03-14|March 14th, 2016]]<br />
* [[WeeklyUpdates/2016-03-07|March 7th, 2016]]<br />
* [[WeeklyUpdates/2016-02-29|February 29th, 2016]]<br />
* [[WeeklyUpdates/2016-02-22|February 22nd, 2016]]<br />
* [[WeeklyUpdates/2016-02-15|February 15th, 2016]] (no live meeting due to [https://en.wikipedia.org/wiki/Washington's_Birthday Washington's Birthday] Holiday in the US.)<br />
* [[WeeklyUpdates/2016-02-08|February 8th, 2016]]<br />
* [[WeeklyUpdates/2016-02-01|February 1st, 2016]]<br />
* [[WeeklyUpdates/2016-01-25|January 25th, 2016]]<br />
* [[WeeklyUpdates/2016-01-11|January 11th, 2016]]<br />
* [[WeeklyUpdates/2016-01-04|January 4th, 2016]]<br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2015 <br />
|-<br />
|<br />
* [[WeeklyUpdates/2015-12-28|December 28th, 2015]] (no meeting, just announcements)<br />
* December 21st (no meeting)<br />
* [[WeeklyUpdates/2015-12-14|December 14th, 2015]] (no live meeting due to All Hands recovery)<br />
* December 7th (no meeting due to All Hands)<br />
* [[WeeklyUpdates/2015-11-30|November 30th, 2015]]<br />
* [[WeeklyUpdates/2015-11-23|November 23rd, 2015]]<br />
* [[WeeklyUpdates/2015-11-16|November 16th, 2015]]<br />
* [[WeeklyUpdates/2015-11-09|November 9th, 2015]]<br />
* [[WeeklyUpdates/2015-11-02|November 2nd, 2015]]<br />
* [[WeeklyUpdates/2015-10-26|October 26th, 2015]]<br />
* [[WeeklyUpdates/2015-10-19|October 19th, 2015]]<br />
* [[WeeklyUpdates/2015-10-12|October 12th, 2015]]<br />
* [[WeeklyUpdates/2015-10-05|October 5th, 2015]]<br />
* [[WeeklyUpdates/2015-09-28|September 28th, 2015]]<br />
* [[WeeklyUpdates/2015-09-21|September 21st, 2015]]<br />
* [[WeeklyUpdates/2015-09-14|September 14th, 2015]]<br />
* September 7th (No meeting due to Labor Day)<br />
* [[WeeklyUpdates/2015-08-31|August 31st, 2015]]<br />
* [[WeeklyUpdates/2015-08-24|August 24th, 2015]]<br />
* [[WeeklyUpdates/2015-08-17|August 17th, 2015]]<br />
* [[WeeklyUpdates/2015-08-10|August 10th, 2015]]<br />
* [[WeeklyUpdates/2015-08-03|August 3rd, 2015]]<br />
* [[WeeklyUpdates/2015-07-27|July 27th, 2015]]<br />
* [[WeeklyUpdates/2015-07-20|July 20th, 2015]]<br />
* [[WeeklyUpdates/2015-07-13|July 13th, 2015]]<br />
* [[WeeklyUpdates/2015-07-06|July 6th, 2015]]<br />
* [[WeeklyUpdates/2015-06-29|June 29th, 2015]]<br />
* June 22nd, 2015 (no meeting due to All-Hands travel)<br />
* [[WeeklyUpdates/2015-06-15|June 15th, 2015]]<br />
* [[WeeklyUpdates/2015-06-08|June 8th, 2015]]<br />
* [[WeeklyUpdates/2015-06-01|June 1st, 2015]]<br />
* May 25th, 2015 (no meeting due to US Holiday)<br />
* [[WeeklyUpdates/2015-05-18|May 18th, 2015]]<br />
* [[WeeklyUpdates/2015-05-11|May 11th, 2015]]<br />
* [[WeeklyUpdates/2015-05-04|May 4th, 2015]]<br />
* [[WeeklyUpdates/2015-04-27|April 27th, 2015]]<br />
* [[WeeklyUpdates/2015-04-20|April 20th, 2015]]<br />
* [[WeeklyUpdates/2015-04-13|April 13th, 2015]]<br />
* [[WeeklyUpdates/2015-04-06|April 6th, 2015]]<br />
* [[WeeklyUpdates/2015-03-30|March 30th, 2015]]<br />
* [[WeeklyUpdates/2015-03-23|March 23rd, 2015]]<br />
* [[WeeklyUpdates/2015-03-16|March 16th, 2015]]<br />
* [[WeeklyUpdates/2015-03-09|March 9th, 2015]]<br />
* [[WeeklyUpdates/2015-03-02|March 2nd, 2015]]<br />
* [[WeeklyUpdates/2015-02-23|February 23rd, 2015]]<br />
* Feb 16th No meeting due to US Holiday<br />
* [[WeeklyUpdates/2015-02-09|February 9nd, 2015]]<br />
* [[WeeklyUpdates/2015-02-02|February 2nd, 2015]]<br />
* [[WeeklyUpdates/2015-01-26|January 26th, 2015]]<br />
* [[WeeklyUpdates/2015-01-19|January 19th, 2015]]<br />
* [[WeeklyUpdates/2015-01-12|January 12th, 2015]]<br />
* [[WeeklyUpdates/2015-01-05|January 5th, 2015]]<br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2014<br />
|-<br />
|<br />
*[[WeeklyUpdates/2014-12-29|December 29th, 2014]]<br />
*[[WeeklyUpdates/2014-12-15|December 15th, 2014]]<br />
*[[WeeklyUpdates/2014-12-08|December 8th, 2014]]<br />
*[[WeeklyUpdates/2014-11-24|November 24th, 2014]]<br />
*[[WeeklyUpdates/2014-11-17|November 17th, 2014]]<br />
*[[WeeklyUpdates/2014-11-10|November 10th, 2014]]<br />
*[[WeeklyUpdates/2014-11-03|November 3rd, 2014]]<br />
*[[WeeklyUpdates/2014-10-27|October 27th, 2014]]<br />
*[[WeeklyUpdates/2014-10-20|October 20th, 2014]]<br />
*[[WeeklyUpdates/2014-10-13|October 13th, 2014]]<br />
*[[WeeklyUpdates/2014-10-06|October 6th, 2014]]<br />
*[[WeeklyUpdates/2014-09-29|September 29th, 2014]]<br />
*[[WeeklyUpdates/2014-09-22|September 22th, 2014]]<br />
*[[WeeklyUpdates/2014-09-15|September 15th, 2014]]<br />
*[[WeeklyUpdates/2014-09-08|September 8th, 2014]]<br />
*[[WeeklyUpdates/2014-09-01|September 1st, 2014]]<br />
*[[WeeklyUpdates/2014-08-25|August 25, 2014]]<br />
*[[WeeklyUpdates/2014-08-18|August 18, 2014]]<br />
*[[WeeklyUpdates/2014-08-11|August 11, 2014]]<br />
*[[WeeklyUpdates/2014-08-04|August 4, 2014]]<br />
*[[WeeklyUpdates/2014-07-28|July 28, 2014]]<br />
*[[WeeklyUpdates/2014-07-21|July 21, 2014]]<br />
*[[WeeklyUpdates/2014-07-14|July 14, 2014]]<br />
*[[WeeklyUpdates/2014-07-07|July 7, 2014]]<br />
*[[WeeklyUpdates/2014-06-30|June 30, 2014]]<br />
*[[WeeklyUpdates/2014-06-23|June 23, 2014]]<br />
*[[WeeklyUpdates/2014-06-16|June 16, 2014]]<br />
*[[WeeklyUpdates/2014-06-09|June 09, 2014]]<br />
*[[WeeklyUpdates/2014-06-02|June 02, 2014]]<br />
*[[WeeklyUpdates/2014-05-26|May 26, 2014]]<br />
*[[WeeklyUpdates/2014-05-19|May 19, 2014]]<br />
*[[WeeklyUpdates/2014-05-12|May 12, 2014]]<br />
*[[WeeklyUpdates/2014-05-05|May 05, 2014]]<br />
*[[WeeklyUpdates/2014-04-28|April 28, 2014]]<br />
*[[WeeklyUpdates/2014-04-21|April 21, 2014]]<br />
*[[WeeklyUpdates/2014-04-14|April 14, 2014]]<br />
*[[WeeklyUpdates/2014-04-07|April 7, 2014]]<br />
*[[WeeklyUpdates/2014-03-31|March 31, 2014]]<br />
*[[WeeklyUpdates/2014-03-24|March 24, 2014]]<br />
*[[WeeklyUpdates/2014-03-17|March 17, 2014]]<br />
*[[WeeklyUpdates/2014-03-10|March 10, 2014]]<br />
*[[WeeklyUpdates/2014-03-03|March 3, 2014]]<br />
*[[WeeklyUpdates/2014-02-24|February 24, 2014]]<br />
*[[WeeklyUpdates/2014-02-10|February 10, 2014]]<br />
*[[WeeklyUpdates/2014-02-03|February 3, 2014]]<br />
*[[WeeklyUpdates/2014-01-27|January 27, 2014]]<br />
*[[WeeklyUpdates/2014-01-20|January 20, 2014]]<br />
*[[WeeklyUpdates/2014-01-13|January 13, 2014]]<br />
*[[WeeklyUpdates/2014-01-06|January 6, 2014]]<br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2013 <br />
|-<br />
|<br />
*[[WeeklyUpdates/2013-12-16|December 16, 2013]]<br />
*[[WeeklyUpdates/2013-12-09|December 9, 2013]]<br />
*[[WeeklyUpdates/2013-12-02|December 2, 2013]]<br />
*[[WeeklyUpdates/2013-11-25|November 25, 2013]]<br />
*[[WeeklyUpdates/2013-11-18|November 18, 2013]]<br />
*[[WeeklyUpdates/2013-11-11|November 11, 2013]]<br />
*[[WeeklyUpdates/2013-11-04|November 4, 2013]]<br />
*[[WeeklyUpdates/2013-10-28|October 28, 2013]]<br />
*[[WeeklyUpdates/2013-10-21|October 21, 2013]]<br />
*[[WeeklyUpdates/2013-10-14|October 14, 2013]]<br />
*[[WeeklyUpdates/2013-10-07|October 7, 2013]]<br />
*[[WeeklyUpdates/2013-09-30|September 30, 2013]]<br />
*[[WeeklyUpdates/2013-09-23|September 23, 2013]]<br />
*[[WeeklyUpdates/2013-09-16|September 16, 2013]]<br />
*[[WeeklyUpdates/2013-09-09|September 9, 2013]]<br />
*[[WeeklyUpdates/2013-09-02|September 2, 2013]]<br />
*[[WeeklyUpdates/2013-08-26|August 26, 2013]]<br />
*[[WeeklyUpdates/2013-08-19|August 19, 2013]]<br />
*[[WeeklyUpdates/2013-08-12|August 12, 2013]]<br />
*[[WeeklyUpdates/2013-08-05|August 5, 2013]]<br />
*[[WeeklyUpdates/2013-07-29|July 29, 2013]]<br />
*[[WeeklyUpdates/2013-07-22|July 22, 2013]]<br />
*[[WeeklyUpdates/2013-07-15|July 15, 2013]]<br />
*[[WeeklyUpdates/2013-07-08|July 8, 2013]]<br />
*[[WeeklyUpdates/2013-07-01|July 1, 2013]]<br />
*[[WeeklyUpdates/2013-06-24|June 24, 2013]]<br />
*[[WeeklyUpdates/2013-06-17|June 17, 2013]]<br />
*[[WeeklyUpdates/2013-06-10|June 10, 2013]]<br />
*[[WeeklyUpdates/2013-06-03|June 3, 2013]]<br />
*[[WeeklyUpdates/2013-05-20|May 20, 2013]]<br />
*[[WeeklyUpdates/2013-05-13|May 13, 2013]]<br />
*[[WeeklyUpdates/2013-05-06|May 6, 2013]]<br />
*[[WeeklyUpdates/2013-04-29|April 29, 2013]]<br />
*[[WeeklyUpdates/2013-04-22|April 22, 2013]]<br />
*[[WeeklyUpdates/2013-04-15|April 15, 2013]]<br />
*[[WeeklyUpdates/2013-04-08|April 8, 2013]]<br />
*[[WeeklyUpdates/2013-04-01|April 1, 2013]]<br />
*[[WeeklyUpdates/2013-03-25|March 25, 2013]]<br />
*[[WeeklyUpdates/2013-03-18|March 18, 2013]]<br />
*[[WeeklyUpdates/2013-03-11|March 11, 2013]]<br />
*[[WeeklyUpdates/2013-03-04|March 4, 2013]]<br />
*[[WeeklyUpdates/2013-02-25|February 25, 2013]]<br />
*February 18, 2013 - ''No meeting.'' <br />
*[[WeeklyUpdates/2013-02-11|February 11, 2013]]<br />
*[[WeeklyUpdates/2013-02-04|February 04, 2013]]<br />
*[[WeeklyUpdates/2013-01-28|January 28, 2013]]<br />
*[[WeeklyUpdates/2013-01-21|January 21, 2013]]<br />
*[[WeeklyUpdates/2013-01-14|January 14, 2013]]<br />
*[[WeeklyUpdates/2013-01-07|January 7, 2013]]<br />
|}<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2012 <br />
|-<br />
|<br />
*December 31, 2012 - ''No meeting.''<br />
*December 24, 2012 - ''No meeting.''<br />
*[[WeeklyUpdates/2012-12-17|December 17, 2012]]<br />
*[[WeeklyUpdates/2012-12-10|December 10, 2012]]<br />
*[[WeeklyUpdates/2012-12-03|December 03, 2012]]<br />
*[[WeeklyUpdates/2012-11-26|November 26, 2012]]<br />
*[[WeeklyUpdates/2012-11-19|November 19, 2012]]<br />
*[[WeeklyUpdates/2012-11-12|November 12, 2012]]<br />
*[[WeeklyUpdates/2012-11-05|November 5, 2012]]<br />
*[[WeeklyUpdates/2012-10-29|October 29, 2012]]<br />
*[[WeeklyUpdates/2012-10-22|October 22, 2012]]<br />
*[[WeeklyUpdates/2012-10-15|October 15, 2012]]<br />
*[[WeeklyUpdates/2012-10-08|October 8, 2012]]<br />
*[[WeeklyUpdates/2012-10-01|October 1, 2012]]<br />
*[[WeeklyUpdates/2012-09-24|September 24, 2012]]<br />
*[[WeeklyUpdates/2012-09-17|September 17, 2012]]<br />
*[[WeeklyUpdates/2012-09-10|September 10, 2012]]<br />
*[[WeeklyUpdates/2012-08-27|August 27, 2012]]<br />
*[[WeeklyUpdates/2012-08-20|August 20, 2012]]<br />
*[[WeeklyUpdates/2012-08-13|August 13, 2012]]<br />
*[[WeeklyUpdates/2012-08-06|August 06, 2012]]<br />
*[[WeeklyUpdates/2012-07-30|July 30, 2012]]<br />
*[[WeeklyUpdates/2012-07-23|July 23, 2012]]<br />
*[[WeeklyUpdates/2012-07-16|July 16, 2012]]<br />
*[[WeeklyUpdates/2012-07-09|July 9, 2012]]<br />
*[[WeeklyUpdates/2012-07-02|July 2, 2012]]<br />
*[[WeeklyUpdates/2012-06-25|June 25, 2012]]<br />
*[[WeeklyUpdates/2012-06-18|June 18, 2012]]<br />
*[[WeeklyUpdates/2012-06-11|June 11, 2012]]<br />
*[[WeeklyUpdates/2012-06-04|June 4, 2012]]<br />
*[[WeeklyUpdates/2012-05-28|May 28, 2012]]<br />
*[[WeeklyUpdates/2012-05-21|May 21, 2012]]<br />
*[[WeeklyUpdates/2012-05-14|May 14, 2012]]<br />
*[[WeeklyUpdates/2012-05-07|May 7, 2012]]<br />
*[[WeeklyUpdates/2012-04-30|April 30, 2012]]<br />
*[[WeeklyUpdates/2012-04-23|April 23, 2012]]<br />
*[[WeeklyUpdates/2012-04-16|April 16, 2012]]<br />
*[[WeeklyUpdates/2012-04-09|April 9, 2012]]<br />
*[[WeeklyUpdates/2012-04-02|April 2, 2012]]<br />
*[[WeeklyUpdates/2012-03-26|March 26, 2012]]<br />
*[[WeeklyUpdates/2012-03-19|March 19, 2012]]<br />
*[[WeeklyUpdates/2012-03-12|March 12, 2012]]<br />
*[[WeeklyUpdates/2012-03-05|March 5, 2012]]<br />
*[[WeeklyUpdates/2012-02-27|February 27, 2012]]<br />
*February 20, 2012 - ''No meeting.''<br />
*[[WeeklyUpdates/2012-02-13|February 13, 2012]]<br />
*[[WeeklyUpdates/2012-02-06|February 6, 2012]]<br />
*[[WeeklyUpdates/2012-01-30|January 30, 2012]]<br />
*[[WeeklyUpdates/2012-01-23|January 23, 2012]]<br />
*January 16, 2012 - ''No meeting.''<br />
*[[WeeklyUpdates/2012-01-09|January 9, 2012]]<br />
*January 2, 2012 - ''No meeting.''<br />
|}<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2011 <br />
|-<br />
|<br />
*December 26, 2011 - ''No meeting.''<br />
*[[WeeklyUpdates/2011-12-19|December 19, 2011]]<br />
*[[WeeklyUpdates/2011-12-12|December 12, 2011]]<br />
*[[WeeklyUpdates/2011-12-05|December 5, 2011]]<br />
*[[WeeklyUpdates/2011-11-28|November 28, 2011]]<br />
*[[WeeklyUpdates/2011-11-21|November 21, 2011]]<br />
*[[WeeklyUpdates/2011-11-14|November 14, 2011]]<br />
*[[WeeklyUpdates/2011-11-07|November 7, 2011]]<br />
*[[WeeklyUpdates/2011-10-31|October 31, 2011]]<br />
*[[WeeklyUpdates/2011-10-24|October 24, 2011]]<br />
*[[WeeklyUpdates/2011-10-17|October 17, 2011]]<br />
*[[WeeklyUpdates/2011-10-10|October 10, 2011]]<br />
*[[WeeklyUpdates/2011-10-03|October 3, 2011]]<br />
*[[WeeklyUpdates/2011-09-27|September 26, 2011]]<br />
*[[WeeklyUpdates/2011-09-19|September 19, 2011]]<br />
*September 12, 2011 - ''No meeting due to All-Hands week.''<br />
*September 5, 2011 - ''No meeting due to US holiday.''<br />
*[[WeeklyUpdates/2011-08-29|August 29, 2011]]<br />
*[[WeeklyUpdates/2011-08-22|August 22, 2011]]<br />
*[[WeeklyUpdates/2011-08-15|August 15, 2011]]<br />
*[[WeeklyUpdates/2011-08-08|August 8, 2011]]<br />
*[[WeeklyUpdates/2011-08-01|August 1, 2011]]<br />
*[[WeeklyUpdates/2011-07-25|July 25, 2011]]<br />
*[[WeeklyUpdates/2011-07-18|July 18, 2011]]<br />
*[[WeeklyUpdates/2011-07-11|July 11, 2011]]<br />
*July 4, 2011 - ''No meeting due to US holiday.''<br />
*[[WeeklyUpdates/2011-06-27|June 27, 2011]]<br />
*[[WeeklyUpdates/2011-06-20|June 20, 2011]]<br />
*[[WeeklyUpdates/2011-06-13|June 13, 2011]]<br />
*[[WeeklyUpdates/2011-06-06|June 6, 2011]]<br />
*May 30, 2011 - ''No meeting due to US holiday.''<br />
*[[WeeklyUpdates/2011-05-23|May 23, 2011]]<br />
*[[WeeklyUpdates/2011-05-16|May 16, 2011]]<br />
*[[WeeklyUpdates/2011-05-09|May 9, 2011]]<br />
*[[WeeklyUpdates/2011-05-02|May 2, 2011]]<br />
*[[WeeklyUpdates/2011-04-25|April 25, 2011]]<br />
*[[WeeklyUpdates/2011-04-18|April 18, 2011]]<br />
*[[WeeklyUpdates/2011-04-11|April 11, 2011]]<br />
*April 4, 2011 - ''No meeting due to All-Hands week.''<br />
*[[WeeklyUpdates/2011-03-28|March 28, 2011]]<br />
*[[WeeklyUpdates/2011-03-21|March 21, 2011]]<br />
*[[WeeklyUpdates/2011-03-14|March 14, 2011]]<br />
*[[WeeklyUpdates/2011-03-07|March 7, 2011]]<br />
*[[WeeklyUpdates/2011-02-28|February 28, 2011]]<br />
*February 21, 2011 - ''No meeting due to US holiday.''<br />
*[[WeeklyUpdates/2011-02-14|February 14, 2011]]<br />
*[[WeeklyUpdates/2011-02-07|February 07, 2011]]<br />
*[[WeeklyUpdates/2011-01-31|January 31, 2011]]<br />
*[[WeeklyUpdates/2011-01-24|January 24, 2011]]<br />
*January 17, 2011 - ''No meeting due to US holiday.''<br />
*[[WeeklyUpdates/2011-01-10|January 10, 2011]]<br />
*[[WeeklyUpdates/2011-01-03|January 3, 2011]]<br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2010 <br />
|-<br />
|<br />
*December 27, 2010 - ''No meeting due to holiday season.''<br />
*[[WeeklyUpdates/2010-12-20|December 20, 2010]]<br />
*December 13, 2010 - ''No meeting due to Work Week''<br />
*[[WeeklyUpdates/2010-12-06|December 6, 2010]]<br />
*[[WeeklyUpdates/2010-11-29|November 29, 2010]]<br />
*[[WeeklyUpdates/2010-11-22|November 22, 2010]]<br />
*[[WeeklyUpdates/2010-11-15|November 15, 2010]]<br />
*[[WeeklyUpdates/2010-11-08|November 08, 2010]]<br />
*[[WeeklyUpdates/2010-11-01|November 01, 2010]]<br />
*[[WeeklyUpdates/2010-10-25|October 25, 2010]]<br />
*[[WeeklyUpdates/2010-10-18|October 18, 2010]]<br />
*[[WeeklyUpdates/2010-10-11|October 11, 2010]]<br />
*[[WeeklyUpdates/2010-10-04|October 4, 2010]]<br />
*[[WeeklyUpdates/2010-09-27|September 27, 2010]]<br />
*[[WeeklyUpdates/2010-09-20|September 20, 2010]]<br />
*[[WeeklyUpdates/2010-09-13|September 13, 2010]]<br />
*September 6, 2010 - ''No meeting due to US holiday''<br />
*[[WeeklyUpdates/2010-08-30|August 30, 2010]]<br />
*[[WeeklyUpdates/2010-08-23|August 23, 2010]]<br />
*[[WeeklyUpdates/2010-08-16|August 16, 2010]]<br />
*[[WeeklyUpdates/2010-08-09|August 9, 2010]]<br />
*[[WeeklyUpdates/2010-08-02|August 2, 2010]]<br />
*[[WeeklyUpdates/2010-07-26|July 26, 2010]]<br />
*[[WeeklyUpdates/2010-07-19|July 19, 2010]]<br />
*[[WeeklyUpdates/2010-07-12|July 12, 2010]]<br />
*July 5, 2010 - ''No meeting due to summit''<br />
*[[WeeklyUpdates/2010-06-28|June 28, 2010]]<br />
*[[WeeklyUpdates/2010-06-21|June 21, 2010]]<br />
*[[WeeklyUpdates/2010-06-14|June 14, 2010]]<br />
*[[WeeklyUpdates/2010-06-07|June 7, 2010]]<br />
*May 31, 2010 - ''No meeting due to US holiday''<br />
*[[WeeklyUpdates/2010-05-24|May 24, 2010]]<br />
*[[WeeklyUpdates/2010-05-17|May 17, 2010]]<br />
*[[WeeklyUpdates/2010-05-10|May 10, 2010]]<br />
*[[WeeklyUpdates/2010-05-03|May 03, 2010]]<br />
*[[WeeklyUpdates/2010-04-26|April 26, 2010]]<br />
*[[WeeklyUpdates/2010-04-19|April 19, 2010]]<br />
*[[WeeklyUpdates/2010-04-12|April 12, 2010]]<br />
*[[WeeklyUpdates/2010-04-05|April 5, 2010]]<br />
*[[WeeklyUpdates/2010-03-29|March 29, 2010]]<br />
*[[WeeklyUpdates/2010-03-22|March 22, 2010]]<br />
*[[WeeklyUpdates/2010-03-15|March 15, 2010]]<br />
*[[WeeklyUpdates/2010-03-08|March 8, 2010]]<br />
*[[WeeklyUpdates/2010-03-01|March 1, 2010]]<br />
*[[WeeklyUpdates/2010-02-22|February 22, 2010]] <br />
*[[WeeklyUpdates/2010-02-15|February 15, 2010]]- No meeting due to holiday, please leave updates in the wiki.<br />
*[[WeeklyUpdates/2010-02-08|February 8, 2010]] <br />
*[[WeeklyUpdates/2010-02-01|February 1, 2010]]<br />
*[[WeeklyUpdates/2010-01-25|January 25, 2010]]<br />
*[[WeeklyUpdates/2010-01-18|January 18, 2010]]- No meeting due to US holiday, please leaves updates in the wiki.<br />
*[[WeeklyUpdates/2010-01-11|January 11, 2010]]- First meeting using [[WeeklyUpdates/Guidance|new procedures]].<br />
*[[WeeklyUpdates/2010-01-04|January 04, 2010]] <br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2009 <br />
|-<br />
|<br />
*[[WeeklyUpdates/2009-12-28|December 28, 2009]]- No meeting due to holiday. Feel free to leave updates in the Wiki. <br />
*[[WeeklyUpdates/2009-12-21|December 21, 2009]] <br />
*[[WeeklyUpdates/2009-12-14|December 14, 2009]] <br />
*[[WeeklyUpdates/2009-12-07|December 07, 2009]]- No meeting due to all day Mozilla Corp meetings. Feel free to leave updates in the Wiki. <br />
*[[WeeklyUpdates/2009-11-30|November 30, 2009]] <br />
*[[WeeklyUpdates/2009-11-23|November 23, 2009]] <br />
*[[WeeklyUpdates/2009-11-16|November 16, 2009]] <br />
*[[WeeklyUpdates/2009-11-09|November 09, 2009]] <br />
*[[WeeklyUpdates/2009-11-02|November 02, 2009]] - Time Change! 19:00 UTC (11am PST) <br />
*[[WeeklyUpdates/2009-10-26|October 26, 2009]] <br />
*[[WeeklyUpdates/2009-10-19|October 19, 2009]] <br />
*[[WeeklyUpdates/2009-10-12|October 12, 2009]] <br />
*[[WeeklyUpdates/2009-10-05|October 05, 2009]] <br />
*[[WeeklyUpdates/2009-09-28|September 28, 2009]] <br />
*[[WeeklyUpdates/2009-09-21|September 21, 2009]] <br />
*[[WeeklyUpdates/2009-09-14|September 14, 2009]] <br />
*[[WeeklyUpdates/2009-09-07|September 07, 2009]] - No Meeting due to [http://en.wikipedia.org/wiki/Labor_Day Labor Day] Holiday <br />
*[[WeeklyUpdates/2009-08-31|August 31, 2009]] <br />
*[[WeeklyUpdates/2009-08-24|August 24, 2009]] <br />
*[[WeeklyUpdates/2009-08-17|August 17, 2009]] <br />
*[[WeeklyUpdates/2009-08-10|August 10, 2009]] <br />
*[[WeeklyUpdates/2009-08-03|August 03, 2009]] <br />
*[[WeeklyUpdates/2009-07-27|July 27, 2009]] <br />
*[[WeeklyUpdates/2009-07-20|July 20, 2009]] <br />
*[[WeeklyUpdates/2009-07-13|July 13, 2009]] <br />
*[[WeeklyUpdates/2009-07-06|July 06, 2009]] <br />
*[[WeeklyUpdates/2009-06-29|June 29, 2009]] <br />
*[[WeeklyUpdates/2009-06-22|June 22, 2009]] <br />
*[[WeeklyUpdates/2009-06-15|June 15, 2009]] <br />
*[[WeeklyUpdates/2009-06-08|June 08, 2009]] <br />
*[[WeeklyUpdates/2009-06-01|June 01, 2009]] <br />
*[[WeeklyUpdates/2009-05-25|May 25, 2009]] - No meeting due to US Holiday: [http://en.wikipedia.org/wiki/Memorial_day Memorial Day]. Feel free to leave status! <br />
*[[WeeklyUpdates/2009-05-18|May 18, 2009]] <br />
*[[WeeklyUpdates/2009-05-11|May 11, 2009]] <br />
*[[WeeklyUpdates/2009-05-04|May 04, 2009]] <br />
*April 27, 2009 - no update meeting this week due to on-site event <br />
*[[WeeklyUpdates/2009-04-20|April 20, 2009]] <br />
*[[WeeklyUpdates/2009-04-13|April 13, 2009]] <br />
*[[WeeklyUpdates/2009-04-06|April 06, 2009]] <br />
*[[WeeklyUpdates/2009-03-30|March 30, 2009]] <br />
*[[WeeklyUpdates/2009-03-23|March 23, 2009]] <br />
*[[WeeklyUpdates/2009-03-16|March 16, 2009]] <br />
*[[WeeklyUpdates/2009-03-09|March 09, 2009]] <br />
*[[WeeklyUpdates/2009-03-02|March 02, 2009]] <br />
*[[WeeklyUpdates/2009-02-23|February 23, 2009]] <br />
*February 16, 2009 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2009-02-09|February 09, 2009]] <br />
*[[WeeklyUpdates/2009-02-02|February 02, 2009]] <br />
*[[WeeklyUpdates/2009-01-26|January 26, 2009]] <br />
*January 19, 2009 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2009-01-12|January 12, 2009]] <br />
*[[WeeklyUpdates/2009-01-05|January 05, 2009]] <br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2008 <br />
|-<br />
|<br />
*[[WeeklyUpdates/2008-12-29|December 29, 2008]] <br />
*[[WeeklyUpdates/2008-12-22|December 22, 2008]] <br />
*[[WeeklyUpdates/2008-12-15|December 15, 2008]] <br />
*[[WeeklyUpdates/2008-12-08|December 08, 2008]] <br />
*[[WeeklyUpdates/2008-12-01|December 01, 2008]] <br />
*[[WeeklyUpdates/2008-11-24|November 24, 2008]] <br />
*[[WeeklyUpdates/2008-11-17|November 17, 2008]] <br />
*[[WeeklyUpdates/2008-11-10|November 10, 2008]] <br />
*[[WeeklyUpdates/2008-11-03|November 03, 2008]] <br />
*[[WeeklyUpdates/2008-10-27|October 27, 2008]] <br />
*[[WeeklyUpdates/2008-10-20|October 20, 2008]] <br />
*[[WeeklyUpdates/2008-10-13|October 13, 2008]] <br />
*[[WeeklyUpdates/2008-10-06|October 06, 2008]] <br />
*[[WeeklyUpdates/2008-09-29|September 29, 2008]] <br />
*[[WeeklyUpdates/2008-09-22|September 22, 2008]] <br />
*[[WeeklyUpdates/2008-09-15|September 15, 2008]] <br />
*[[WeeklyUpdates/2008-09-08|September 08, 2008]] <br />
*September 01, 2008 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2008-08-25|August 25, 2008]] <br />
*[[WeeklyUpdates/2008-08-18|August 18, 2008]] <br />
*[[WeeklyUpdates/2008-08-11|August 11, 2008]] <br />
*[[WeeklyUpdates/2008-08-04|August 04, 2008]] <br />
*July 28, 2008 - No Meeting due to Summit <br />
*[[WeeklyUpdates/2008-07-21|July 21, 2008]] <br />
*[[WeeklyUpdates/2008-07-14|July 14, 2008]] <br />
*[[WeeklyUpdates/2008-07-07|July 07, 2008]] <br />
*[[WeeklyUpdates/2008-06-30|June 30, 2008]] <br />
*[[WeeklyUpdates/2008-06-23|June 23, 2008]] <br />
*[[WeeklyUpdates/2008-06-16|June 16, 2008]] <br />
*[[WeeklyUpdates/2008-06-09|June 09, 2008]] <br />
*[[WeeklyUpdates/2008-06-02|June 02, 2008]] <br />
*May 26, 2008 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2008-05-19|May 19, 2008]] <br />
*[[WeeklyUpdates/2008-05-12|May 12, 2008]] <br />
*[[WeeklyUpdates/2008-05-05|May 05, 2008]] <br />
*[[WeeklyUpdates/2008-04-28|April 28, 2008]] <br />
*[[WeeklyUpdates/2008-04-21|April 21, 2008]] <br />
*[[WeeklyUpdates/2008-04-14|April 14, 2008]] <br />
*[[WeeklyUpdates/2008-04-07|April 07, 2008]] <br />
*[[WeeklyUpdates/2008-03-31|March 31, 2008]] <br />
*[[WeeklyUpdates/2008-03-24|March 24, 2008]] <br />
*[[WeeklyUpdates/2008-03-17|March 17, 2008]] <br />
*[[WeeklyUpdates/2008-03-10|March 10, 2008]] <br />
*[[WeeklyUpdates/2008-03-03|March 03, 2008]] <br />
*[[WeeklyUpdates/2008-02-25|February 25, 2008]] <br />
*February 18, 2008 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2008-02-11|February 11, 2008]] <br />
*[[WeeklyUpdates/2008-02-04|February 04, 2008]] <br />
*[[WeeklyUpdates/2008-01-28|January 28, 2008]] <br />
*January 21, 2008 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2008-01-14|January 14, 2008]] <br />
*[[WeeklyUpdates/2008-01-07|January 07, 2008]] <br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2007 <br />
|-<br />
|<br />
*December 31, 2007 - No Meeting due to US holiday season <br />
*December 24, 2007 - No Meeting due to US holiday season <br />
*[[WeeklyUpdates/2007-12-17|December 17, 2007]] <br />
*[[WeeklyUpdates/2007-12-10|December 10, 2007]] <br />
*[[WeeklyUpdates/2007-12-03|December 03, 2007]] <br />
*[[WeeklyUpdates/2007-11-26|November 26, 2007]] <br />
*[[WeeklyUpdates/2007-11-19|November 19, 2007]] <br />
*November 12, 2007 - No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2007-11-05|November 05, 2007]] <br />
*[[WeeklyUpdates/2007-10-29|October 29, 2007]] <br />
*[[WeeklyUpdates/2007-10-22|October 22, 2007]] <br />
*[[WeeklyUpdates/2007-10-15|October 15, 2007]] <br />
*[[WeeklyUpdates/2007-10-08|October 08, 2007]] <br />
*[[WeeklyUpdates/2007-10-01|October 01, 2007]] <br />
*[[WeeklyUpdates/2007-09-24|September 24, 2007]] <br />
*[[WeeklyUpdates/2007-09-17|September 17, 2007]] <br />
*[[WeeklyUpdates/2007-09-10|September 10, 2007]] <br />
*[[WeeklyUpdates/2007-08-27|August 27, 2007]] <br />
*[[WeeklyUpdates/2007-08-20|August 20, 2007]] <br />
*[[WeeklyUpdates/2007-08-13|August 13, 2007]] <br />
*[[WeeklyUpdates/2007-08-06|August 6, 2007]] <br />
*[[WeeklyUpdates/2007-07-30|July 30, 2007]] <br />
*[[WeeklyUpdates/2007-07-23|July 23, 2007]] <br />
*[[WeeklyUpdates/2007-07-16|July 16, 2007]] <br />
*[[WeeklyUpdates/2007-07-09|July 9, 2007]] <br />
*[[WeeklyUpdates/2007-07-02|July 2, 2007]] <br />
*[[WeeklyUpdates/2007-06-25|June 25, 2007]] <br />
*[[WeeklyUpdates/2007-06-18|June 18, 2007]] <br />
*[[WeeklyUpdates/2007-06-11|June 11, 2007]] <br />
*[[WeeklyUpdates/2007-06-04|June 4, 2007]] <br />
*[[WeeklyUpdates/2007-05-21|May 21, 2007]] <br />
*[[WeeklyUpdates/2007-05-14|May 14, 2007]] <br />
*[[WeeklyUpdates/2007-05-07|May 7, 2007]] <br />
*[[WeeklyUpdates/2007-04-30|April 30, 2007]] <br />
*[[WeeklyUpdates/2007-04-23|April 23, 2007]] <br />
*[[WeeklyUpdates/2007-04-16|April 16, 2007]] <br />
*[[WeeklyUpdates/2007-04-09|April 9, 2007]] <br />
*[[WeeklyUpdates/2007-04-02|April 2, 2007]] <br />
*[[WeeklyUpdates/2007-03-26|March 26, 2007]] <br />
*[[WeeklyUpdates/2007-03-19|March 19, 2007]] <br />
*[[WeeklyUpdates/2007-03-12|March 12, 2007]] <br />
*[[WeeklyUpdates/2007-03-05|March 5, 2007]] <br />
*[[WeeklyUpdates/2007-02-26|February 26, 2007]] <br />
*[[WeeklyUpdates/2007-02-12|February 12, 2007]] <br />
*[[WeeklyUpdates/2007-02-05|February 5, 2007]] <br />
*[[WeeklyUpdates/2007-01-29|January 29, 2007]] <br />
*[[WeeklyUpdates/2007-01-22|January 22, 2007]] <br />
*[[WeeklyUpdates/2007-01-08|January 08, 2007]] <br />
|}<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! 2006 <br />
|-<br />
|<br />
*[[WeeklyUpdates/2006-12-18|December 18, 2006]] <br />
*[[WeeklyUpdates/2006-12-11|December 11, 2006]] <br />
*[[WeeklyUpdates/2006-12-04|December 4, 2006]] <br />
*[[WeeklyUpdates/2006-11-27|November 27, 2006]] <br />
*[[WeeklyUpdates/2006-11-13|November 13, 2006]] <br />
*[[WeeklyUpdates/2006-11-06|November 6, 2006]] <br />
*[[WeeklyUpdates/2006-10-30|October 30, 2006]] <br />
*[[WeeklyUpdates/2006-10-23|October 23, 2006]] <br />
*[[WeeklyUpdates/2006-10-16|October 16, 2006]] <br />
*[[WeeklyUpdates/2006-10-09|October 9, 2006]] <br />
*[[WeeklyUpdates/2006-10-02|October 2, 2006]] <br />
*[[WeeklyUpdates/2006-09-25|September 25, 2006]] <br />
*[[WeeklyUpdates/2006-09-18|September 18, 2006]] <br />
*[[WeeklyUpdates/2006-09-11|September 11, 2006]] <br />
*September 4, 2006 - No Meeting due to US and Canadian Holiday <br />
*[[WeeklyUpdates/2006-08-28|August 28, 2006]] <br />
*[[WeeklyUpdates/2006-08-21|August 21, 2006]] <br />
*[[WeeklyUpdates/2006-08-14|August 14, 2006]] <br />
*[[WeeklyUpdates/2006-08-07|August 07, 2006]] <br />
*[[WeeklyUpdates/2006-07-31|July 31, 2006]] <br />
*[[WeeklyUpdates/2006-07-24|July 24, 2006]] <br />
*[[WeeklyUpdates/2006-07-17|July 17, 2006]] <br />
*[[WeeklyUpdates/2006-07-10|July 10, 2006]] <br />
*July 3, 2006 - No Meeting due to US Holiday <br />
*June 26, 2006 - No Meeting <br />
*[[WeeklyUpdates/2006-06-19|June 19, 2006]] <br />
*[[WeeklyUpdates/2006-06-12|June 12, 2006]] <br />
*[[WeeklyUpdates/2006-06-05|June 05, 2006]] <br />
*May 29, 2006 -- No Meeting due to US Holiday <br />
*[[WeeklyUpdates/2006-05-22|May 22, 2006]] <br />
*May 15, 2006 -- No Meeting due to XTech 2006 Conference <br />
*[[WeeklyUpdates/2006-05-08|May 08, 2006]] <br />
*[[WeeklyUpdates/2006-05-01|May 01, 2006]] <br />
*[[WeeklyUpdates/2006-04-24|April 24, 2006]] <br />
*[[WeeklyUpdates/2006-04-17|April 17, 2006]] <br />
*[[WeeklyUpdates/2006-04-10|April 10, 2006]] <br />
*[[WeeklyUpdates/2006-04-03|April 03, 2006]] <br />
*[[WeeklyUpdates/2006-03-27|March 27, 2006]]<br />
|}<br />
<br />
''Note: Older [http://www-archive.mozilla.org/status/minutes.html meeting minutes] and [http://www-archive.mozilla.org/status/ status updates] are available on the www.mozilla.org archive site.''<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Gervhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2018-01-29&diff=1187753WeeklyUpdates/2018-01-292018-01-29T13:34:37Z<p>Gerv: Add self as speaker</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* https://air.mozilla.org/channels/project-meeting/ to watch and listen<br />
* join irc.mozilla.org #airmozilla for backchannel discussion<br />
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak. <br />
{{conf|8600}}<br />
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Gervase Markham<br />
| Policy Engineer; I also run [http://mozilla.org/moss/ MOSS]<br />
| MOSS Status Update<br />
| My house, Loughborough, UK<br />
| No<br />
| N/A<br />
| [https://blog.mozilla.org/blog/2018/01/23/moss-q4-supporting-python-ecosystem/ MOSS Q4 Update blog post]<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Their Name<br />
| Your Name<br />
| Intro location<br />
| Their Location<br />
| Their Role<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Gervhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2018-01-29&diff=1187752WeeklyUpdates/2018-01-292018-01-29T13:29:21Z<p>Gerv: Initial version</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* https://air.mozilla.org/channels/project-meeting/ to watch and listen<br />
* join irc.mozilla.org #airmozilla for backchannel discussion<br />
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak. <br />
{{conf|8600}}<br />
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Their Name<br />
| Your Name<br />
| Intro location<br />
| Their Location<br />
| Their Role<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Forbidden_or_Problematic_Practices&diff=1187579CA/Forbidden or Problematic Practices2018-01-25T16:29:01Z<p>Gerv: Move validation delegation to "forbidden"</p>
<hr />
<div>This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla's Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.<br />
<br />
== Forbidden Practices ==<br />
<br />
=== Long-lived Certificates ===<br />
<br />
The BRs currently require certificates to have a maximum lifetime of 39 months, and that will be reduced to 27 months in March 2018.<br />
<br />
=== Non-Standard Email Address Prefixes for Domain Ownership Validation ===<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [[CA:BaselineRequirements|Baseline Requirements]] (BRs) in the issuance and management of publicly trusted SSL certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR Section 11.1.1 (section 3.2.2.4 in BR version 1.3), which restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records and a selected whitelist of local addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster".<br />
<br />
A CA that authorizes certificate subscribers by contacting any other email addresses is deemed to be non-compliant with Mozilla's Root Store Policy and non-conforming to the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any certificates that are technically capable of issuing SSL certificates, and subordinate CAs that fail to follow these requirements reflect upon the issuing CA that certified it.<br />
<br />
=== Issuing End Entity Certificates Directly From Roots ===<br />
<br />
This is forbidden by the Baseline Requirements.<br />
<br />
=== Distributing Generated Private Keys in PKCS#12 Files ===<br />
<br />
It is reported that some CAs generate the key pairs for their subscribers,<br />
rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file. The issues include:<br />
<br />
* The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and <br />
* The distribution channels used (e.g. unencrypted email) may not be adequately secured.<br />
<br />
CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:<br />
<br />
* The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)<br />
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.<br />
<br />
=== Certificates Referencing Local Names or Private IP Addresses ===<br />
<br />
This is forbidden by the Baseline Requirements. [http://www.cabforum.org/documents.html BR 9.2.1]: “As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the '''use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016'''. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.”<br />
<br />
=== Issuing SSL Certificates for .int Domains ===<br />
<br />
It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD. In any case, CAs should be no longer issuing certificates for Internal Names.<br />
<br />
=== OCSP Responses Signed by a Certificate Under a Different Root ===<br />
<br />
CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.<br />
<br />
RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.<br />
<br />
When an OCSP responder URL is included in end-entity certificates, Firefox will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate is not the certificate of the CA that issued the certificate in question and is not issued by the CA that issued the certificate in question, the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.<br />
<br />
For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: [[CA:OCSP-TrustedResponder|Details about OCSP Trusted Responder Mode.]]<br />
<br />
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]<br />
<br />
=== Issuance of SHA-1 Certificates ===<br />
<br />
This is forbidden by the Baseline Requirements.<br />
<br />
SHA-1 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for SHA-1 based signatures. The SHA-1 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling SHA-1 will impact intermediate and end entity certificates, where the signatures are validated.<br />
<br />
There are still many end entity certificates that would be impacted if support for SHA-1 based signatures was turned off. Therefore, we are hoping to give CAs time to react, and are planning to turn off support for SHA-1 based signatures in 2017. Note that Mozilla will take this action earlier if needed to keep our users safe.<br />
* CAs should not be issuing new SHA-1 certificates, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates.<br />
* If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before 2017.<br />
* If you aren't sure whether or not your site is using SHA-1, please see https://shaaaaaaaaaaaaa.com/.<br />
* [https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Security Blog Post Regarding SHA-1 Based Signature Algorithms]<br />
<br />
=== Delegation of Domain / Email Validation to Third Parties ===<br />
<br />
This is forbidden by the Baseline Requirements, section 1.3.2.<br />
<br />
Domain and Email validation are core requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] and should always be incorporated into the issuing CA's procedures. Delegating this function to 3rd parties is not permitted.<br />
<br />
== Potentially Problematic Practices ==<br />
<br />
=== Allowing External Entities to Operate Subordinate CAs ===<br />
<br />
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. If Mozilla accepts and includes a CA's root certificate, then we have to assume that we also accept any of their future sub-CAs and their sub-CAs. Therefore, the selection criteria for a CA's sub-CAs and their sub-CAs will be a critical decision factor, as well as the documentation and auditing-of-operations requirements that the CA places on such relationships.<br />
<br />
In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of SSL or email issuance.<br />
<br />
More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is available].<br />
<br />
During the root inclusion/change process, CAs must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.<br />
<br />
After inclusion, CAs must disclose their subordinate CAs in the [https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Database], and maintain annual updates to the corresponding CP/CPS documents and audit statements.<br />
<br />
=== Generic Names for CAs ===<br />
<br />
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.<br />
<br />
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.<br />
<br />
Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the certificate. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would not be acceptable in a root certificate to be included in NSS.<br />
* CN = Root CA<br />
* OU = Certification Authorities<br />
* OU = Services<br />
* O = admin<br />
There is no information in this issuer that can be linked back to any particular CA. There is no distinguishable company name or brand name. All of the information in this issuer is too generic to do a search on and hope to find the CA.<br />
<br />
'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable to have the O be a generic term such as "Admin" because it could mislead users that rely on the issuer details, such as when you hover your mouse over the domain or organization section in the address bar.<br />
<br />
=== Lack of Communication With End Users ===<br />
<br />
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA.<br />
<br />
=== Backdating the notBefore Date ===<br />
<br />
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.<br />
<br />
=== Issuer Encoding in CRL ===<br />
<br />
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs ([https://www.ietf.org/rfc/rfc2459.txt RFC 2459], [https://www.ietf.org/rfc/rfc3280.txt RFC 3280], [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280]) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS&diff=1187562MOSS2018-01-25T11:38:26Z<p>Gerv: /* Mentors */</p>
<hr />
<div>Mozilla Open Source Support (MOSS) has a [https://www.mozilla.org/moss new website] - see there for a program overview. You can also read our [https://blog.mozilla.org/wp-content/uploads/2017/04/MOSS_2016_review_april_25-v.1.0.pdf 2016 Review and 2017 Strategic Plan].<br />
<br />
MOSS currently has 3 tracks:<br />
<br />
* MOSS Track 1 - [[MOSS/Foundational Technology|Foundational Technology]]<br />
* MOSS Track 2 - [[MOSS/Mission Partners|Mission Partners]]<br />
* MOSS Track 3 - [[MOSS/Secure Open Source|Secure Open Source]]<br />
<br />
Use the links above to find out about each track, including details on how to apply. To stay informed about and involved with MOSS in general, please join the MOSS [https://www.mozilla.org/en-US/about/forums/#moss discussion forum]. And whether you apply successfully or not, if your open source project is looking for support you may be interested in contacting some of our [[MOSS/Friends|friends]].<br />
<br />
==Application Deadlines==<br />
<br />
We consider MOSS applications in batches; deadline for the next batch is the last day of January 2018, and then every three months thereafter. Missing a deadline may cause a delay in the consideration of your application.<br />
<br />
==Selection Committee==<br />
<br />
We have formed a selection committee of 8 participants to assess awards on Tracks 1 and 2, as follows:<br />
<br />
* '''Current Committed Mozillians''' - they bring a good working knowledge of Mozilla's day-to-day activities and how various open source projects are used.<br />
** [https://mozillians.org/en-US/u/lthomson/ Laura Thomson]<br />
** [https://ritter.vg/ Tom Ritter]<br />
<br />
* '''Senior Mozilla Alumni''' - they are no longer actively involved with Mozilla on a day-to-day basis but have a deep understanding of our project and a different/outside perspective.<br />
** [http://stormyscorner.com/ Stormy Peters]<br />
** [http://shaver.off.net/diary/ Mike Shaver]<br />
** [https://mozillians.org/en-US/u/rbarnes/ Richard Barnes]<br />
<br />
* '''Other Open Source Experts''' - they bring knowledge of the role of different projects within the open source ecosystem.<br />
** [http://www.cmu.edu/iii/innovators/faculty-staff/wasserman.html Tony Wasserman]<br />
** [https://www.justindorfman.com/ Justin Dorfman]<br />
<br />
==Applicant/Awardee Resources==<br />
<br />
The application form has an "Outcomes" section, and any award will require a contract or agreement with a Schedule of Work (SoW) which defines what work is to be done. Both of those things might benefit from examining a sample Schedule of Work.<br />
<br />
* [[Media:Tor-sow.odt|Sample Schedule of Work (SoW) for Tor Project Metrics]]<br />
* [[Media:Kea-sow.pdf|Sample Schedule of Work (SoW) for Kea DHCP Server]]<br />
<br />
==Mentors==<br />
<br />
Some projects may want to apply for a MOSS award but be nervous about preparing a proposal. We have identified some mentors who are willing to help with this, and you should feel free to contact any of them: <br />
<br />
* [https://mozillians.org/u/dbryant/ David Bryant]. David is Mozilla's VP of Platform Engineering, so he is obviously clueful about software, and he’s also signed on to assist with the topics of project needs, possible solutions and appropriate amounts.<br />
* [https://mozillians.org/u/pfinette/ Pascal Finette]. Pascal launched [http://webfwd.org WebFWD] when he was a Mozilla employee and now runs Singularity University’s [http://startup.singularityu.org/accelerator/ accelerator program]. Pascal has a long history and an abiding love of working with people to build things. He has great expertise in this type of task, matching by his abiding interest in contributing to Mozilla.<br />
<br />
==Recipients==<br />
<br />
* [https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/ 2015-12-10]: Buildbot, CodeMirror, Discourse, Read The Docs, Mercurial, Django, Bro<br />
* [https://blog.mozilla.org/blog/2016/04/13/mozilla-open-source-support-moss-update-q1-2016/ 2016-04-13]: Django REST Framework, The Intern<br />
* [https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/ 2016-06-22]: Tor, Tails, Caddy, Mio, DNSSEC/DANE Chain Stapling, Godot Engine, PeARS, NVDA<br />
* [https://blog.mozilla.org/blog/2016/08/04/mozilla-awards-585000-to-nine-open-source-projects-in-q2-2016/ 2016-08-04]: PyPy<br />
* [https://blog.mozilla.org/blog/2016/10/03/moss-supports-four-more-open-source-projects-with-300k/ 2016-10-03]: Redash, Review Board, Kea, Speech Rule Engine<br />
* [https://blog.mozilla.org/blog/2017/04/10/mozilla-awards-365000-to-open-source-projects-as-part-of-moss/ 2017-04-10]: SecureDrop, libjpeg-turbo, LLVM, LEAP Encryption Access Project, Tokio<br />
* [https://blog.mozilla.org/blog/2017/10/03/mozilla-awards-half-million-open-source-projects/ 2017-10-03]: Ushahidi, webpack, RiseUp, Phaser, mod_md<br />
* ...</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS&diff=1187561MOSS2018-01-25T11:37:40Z<p>Gerv: Update Application Deadlines - oops</p>
<hr />
<div>Mozilla Open Source Support (MOSS) has a [https://www.mozilla.org/moss new website] - see there for a program overview. You can also read our [https://blog.mozilla.org/wp-content/uploads/2017/04/MOSS_2016_review_april_25-v.1.0.pdf 2016 Review and 2017 Strategic Plan].<br />
<br />
MOSS currently has 3 tracks:<br />
<br />
* MOSS Track 1 - [[MOSS/Foundational Technology|Foundational Technology]]<br />
* MOSS Track 2 - [[MOSS/Mission Partners|Mission Partners]]<br />
* MOSS Track 3 - [[MOSS/Secure Open Source|Secure Open Source]]<br />
<br />
Use the links above to find out about each track, including details on how to apply. To stay informed about and involved with MOSS in general, please join the MOSS [https://www.mozilla.org/en-US/about/forums/#moss discussion forum]. And whether you apply successfully or not, if your open source project is looking for support you may be interested in contacting some of our [[MOSS/Friends|friends]].<br />
<br />
==Application Deadlines==<br />
<br />
We consider MOSS applications in batches; deadline for the next batch is the last day of January 2018, and then every three months thereafter. Missing a deadline may cause a delay in the consideration of your application.<br />
<br />
==Selection Committee==<br />
<br />
We have formed a selection committee of 8 participants to assess awards on Tracks 1 and 2, as follows:<br />
<br />
* '''Current Committed Mozillians''' - they bring a good working knowledge of Mozilla's day-to-day activities and how various open source projects are used.<br />
** [https://mozillians.org/en-US/u/lthomson/ Laura Thomson]<br />
** [https://ritter.vg/ Tom Ritter]<br />
<br />
* '''Senior Mozilla Alumni''' - they are no longer actively involved with Mozilla on a day-to-day basis but have a deep understanding of our project and a different/outside perspective.<br />
** [http://stormyscorner.com/ Stormy Peters]<br />
** [http://shaver.off.net/diary/ Mike Shaver]<br />
** [https://mozillians.org/en-US/u/rbarnes/ Richard Barnes]<br />
<br />
* '''Other Open Source Experts''' - they bring knowledge of the role of different projects within the open source ecosystem.<br />
** [http://www.cmu.edu/iii/innovators/faculty-staff/wasserman.html Tony Wasserman]<br />
** [https://www.justindorfman.com/ Justin Dorfman]<br />
<br />
==Applicant/Awardee Resources==<br />
<br />
The application form has an "Outcomes" section, and any award will require a contract or agreement with a Schedule of Work (SoW) which defines what work is to be done. Both of those things might benefit from examining a sample Schedule of Work.<br />
<br />
* [[Media:Tor-sow.odt|Sample Schedule of Work (SoW) for Tor Project Metrics]]<br />
* [[Media:Kea-sow.pdf|Sample Schedule of Work (SoW) for Kea DHCP Server]]<br />
<br />
==Mentors==<br />
<br />
Some projects may want to apply for a MOSS award but be nervous about preparing a proposal. We have identified three mentors who are willing to help with this, and you should feel free to contact any of them: <br />
<br />
* [https://mozillians.org/u/dbryant/ David Bryant]. David is Mozilla's VP of Platform Engineering, so he is obviously clueful about software, and he’s also signed on to assist with the topics of project needs, possible solutions and appropriate amounts.<br />
* [https://mozillians.org/u/pfinette/ Pascal Finette]. Pascal launched [http://webfwd.org WebFWD] when he was a Mozilla employee and now runs Singularity University’s [http://startup.singularityu.org/accelerator/ accelerator program]. Pascal has a long history and an abiding love of working with people to build things. He has great expertise in this type of task, matching by his abiding interest in contributing to Mozilla.<br />
<br />
==Recipients==<br />
<br />
* [https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/ 2015-12-10]: Buildbot, CodeMirror, Discourse, Read The Docs, Mercurial, Django, Bro<br />
* [https://blog.mozilla.org/blog/2016/04/13/mozilla-open-source-support-moss-update-q1-2016/ 2016-04-13]: Django REST Framework, The Intern<br />
* [https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/ 2016-06-22]: Tor, Tails, Caddy, Mio, DNSSEC/DANE Chain Stapling, Godot Engine, PeARS, NVDA<br />
* [https://blog.mozilla.org/blog/2016/08/04/mozilla-awards-585000-to-nine-open-source-projects-in-q2-2016/ 2016-08-04]: PyPy<br />
* [https://blog.mozilla.org/blog/2016/10/03/moss-supports-four-more-open-source-projects-with-300k/ 2016-10-03]: Redash, Review Board, Kea, Speech Rule Engine<br />
* [https://blog.mozilla.org/blog/2017/04/10/mozilla-awards-365000-to-open-source-projects-as-part-of-moss/ 2017-04-10]: SecureDrop, libjpeg-turbo, LLVM, LEAP Encryption Access Project, Tokio<br />
* [https://blog.mozilla.org/blog/2017/10/03/mozilla-awards-half-million-open-source-projects/ 2017-10-03]: Ushahidi, webpack, RiseUp, Phaser, mod_md<br />
* ...</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1186776CA/CT Redaction2018-01-15T17:30:05Z<p>Gerv: More equivocation on DNS reconnaissance</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
===== Response =====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. In addition to the existing policies that allow whitelisting per-domain, Chrome has announced it will allow some limited flexibility for whitelisting by keys, to support organizations with managed CAs for a set of domains. This was part of the reason why Chrome deferred the date for requiring CT to April 2018.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
===== Response =====<br />
<br />
This is an argument for security through obscurity, the value of which is given different weights by different security professionals. It is noted that hostnames leak in a number of other ways and so the level of obscurity this provides is also disputed; other DNS reconnaissance techniques may well work but be more complex or time consuming than simply consulting a CT server.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
===== Response =====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
===== Response =====<br />
<br />
Why would someone DOS a random camera somewhere else on the Internet just because it was there?<br />
<br />
=== Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.<br />
<br />
===== Response =====<br />
<br />
This point assumes that the IoT will be using publicly trusted certificates.<br />
<br />
=== Logging Reveals Commercially Sensitive Information ===<br />
<br />
* Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
* Competitors scanning CT logs could infer new product/service offerings prior to their public release.<br />
<br />
===== Response =====<br />
<br />
* How would redaction help? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
* Wildcard certificates would suffice for new unreleased services even when being tested publicly. Those could be replaced with fully-qualified certificates (including EV if desired) when the service is announced.<br />
<br />
=== Logging Reveals Personally Identifiable Information ===<br />
<br />
Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).<br />
<br />
===== Response =====<br />
<br />
Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
===== Response =====<br />
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.<br />
<br />
Note that this is issue is not caused by redaction. A domain owner today might find an unredacted cert in a CT log that they don't recognize. They need some recourse too, so we don't need a new recourse mechanism/process just for redacted certs.<br />
<br />
===== Problems =====<br />
<br />
Solutions which give the original Applicant 'veto' power means that attackers have power over defenders, which is the wrong balance of concerns.<br />
<br />
Solutions which do not allow the original Applicant to 'veto', thus ensuring defenders can mitigate against attackers, run into the complexities identified. The thread covers a number of ways in which the proposed mitigation fails to provide suitable recourse that balances the needs of site operators in the face of both hostile and 'unintentional'/'unauthorized' redaction, and fails to balance the needs of site operators in the face of 'hostile unredaction', which is why recourse is hard.<br />
<br />
=== Redaction Makes Clients More Complex ===<br />
<br />
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).<br />
<br />
=== Redaction Reduces Visibility and Accountability To The Public ===<br />
<br />
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns. Some CAs may simply choose to redact all certificates or redact by default.<br />
<br />
===== Response =====<br />
<br />
How much visibility and accountability would be lost by redaction? Redaction would hide a few domain labels in the CN and SANs, but every other DN field and every other extension would be present, allowing monitors to detect nearly all the BR-noncompliance they detect today.<br />
<br />
===== Problems =====<br />
<br />
Assessing the risk of misissuance would be significantly complicated. Consider if a single redacted certificate for '(redacted).example.com', it would not be possible to independently assess whether this is a potentially misissued certificate for 'www.example.com' (in which case, the 'example.com' owner may be proactively contacted) or whether it's a sign of an upcoming product release.<br />
<br />
For those who believe wildcards are detrimental due to enabling phishing, redaction would introduce a similar method, in the form of '(redacted).example.com' being suitable for login-phishing-page.example.com<br />
<br />
For compliance with RFC 5280, a number of CAs were detected to be improperly validating hostnames, allowing situations such as spaces or invalid characters. These would not be possible to detect with redaction.<br />
<br />
=== Redaction Reduces Visibility and Accountability to Domain Owners ===<br />
<br />
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.<br />
<br />
=== Domain redaction is not sufficient ===<br />
<br />
While redacting by subdomain labels can address some needs, one case that it does not address is unreleased or unlaunched products. For example, "Contoso Ltd" requires as part of corporate security policy that all of their organizations certificates come from "Contoso Ltd Managed CA". They have an exciting new product to launch, but have not yet announced it, and it will be launched at 'example.com'. Unless it was possible to redact to '(redacted).com', they any disclosure of an 'example.com' certificate being issued by "Contoso Ltd Managed CA" would reveal the affiliation.<br />
<br />
While Contoso could restructure their launch such that their product name is a subdomain of their existing domain, to do so would significantly limit their branding opportunities, and Contoso declared this unacceptable.<br />
<br />
=== Redaction is not a security control ===<br />
<br />
Because the unredacted publicly-trusted certificates can be logged, at any time, to a CT log, their ability as a security control is limited to ensuring these certificates are never observed. Unlike DNS observations, which are not widely shared unless they end up within some form of index (such as Shodan or various search engines), and which can be removed or fade away over time, once added to CT logs, unredacted certificates can never be removed.<br />
<br />
https://crt.sh/redacted-precertificates already shows a number of examples of the equivalent public certificates having been disclosed via the existing CT log systems, and that's without systems such as browsers automatically submitting publicly trusted certificates to logs to ensure CA's compliance with stated policies.<br />
<br />
== Alternatives to Redaction ==<br />
<br />
A quick summary of suggestions people have made:<br />
<br />
* Disabling CT via browser policy in enterprises<br />
* Private roots<br />
* Wildcard certs<br />
* Log a name-constrained intermediate<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Included_CAs&diff=1186722CA/Included CAs2018-01-15T09:15:54Z<p>Gerv: </p>
<hr />
<div>= Mozilla Included CA List =<br />
<br />
These reports list all the CAs who have certificates in Mozilla's root program, together with useful information about them such as their CAA identifiers and the mechanism by which you can report a problem with that CA's certificates.<br />
<br />
* [https://ccadb-public.secure.force.com/mozilla/CAInformationReport Participating CAs] (HTML)<br />
* [https://ccadb-public.secure.force.com/mozilla/CAInformationReportCSVFormat Participating CAs] (CSV)<br />
* [https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport Problem Reporting Mechanisms]<br />
* [https://ccadb-public.secure.force.com/mozilla/CAAIdentifiersReport CAA Identifiers]</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1186605CA/CT Redaction2018-01-11T12:02:48Z<p>Gerv: /* Response */</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
===== Response =====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. In addition to the existing policies that allow whitelisting per-domain, Chrome has announced it will allow some limited flexibility for whitelisting by keys, to support organizations with managed CAs for a set of domains. This was part of the reason why Chrome deferred the date for requiring CT to April 2018.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
===== Response =====<br />
<br />
This is an argument for security through obscurity, the value of which is given different weights by different security professionals. However, in this case, the measure will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
===== Response =====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
===== Response =====<br />
<br />
Why would someone DOS a random camera somewhere else on the Internet just because it was there?<br />
<br />
=== Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.<br />
<br />
===== Response =====<br />
<br />
This point assumes that the IoT will be using publicly trusted certificates.<br />
<br />
=== Logging Reveals Commercially Sensitive Information ===<br />
<br />
* Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
* Competitors scanning CT logs could infer new product/service offerings prior to their public release.<br />
<br />
===== Response =====<br />
<br />
* How would redaction help? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
* Wildcard certificates would suffice for new unreleased services even when being tested publicly. Those could be replaced with fully-qualified certificates (including EV if desired) when the service is announced.<br />
<br />
=== Logging Reveals Personally Identifiable Information ===<br />
<br />
Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).<br />
<br />
===== Response =====<br />
<br />
Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
===== Response =====<br />
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.<br />
<br />
Note that this is issue is not caused by redaction. A domain owner today might find an unredacted cert in a CT log that they don't recognize. They need some recourse too, so we don't need a new recourse mechanism/process just for redacted certs.<br />
<br />
===== Problems =====<br />
<br />
Solutions which give the original Applicant 'veto' power means that attackers have power over defenders, which is the wrong balance of concerns.<br />
<br />
Solutions which do not allow the original Applicant to 'veto', thus ensuring defenders can mitigate against attackers, run into the complexities identified. The thread covers a number of ways in which the proposed mitigation fails to provide suitable recourse that balances the needs of site operators in the face of both hostile and 'unintentional'/'unauthorized' redaction, and fails to balance the needs of site operators in the face of 'hostile unredaction', which is why recourse is hard.<br />
<br />
=== Redaction Makes Clients More Complex ===<br />
<br />
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).<br />
<br />
=== Redaction Reduces Visibility and Accountability To The Public ===<br />
<br />
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns. Some CAs may simply choose to redact all certificates or redact by default.<br />
<br />
===== Response =====<br />
<br />
How much visibility and accountability would be lost by redaction? Redaction would hide a few domain labels in the CN and SANs, but every other DN field and every other extension would be present, allowing monitors to detect nearly all the BR-noncompliance they detect today.<br />
<br />
===== Problems =====<br />
<br />
Assessing the risk of misissuance would be significantly complicated. Consider if a single redacted certificate for '(redacted).example.com', it would not be possible to independently assess whether this is a potentially misissued certificate for 'www.example.com' (in which case, the 'example.com' owner may be proactively contacted) or whether it's a sign of an upcoming product release.<br />
<br />
For those who believe wildcards are detrimental due to enabling phishing, redaction would introduce a similar method, in the form of '(redacted).example.com' being suitable for login-phishing-page.example.com<br />
<br />
For compliance with RFC 5280, a number of CAs were detected to be improperly validating hostnames, allowing situations such as spaces or invalid characters. These would not be possible to detect with redaction.<br />
<br />
=== Redaction Reduces Visibility and Accountability to Domain Owners ===<br />
<br />
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.<br />
<br />
=== Domain redaction is not sufficient ===<br />
<br />
While redacting by subdomain labels can address some needs, one case that it does not address is unreleased or unlaunched products. For example, "Contoso Ltd" requires as part of corporate security policy that all of their organizations certificates come from "Contoso Ltd Managed CA". They have an exciting new product to launch, but have not yet announced it, and it will be launched at 'example.com'. Unless it was possible to redact to '(redacted).com', they any disclosure of an 'example.com' certificate being issued by "Contoso Ltd Managed CA" would reveal the affiliation.<br />
<br />
While Contoso could restructure their launch such that their product name is a subdomain of their existing domain, to do so would significantly limit their branding opportunities, and Contoso declared this unacceptable.<br />
<br />
=== Redaction is not a security control ===<br />
<br />
Because the unredacted publicly-trusted certificates can be logged, at any time, to a CT log, their ability as a security control is limited to ensuring these certificates are never observed. Unlike DNS observations, which are not widely shared unless they end up within some form of index (such as Shodan or various search engines), and which can be removed or fade away over time, once added to CT logs, unredacted certificates can never be removed.<br />
<br />
https://crt.sh/redacted-precertificates already shows a number of examples of the equivalent public certificates having been disclosed via the existing CT log systems, and that's without systems such as browsers automatically submitting publicly trusted certificates to logs to ensure CA's compliance with stated policies.<br />
<br />
== Alternatives to Redaction ==<br />
<br />
A quick summary of suggestions people have made:<br />
<br />
* Disabling CT via browser policy in enterprises<br />
* Private roots<br />
* Wildcard certs<br />
* Log a name-constrained intermediate<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=Bugzilla:Meetings&diff=1186105Bugzilla:Meetings2017-12-30T19:41:23Z<p>Gerv: Update for January</p>
<hr />
<div>==When and Where?==<br />
<br />
The Bugzilla community holds public meetings on the '''1st Wednesday''' of every month at 21:00 UK time. Everyone interested in being actively involved in the Bugzilla project can attend. Project leads and core developers will hopefully be there, but we welcome anyone interested in contributing, whether it be to development, testing, planning, the website, or anything else.<br />
<br />
The next meeting will be on Wednesday, [http://arewemeetingyet.com/London/2018-01-03/21:00/Bugzilla%20Meeting 2018-January-03, at 21:00 London time] (click for time in your timezone).<br />
<br />
You can participate in the following ways:<br />
<br />
* '''Mozilla Vidyo:''' in the 'Bugzilla' room; if you don't have a Mozilla LDAP login, use [https://v.mozilla.com/flex.html?roomdirect.html&key=kCjGNHjpT8sj this guest link] (requires install of proprietary client, sadly)<br />
* '''Air Mozilla:''' https://air.mozilla.org/search/?q=tag%3A+bugzilla (streaming; view/listen only)<br />
{{vidyoconf|8008}} <br />
<br />
If you want to both see and hear but don't want to use Vidyo you can connect on Air Mozilla, mute the speaker, and also dial in.<br />
<br />
Minutes will be taken on [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad] and transcribed to the wiki shortly after the meeting ends. There is also an IRC back channel on the Mozilla IRC server: irc.mozilla.org, channel #bugzilla.<br />
<br />
Video recordings of past meetings can be viewed at https://air.mozilla.org/search/?q=tag%3A+bugzilla<br />
<br />
==Agenda==<br />
<br />
# Appoint note taker and get them editing the [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad]<br />
# Dylan's plan for redirecting development<br />
# Switching www.bugzilla.org over to the new Markdown version on Github (hoping to use technique from (secret) {{bug|1409786}}) <br />
# Any other business<br />
<br />
== Summaries of previous meetings ==<br />
<br />
=== 2017 ===<br />
<br />
[[Bugzilla:Meetings:2017-11-01 | Wednesday, November 1st]] ([https://air.mozilla.org/bugzilla-project-meeting-20171108/ video])<br />
<br />
[[Bugzilla:Meetings:2017-10-04 | Wednesday, October 4th]] ([https://air.mozilla.org/bugzilla-project-meeting-20171004/ video])<br />
<br />
[[Bugzilla:Meetings:2017-09-06 | Wednesday, September 6th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170906/ video])<br />
<br />
Wednesday, August 2nd ''(cancelled due to lack of things to discuss - let's hack instead :-)''<br />
<br />
[[Bugzilla:Meetings:2017-07-05 | Wednesday, July 5th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170705/ video])<br />
<br />
[[Bugzilla:Meetings:2017-06-07 | Wednesday, June 7th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170607/ video])<br />
<br />
[[Bugzilla:Meetings:2017-05-24 | Wednesday, May 24th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170524/ video])<br />
<br />
[[Bugzilla:Meetings:2017-04-26 | Wednesday, April 26th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170426/ video])<br />
<br />
[[Bugzilla:Meetings:2017-03-22 | Wednesday, March 22nd]] ([https://air.mozilla.org/bugzilla-project-meeting-2017-03-22/ video])<br />
<br />
Wednesday, February 22nd ''(cancelled due to lack of attendance by key people - see developers mailing list for followup discussion)''<br />
<br />
Wednesday, January 25th ''(cancelled due to lack of attendance by key people)''<br />
<br />
=== 2016 ===<br />
[[Bugzilla:Meetings:2016-12-28 | Wednesday, December 28th]]<br />
<br />
Wednesday, November 23rd ''(cancelled due to US holidays)''<br />
<br />
[[Bugzilla:Meetings:2016-10-26 | Wednesday, October 26th]]<br />
<br />
[[Bugzilla:Meetings:2016-09-28 | Wednesday, September 28th]]<br />
<br />
[[Bugzilla:Meetings:2016-08-24 | Wednesday, August 24th]] -- notes missing<br />
<br />
[[Bugzilla:Meetings:2016-07-27 | Wednesday, July 27th]]<br />
<br />
Wednesday, June 22nd ''(cancelled)''<br />
<br />
[[Bugzilla:Meetings:2016-05-25 | Wednesday, May 25th]]<br />
<br />
[[Bugzilla:Meetings:2016-04-27 | Wednesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2016-03-23 | Wednesday, March 23rd]]<br />
<br />
[[Bugzilla:Meetings:2016-02-24 | Wednesday, February 24th]]<br />
<br />
[[Bugzilla:Meetings:2016-01-27 | Wednesday, January 27th]]<br />
<br />
=== 2015 ===<br />
[[Bugzilla:Meetings:2015-12-23 | Wednesday, December 23rd]]<br />
<br />
[[Bugzilla:Meetings:2015-11-25 | Wednesday, November 25th]]<br />
<br />
Wednesday, October 28th ''(skipped due to one attendee; meeting moves time next month)''<br />
<br />
Wednesday, September 23 ''(meeting happened but no notes taken)''<br />
<br />
[[Bugzilla:Meetings:2015-08-26 | Wednesday, August 26th]]<br />
<br />
[[Bugzilla:Meetings:2015-07-22 | Wednesday, July 22nd]]<br />
<br />
Wednesday, June 24th ''(skipped due to Mozilla all-hands)''<br />
<br />
[[Bugzilla:Meetings:2015-05-26 | Wednesday, May 26th]]<br />
<br />
Wednesday, April 22nd ''(skipped due to a single agenda item and no attendees)''<br />
<br />
[[Bugzilla:Meetings:2015-03-25 | Wednesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-02-25 | Wednesday, February 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-01-28 | Wednesday, January 28th]] ''(skipped due to lack of agenda items)''<br />
<br />
=== 2014 ===<br />
[[Bugzilla:Meetings:2014-11-26 | Wednesday, November 26th]]<br />
<br />
[[Bugzilla:Meetings:2014-10-22 | Wednesday, October 22nd]]<br />
<br />
[[Bugzilla:Meetings:2014-09-24 | Wednesday, September 24th]]<br />
<br />
[[Bugzilla:Meetings:2014-08-27 | Wednesday, August 27th]]<br />
<br />
[[Bugzilla:Meetings:2014-07-23 | Wednesday, July 23rd]]<br />
<br />
[[Bugzilla:Meetings:2014-06-25 | Wednesday, June 25th]]<br />
<br />
[[Bugzilla:Meetings:2014-05-28 | Wednesday, May 28th]]<br />
<br />
[[Bugzilla:Meetings:2014-04-23 | Wednesday, April 23rd]]<br />
<br />
=== 2013 ===<br />
[[Bugzilla:Meetings:2013-07-17 | Wednesday, July 17th]]<br />
<br />
=== 2012 ===<br />
[[Bugzilla:Meetings:2012-02-15 | Wednesday, February 15th]]<br />
<br />
=== 2011 ===<br />
<br />
[[Bugzilla:Meetings:2011-03-01 | Tuesday, March 1st]]<br />
<br />
=== 2010 ===<br />
<br />
[[Bugzilla:Meetings:2010-01-12 | Tuesday, January 12th]]<br />
<br />
[[Bugzilla:Meetings:2010-04-27 | Tuesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2010-10-05 | Tuesday, October 5th]]<br />
<br />
=== 2009 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-13 | Tuesday, January 13th]]<br />
<br />
[[Bugzilla:Meetings:2009-02-10 | Tuesday, February 10th]]<br />
<br />
[[Bugzilla:Meetings:2009-03-10 | Tuesday, March 10th]] (50th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2009-04-14 | Tuesday, April 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-07-14 | Tuesday, July 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-08-18 | Tuesday, August 18th]]<br />
<br />
[[Bugzilla:Meetings:2009-10-27 | Tuesday, October 27th]]<br />
<br />
=== 2008 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-15 | Tuesday, January 15th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-12 | Tuesday, February 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-26 | Tuesday, February 26th]]<br />
<br />
[[Bugzilla:Meetings:2008-03-25 | Tuesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2008-04-08 | Tuesday, April 8th]] (40th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2008-05-06 | Tuesday, May 6th]]<br />
<br />
[[Bugzilla:Meetings:2008-05-20 | Tuesday, May 20th]]<br />
<br />
[[Bugzilla:Meetings:2008-07-01 | Tuesday, July 1st]]<br />
<br />
[[Bugzilla:Meetings:2008-08-12 | Tuesday, August 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-09-16 | Tuesday, September 16th]]<br />
<br />
[[Bugzilla:Meetings:2008-10-21 | Tuesday, October 21st]]<br />
<br />
[[Bugzilla:Meetings:2008-11-18 | Tuesday, November 18th]]<br />
<br />
=== 2007 ===<br />
<br />
[[Bugzilla:Meetings:2007-01-09 | Tuesday, January 9th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-06 | Tuesday, February 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-27 | Tuesday, February 27th]]<br />
<br />
[[Bugzilla:Meetings:2007-03-20 | Tuesday, March 20th]]<br />
<br />
[[Bugzilla:Meetings:2007-05-15 | Tuesday, May 15th]]<br />
<br />
[[Bugzilla:Meetings:2007-06-12 | Tuesday, June 12th]]<br />
<br />
[[Bugzilla:Meetings:2007-07-10 | Tuesday, July 10th]] (30th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2007-08-07 | Tuesday, August 7th]]<br />
<br />
[[Bugzilla:Meetings:2007-09-04 | Tuesday, September 4th]]<br />
<br />
[[Bugzilla:Meetings:2007-10-02 | Tuesday, October 2nd]]<br />
<br />
[[Bugzilla:Meetings:2007-11-06 | Tuesday, November 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-12-04 | Tuesday, December 4th]]<br />
<br />
=== 2006 ===<br />
<br />
[[Bugzilla:Meetings:2006-02-02 | Thursday, February 2nd]] (our first IRC meeting!)<br />
<br />
[[Bugzilla:Meetings:2006-02-14 | Tuesday, February 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-02-28 | Tuesday, February 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-14 | Tuesday, March 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-28 | Tuesday, March 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-11 | Tuesday, April 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-25 | Tuesday, April 25th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-09 | Tuesday, May 9th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-23 | Tuesday, May 23rd]]<br />
<br />
[[Bugzilla:Meetings:2006-06-06 | Tuesday, June 6th]] (10th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-06-22 | Thursday, June 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-07-11 | Tuesday, July 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-07-24 | Monday, July 24th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-08 | Tuesday, August 8th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-22 | Tuesday, August 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-09-05 | Tuesday, September 5th]]<br />
<br />
[[Bugzilla:Meetings:2006-09-19 | Tuesday, September 19th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-03 | Tuesday, October 3rd]]<br />
<br />
[[Bugzilla:Meetings:2006-10-17 | Tuesday, October 17th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-31 | Tuesday, October 31st]] (20th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-11-14 | Tuesday, November 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-11-28 | Tuesday, November 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-12-12 | Tuesday, December 12th]]<br />
<br />
[http://www.bugzilla.jp/bzwiki/bz/Bugzilla:Meetings ja]<br />
<br />
[[category:Bugzilla|Meetings]]</div>Gervhttps://wiki.mozilla.org/index.php?title=Modules/Activities&diff=1185919Modules/Activities2017-12-19T10:37:16Z<p>Gerv: Update owner of Commit Access Policy</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Governance<br />
|description=Policies and process for how we distribute authority and govern ourselves; including:<br />
* Development and Implementation of new policies as appropriate for delegation of authority and responsibility<br />
* Management of the source tree<br />
* Balancing different constituencies of the Mozilla project<br />
* Maintaining the Mozilla identity as we take on new activities<br />
<br />
[http://www.mozilla.org/about/roles.html#ultimate-decision-makers Ultimate authority] within the project rests with the owner and peer(s) of this module, and project decisions can be escalated to here.<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=governance<br />
|url=https://wiki.mozilla.org/GovernanceIssues<br />
|components=mozilla.org::Governance<br />
}}<br />
<br />
===Governance Sub Modules===<br />
<br />
{{Module<br />
|name=Module Ownership System<br />
|description=Healthy operation of the module ownership system, including topics such as:<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve.<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners <br />
|owner= [mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:dmose@mozilla.org Dan Mosedale], [mailto:kairo@kairo.at Robert Kaiser], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dbaron@dbaron.org David Baron], [mailto:dascher@mozilla.com David Ascher], [mailto:mitchell@mozilla.org Mitchell Baker], Guillermo Movia (as 'observer'. This is a new role we're trying out as of Jan 2012. The observers are watching and learning how the module operates, since there's no code in this module to serve as a learning /participation tool.)<br />
|ownersemeritus=Brendan Eich<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Policy<br />
|description=<br />
|owner=[mailto:mconnor@mozilla.com Mike Connor]<br />
|peers=<br />
|ownersemeritus=Mitchell Baker<br />
|group=<br />
|url=http://www.mozilla.org/hacking/committer/<br />
|components=mozilla.org::Miscellaneous<br />
}}<br />
<br />
{{Module<br />
|name=Commit Access Implementation<br />
|description= Governance structure for the work of enforcing and implementing Mozilla's commit access policy.<br />
|owner=[mailto:marcia@mozilla.com Marcia Knous]<br />
|peers=[mailto:jmatthews@mozilla.com Josh Matthews]<br />
|group=<br />
|url=https://wiki.mozilla.org/Commit_Access_Implementation_module<br />
|components=mozilla.org::Repository Account Requests<br />
}}<br />
<br />
{{Module<br />
|name=Security Policy<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:security@mozilla.org Al Billings]<br />
|group=dev-security<br />
|url=http://www.mozilla.org/security/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla CA Certificate Policy<br />
|description=Definition and enforcement of policies governing Certification Authorities, their root certificates included in Mozilla software products, and intermediate and end-entity certificates within those CA hierarchies.<br />
|owner=[mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|peers=[mailto:gerv@mozilla.org Gervase Markham]<br />
|ownersemeritus=Frank Hecker<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes<br />
|group=dev-security-policy<br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Code Review Policy<br />
|description=<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|peersemeritus=Brendan Eich<br />
|group=<br />
|url=http://www.mozilla.org/hacking/reviewers.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Performance Regression Policy<br />
|description=<br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=<br />
|group=<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Planet Mozilla<br />
|description=Content and policy for planet.mozilla.org, including topics such as:<br />
* which blogs are syndicated to planet.mozilla.org<br />
* which content from syndicated blogs is included<br />
* other planet.mozilla.org policy issues <br />
|owner=[mailto:mhoye@mozilla.com Mike Hoye]<br />
|peers=[mailto:asa@reedloden.org Asa Dotzler]<br />
|group=<br />
|url=<br />
|components=Websites::planet.mozilla.org<br />
|ownersemeritus=Robert Accettura<br />
|peersemeritus=Reed Loden<br />
}}<br />
<br />
{{Module<br />
|name=Mozilla Public License<br />
|description=Maintenance and development of the MPL<br />
* changes in the legal landscape which could /should be reflected<br />
* changes in FLOSS development practices which could / should be reflected <br />
|owner=[mailto:mitchell@mozilla.org Mitchell Baker]<br />
|peers=[mailto:handerson@mozilla.com Harvey Anderson], [mailto:gerv@mozilla.org Gervase Markham], [mailto:MeekerH@gtlaw.com Heather Meeker], [mailto:villalu@gtlaw.com Luis Villa]<br />
|group=governance-mpl-update<br />
|url=<br />
|components=mozilla.org::Licensing<br />
}}<br />
<br />
{{Module<br />
|name=CA Certificates<br />
|description=Determine which root certificates should be included in Mozilla software products, which trust bits should be set on them, and which of them should be enabled for EV treatment. Evaluate requests from Certification Authorities (CAs) for inclusion or removal of root certificates, and for updating trust bit settings or enabling EV treatment for already included root certificates.<br />
|owner=[mailto:kwilson@mozilla.com Kathleen Wilson]<br />
|peers=[mailto:gerv@mozilla.org Gervase Markham], [mailto:sleevi@google.com Ryan Sleevi]<br />
|ownersemeritus=Frank Hecker<br />
|peersemeritus= Johnathan Nightingale, Sid Stamm, Richard Barnes<br />
|group=dev-security-policy <br />
|url=http://www.mozilla.org/projects/security/certs/policy/<br />
|components=mozilla.org::CA Certificates<br />
}}<br />
<br />
{{Module<br />
|name=Participation Metrics<br />
|description=Develop, monitor and analyze metrics relating to participation in the Mozilla project, including such things as:<br />
* determining which questions are most important to ask (how many people do X?)<br />
* determining what data is relevant to answer these questions<br />
* designing and operating a system to generate the requested data<br />
* analyzing the resulting metrics<br />
* notifying appropriate people when participation starts to change significantly<br />
* assisting various groups to understand and use the metrics to strengthen participation<br />
* produce periodic report/analysis of participation metrics <br />
|owner=[mailto:ppapadeas@mozilla.com Pierros Papadeas]<br />
|peers=[mailto:dboswell@mozilla.com David Boswell], [mailto:asa@mozilla.com Asa Dotzler], [mailto:deinspanjer@mozilla.com Daniel Einspanjer], [mailto:aelliott@mozilla.com Annie Elliott], [mailto:david@eaves.ca David Eaves], [mailto:michelle@mozillafoundation.org Michelle Thorne], [mailto:ryan@mozillafoundation.org Ryan Merkley]<br />
|group=<br />
|url=https://wiki.mozilla.org/Contribute/Dashboards<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Productive Communications Module (aka the "Conductors")<br />
|description=Promotion of productive communications styles within Mozilla, where "productive" means simultaneously honest and civil. This includes topics such as:<br />
*coaching people on who to respond to nasty settings;<br />
*coaching people to think a little before they hit post/send/submit.<br />
*coaching people on how to be direct and yet civil, notifying people they are at or past the boundary;<br />
*coaching people to recognize legitimate comments/ complaints / differences of opinion despite poor communication style<br />
*redirecting conversations into a better place,<br />
*building a culture of respect in how we communicate with difficult and contentious issues<br />
*when necessary, letting people know they've gone beyond the boundaries.<br />
|owner=Stormy Peters<br />
|peers=David Ascher , Dietrich Ayala, Mike Beltzner, Matt Claypotch, David Eaves, Gen Kanai, Michelle Luna, Kev Needham, Johnathan Nightingale, Melissa Shapiro, Gavin Sharp, Benjamin Smedberg, Mike Taylor (Bear), David Tenser, Daniel Veditz, [mailto:conductors@mozilla.org conductors@mozilla.org] (collectively)<br />
|group=mozilla.governance<br />
|url=http://wiki.mozilla.org/Conductors<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Internet Public Policy<br />
|description=Mozilla activities related to Public Policy issues that affect the health of the Internet. Our working definition of Public Policy is taken from Wikipedia: "courses of action, regulatory measures, laws, and funding priorities concerning a given topic promulgated by a governmental entity or its representatives." <br />
This includes topics such as:<br />
*determining if Mozilla should take an official position on a particular public policy issue<br />
*determining what that position is <br />
*determining how mozilla communicates our position <br />
**global, multi-regional, regional or local action<br />
**direct action, or support of action by other aligned groups<br />
**public campaigns or opinion pieces or educational activities, dialog with policy makers, other techniques TBD<br />
*strengthening local community capabilities to address public policy issues <br />
|owner=[mailto:handerson@mozilla.com Harvey Anderson]<br />
|peers=[mailto:mitchell@mozilla.org Mitchell Baker], [mailto:afowler@mozilla.com Alex Fowler], [mailto:mark@mozillafoundation.org Mark Surman]<br />
|url=https://wiki.mozilla.org/Netpolicy<br />
|group=https://mail.mozilla.org/listinfo/netpolicy<br />
|components=<br />
|notes=Area Expert Advisors: Katharina Borchert, Andrew Bridges, Hanno Kaiser, Andrew McLaughlin, Danny Weitzner, Gene Kimmelman, and Ronaldo Lemos<br />
}}<br />
Area Expert Advisors are people with particular expertise who have agreed to assist Mozilla with their area-specific expertise. The Area Expert Advisors are different from peers. A peer is someone to whom the module owner has delegated some of her/his authority and a peer is expected to provide leadership for Mozilla within our specific context. Area Expert Advisors are advisors to Mozilla. They may become peers, but they need not. <br />
<br />
<br />
{{Module<br />
|name=Weekly Project All Hands Meeting<br />
|description=Responsibility for the weekly meetings, including:<br />
* determining and implementing the best organization and structure for the meeting<br />
* Determining and implementing the most useful content<br />
* Identifying and implementing technical means to make the meeting accessible and interactive for participants around the globe<br />
|owner=[mailto:potch@mozilla.com Matt Claypotch]<br />
|peers=[mailto:asa@mozilla.org Asa Dotzler], MoCo Desktop IT services<br />
|group=mozilla.governance<br />
|url=https://wiki.mozilla.org/WeeklyUpdates<br />
|components=<br />
}}<br />
<br />
(It's a new thing to have a group such as "MoCo Desktop IT services" as a<br />
"peer." We're trying this based on the idea that anyone in the Desktop IT group<br />
should be able to resolve problems and make fixes to the systems.)<br />
<br />
===Other===<br />
<br />
{{Module<br />
|name=Popcorn Events<br />
|description=Events to support and grow the popcorn project. These include hack days pairing web developers and media creators, as well as Learning Labs to teach popcorn.js and Popcorn Maker.<br />
|owner=[mailto:brett@mozillafoundation.org Brett Gaylor]<br />
|peers=[mailto:michelle@mozillafoundation.org Michelle Thorne]<br />
|group=mozilla.community.popcorn<br />
|url=http://www.mozillapopcorn.org/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Tree Sheriffs<br />
|description=Tree Sheriffs aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines. <br />
|owner=[mailto:rvandermeulen@mozilla.com Ryan VanderMeulen] (RyanVM)<br />
|peers=[mailto:wkocher@mozilla.com Wes Kocher (KWierso)], [mailto:cbook@mozilla.com Carsten Book (Tomcat)]<br />
|group=dev-tree-management<br />
|url=https://wiki.mozilla.org/Sheriffing<br />
|components=Tree Management::Visibility Requests<br />
}}</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Forbidden_or_Problematic_Practices&diff=1185426CA/Forbidden or Problematic Practices2017-12-06T16:00:50Z<p>Gerv: Remove misleading word</p>
<hr />
<div>This page contains comments about various CA practices that have been the subject of discussion in past CA evaluations. Some of these practices are addressed by the [http://www.mozilla.org/projects/security/certs/policy Mozilla's Root Store Policy] and are forbidden. They are listed here because they are things CAs often get wrong. Others, we do not necessarily consider security risks, but we want to highlight them because they've occasioned controversy in the past and have in some cases caused approval of applications to be delayed. Additional practices may be addressed in future versions of the policy.<br />
<br />
== Forbidden Practices ==<br />
<br />
=== Long-lived Certificates ===<br />
<br />
The BRs currently require certificates to have a maximum lifetime of 39 months, and that will be reduced to 27 months in March 2018.<br />
<br />
=== Non-Standard Email Address Prefixes for Domain Ownership Validation ===<br />
<br />
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] requires CAs to conform to the [[CA:BaselineRequirements|Baseline Requirements]] (BRs) in the issuance and management of publicly trusted SSL certificates. This includes the BR restrictions on the use of email as a way of validating that the certificate subscriber owns or controls the domain name to be included in the certificate. CAs are expected to conform to BR Section 11.1.1 (section 3.2.2.4 in BR version 1.3), which restricts the email addresses that may be used to authenticate the subscriber to information listed in the "registrant", "technical", or "administrative" WHOIS records and a selected whitelist of local addresses, which are limited to local-parts of "admin", "administrator", "webmaster", "hostmaster", and "postmaster".<br />
<br />
A CA that authorizes certificate subscribers by contacting any other email addresses is deemed to be non-compliant with Mozilla's Root Store Policy and non-conforming to the Baseline Requirements, and may have action taken against it. CAs are also reminded that Mozilla's Root Store Policy and the Baseline Requirements extend to any certificates that are technically capable of issuing SSL certificates, and subordinate CAs that fail to follow these requirements reflect upon the issuing CA that certified it.<br />
<br />
=== Issuing End Entity Certificates Directly From Roots ===<br />
<br />
This is forbidden by the Baseline Requirements.<br />
<br />
=== Distributing Generated Private Keys in PKCS#12 Files ===<br />
<br />
It is reported that some CAs generate the key pairs for their subscribers,<br />
rather than having the subscribers generate their own key pairs, and once generated, those CAs distribute the private key, together with the issued public key certificate and its chain, to the subscriber in a PKCS#12 file. The issues include:<br />
<br />
* The user doesn't know or control who else possesses and can use his private key (decrypt his private messages or forge his signature), and <br />
* The distribution channels used (e.g. unencrypted email) may not be adequately secured.<br />
<br />
CAs must never generate the key pairs for signer or SSL certificates. CAs may only generate the key pairs for SMIME certificates. Distribution or transfer of certificates in PKCS#12 form through unsecure electronic channels is not allowed. If a PKCS#12 file is distributed via a physical data storage device, then:<br />
<br />
* The storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal)<br />
* The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the storage.<br />
<br />
=== Certificates Referencing Local Names or Private IP Addresses ===<br />
<br />
This is forbidden by the Baseline Requirements. [http://www.cabforum.org/documents.html BR 9.2.1]: “As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName (SAN) extension or Subject Common Name field containing a Reserved IP Address or Internal Server Name, the CA shall notify the Applicant that the '''use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016'''. Also as of the Effective Date, the CA shall not issue a certificate with an Expiry Date later than 1 November 2015 with a SAN or Subject Common Name field containing a Reserved IP Address or Internal Server Name. As from 1 October 2016, CAs shall revoke all unexpired Certificates.”<br />
<br />
=== Issuing SSL Certificates for .int Domains ===<br />
<br />
It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD. In any case, CAs should be no longer issuing certificates for Internal Names.<br />
<br />
=== OCSP Responses Signed by a Certificate Under a Different Root ===<br />
<br />
CAs who issue certificates with OCSP URLs in AIA extensions should make sure that the OCSP responses conform to RFC 2560, and work correctly for Mozilla users without requiring the user to find and install the OCSP responder's certificate, that is, the certificate with which the OCSP response signatures are verified.<br />
<br />
RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.<br />
<br />
When an OCSP responder URL is included in end-entity certificates, Firefox will by default attempt to check the certificate's status via OCSP. If the OCSP signer certificate is not the certificate of the CA that issued the certificate in question and is not issued by the CA that issued the certificate in question, the OCSP check will fail with an NSS error code for OCSP, such as SEC_ERROR_OCSP_UNAUTHORIZED_REQUEST or SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.<br />
<br />
For a detailed explanation about why an OCSP responder should not use a self-signed OCSP responder certificate and depend on Trusted Responder Mode within the Firefox browser, see: [[CA:OCSP-TrustedResponder|Details about OCSP Trusted Responder Mode.]]<br />
<br />
Please test your OCSP responder within the Firefox browser by enforcing OCSP as per our [[CA:Recommended_Practices#OCSP|CA Recommended Practices for OCSP.]]<br />
<br />
=== Issuance of SHA-1 Certificates ===<br />
<br />
This is forbidden by the Baseline Requirements.<br />
<br />
SHA-1 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for SHA-1 based signatures. The SHA-1 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling SHA-1 will impact intermediate and end entity certificates, where the signatures are validated.<br />
<br />
There are still many end entity certificates that would be impacted if support for SHA-1 based signatures was turned off. Therefore, we are hoping to give CAs time to react, and are planning to turn off support for SHA-1 based signatures in 2017. Note that Mozilla will take this action earlier if needed to keep our users safe.<br />
* CAs should not be issuing new SHA-1 certificates, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates.<br />
* If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before 2017.<br />
* If you aren't sure whether or not your site is using SHA-1, please see https://shaaaaaaaaaaaaa.com/.<br />
* [https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ Security Blog Post Regarding SHA-1 Based Signature Algorithms]<br />
<br />
== Potentially Problematic Practices ==<br />
<br />
=== Delegation of Domain / Email Validation to Third Parties ===<br />
<br />
Domain and Email validation are core requirements of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] and should always be incorporated into the issuing CA's procedures whenever possible. Registration Authorities (RA) or other third parties performing such functions must provide attestations about their procedures and/or should be audited together with the issuing CA. The CA must demonstrate clear and efficient controls attesting the performance of its RAs. Delegation of domain/email validation to third parties should generally be avoided.<br />
<br />
=== Allowing External Entities to Operate Subordinate CAs ===<br />
<br />
Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. If Mozilla accepts and includes a CA's root certificate, then we have to assume that we also accept any of their future sub-CAs and their sub-CAs. Therefore, the selection criteria for a CA's sub-CAs and their sub-CAs will be a critical decision factor, as well as the documentation and auditing-of-operations requirements that the CA places on such relationships.<br />
<br />
In order to best ensure the safety and security of Mozilla users, Mozilla has a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ single consistent policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of SSL or email issuance.<br />
<br />
More information on our disclosure requirements [https://wiki.mozilla.org/CA:SubordinateCA_checklist#Non-disclosable_Intermediate_Certificates is available].<br />
<br />
During the root inclusion/change process, CAs must provide a clear description of the subordinate CAs that are operated by external third parties, and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with Mozilla's CA Certificate Policy requirements as per the Subordinate CA Checklist.<br />
<br />
After inclusion, CAs must disclose their subordinate CAs in the [https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Common CA Database], and maintain annual updates to the corresponding CP/CPS documents and audit statements.<br />
<br />
=== Generic Names for CAs ===<br />
<br />
In various contexts Firefox and other Mozilla-based products display to users the names of root CAs, issuing CAs, and intermediate CAs in general. In some cases CA names are very generic, e.g., "Secure Server CA"; this makes it difficult for users to ascertain who operates the CA without undertaking a detailed investigation.<br />
<br />
Our recommendation is that all CA names incorporate an organizational name or product brand name sufficiently unique to allow relatively straightforward identification of the CA.<br />
<br />
Additionally, the issuer and subject information in the root certificate should provide clear indication about who owns or operates the certificate. Generic issuer and subject information inhibits the users' ability to establish a chain of trust, and to pursue complaints when appropriate. For instance, the following issuer information would not be acceptable in a root certificate to be included in NSS.<br />
* CN = Root CA<br />
* OU = Certification Authorities<br />
* OU = Services<br />
* O = admin<br />
There is no information in this issuer that can be linked back to any particular CA. There is no distinguishable company name or brand name. All of the information in this issuer is too generic to do a search on and hope to find the CA.<br />
<br />
'''Important:''' Both the O and the CN must be meaningful, and not generic terms such as "admin" or "root". It is not acceptable to have the O be a generic term such as "Admin" because it could mislead users that rely on the issuer details, such as when you hover your mouse over the domain or organization section in the address bar.<br />
<br />
=== Lack of Communication With End Users ===<br />
<br />
CAs should be contactable by, and accept and act upon complaints made by, those relying on their assertions of identity. For CAs included in Mozilla, this will include being responsive to members of the general public, including people who have not purchased products from that CA.<br />
<br />
=== Backdating the notBefore Date ===<br />
<br />
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.<br />
<br />
=== Issuer Encoding in CRL ===<br />
<br />
The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the exact same string types and field contents. The specs ([https://www.ietf.org/rfc/rfc2459.txt RFC 2459], [https://www.ietf.org/rfc/rfc3280.txt RFC 3280], [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280]) permit them to mismatch, but that causes compatibility issues with various clients -- in such cases client software might not find the entry for the revoked certificate in the CRL.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1185320CA/CT Redaction2017-12-05T12:04:08Z<p>Gerv: More tweaks</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
===== Response =====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. In addition to the existing policies that allow whitelisting per-domain, Chrome has announced it will allow some limited flexibility for whitelisting by keys, to support organizations with managed CAs for a set of domains. This was part of the reason why Chrome deferred the date for requiring CT to April 2018.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
===== Response =====<br />
<br />
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
===== Response =====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
===== Response =====<br />
<br />
Why would someone DOS a random camera somewhere else on the Internet just because it was there?<br />
<br />
=== Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.<br />
<br />
===== Response =====<br />
<br />
This point assumes that the IoT will be using publicly trusted certificates.<br />
<br />
=== Logging Reveals Commercially Sensitive Information ===<br />
<br />
* Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
* Competitors scanning CT logs could infer new product/service offerings prior to their public release.<br />
<br />
===== Response =====<br />
<br />
* How would redaction help? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
* Wildcard certificates would suffice for new unreleased services even when being tested publicly. Those could be replaced with fully-qualified certificates (including EV if desired) when the service is announced.<br />
<br />
=== Logging Reveals Personally Identifiable Information ===<br />
<br />
Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).<br />
<br />
===== Response =====<br />
<br />
Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
===== Response =====<br />
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.<br />
<br />
Note that this is issue is not caused by redaction. A domain owner today might find an unredacted cert in a CT log that they don't recognize. They need some recourse too, so we don't need a new recourse mechanism/process just for redacted certs.<br />
<br />
===== Problems =====<br />
<br />
Solutions which give the original Applicant 'veto' power means that attackers have power over defenders, which is the wrong balance of concerns.<br />
<br />
Solutions which do not allow the original Applicant to 'veto', thus ensuring defenders can mitigate against attackers, run into the complexities identified. The thread covers a number of ways in which the proposed mitigation fails to provide suitable recourse that balances the needs of site operators in the face of both hostile and 'unintentional'/'unauthorized' redaction, and fails to balance the needs of site operators in the face of 'hostile unredaction', which is why recourse is hard.<br />
<br />
=== Redaction Makes Clients More Complex ===<br />
<br />
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).<br />
<br />
=== Redaction Reduces Visibility and Accountability To The Public ===<br />
<br />
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns. Some CAs may simply choose to redact all certificates or redact by default.<br />
<br />
===== Response =====<br />
<br />
How much visibility and accountability would be lost by redaction? Redaction would hide a few domain labels in the CN and SANs, but every other DN field and every other extension would be present, allowing monitors to detect nearly all the BR-noncompliance they detect today.<br />
<br />
===== Problems =====<br />
<br />
Assessing the risk of misissuance would be significantly complicated. Consider if a single redacted certificate for '(redacted).example.com', it would not be possible to independently assess whether this is a potentially misissued certificate for 'www.example.com' (in which case, the 'example.com' owner may be proactively contacted) or whether it's a sign of an upcoming product release.<br />
<br />
For those who believe wildcards are detrimental due to enabling phishing, redaction would introduce a similar method, in the form of '(redacted).example.com' being suitable for login-phishing-page.example.com<br />
<br />
For compliance with RFC 5280, a number of CAs were detected to be improperly validating hostnames, allowing situations such as spaces or invalid characters. These would not be possible to detect with redaction.<br />
<br />
=== Redaction Reduces Visibility and Accountability to Domain Owners ===<br />
<br />
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.<br />
<br />
=== Domain redaction is not sufficient ===<br />
<br />
While redacting by subdomain labels can address some needs, one case that it does not address is unreleased or unlaunched products. For example, "Contoso Ltd" requires as part of corporate security policy that all of their organizations certificates come from "Contoso Ltd Managed CA". They have an exciting new product to launch, but have not yet announced it, and it will be launched at 'example.com'. Unless it was possible to redact to '(redacted).com', they any disclosure of an 'example.com' certificate being issued by "Contoso Ltd Managed CA" would reveal the affiliation.<br />
<br />
While Contoso could restructure their launch such that their product name is a subdomain of their existing domain, to do so would significantly limit their branding opportunities, and Contoso declared this unacceptable.<br />
<br />
=== Redaction is not a security control ===<br />
<br />
Because the unredacted publicly-trusted certificates can be logged, at any time, to a CT log, their ability as a security control is limited to ensuring these certificates are never observed. Unlike DNS observations, which are not widely shared unless they end up within some form of index (such as Shodan or various search engines), and which can be removed or fade away over time, once added to CT logs, unredacted certificates can never be removed.<br />
<br />
https://crt.sh/redacted-precertificates already shows a number of examples of the equivalent public certificates having been disclosed via the existing CT log systems, and that's without systems such as browsers automatically submitting publicly trusted certificates to logs to ensure CA's compliance with stated policies.<br />
<br />
== Alternatives to Redaction ==<br />
<br />
A quick summary of suggestions people have made:<br />
<br />
* Disabling CT via browser policy in enterprises<br />
* Private roots<br />
* Wildcard certs<br />
* Log a name-constrained intermediate<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1185061CA/CT Redaction2017-11-30T09:31:02Z<p>Gerv: A few clean-ups</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
===== Response =====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots. However, Chrome's enterprise policy requires a list of all domain names that may appear in non-logged certs, and some enterprise customers have said they manage hundreds of domains that change frequently, so this approach may have challenges. It would be useful to know which reasons for redaction are of interest to such customers; it can't be the "concealing network topography" reason, because surely no company has a list of hundreds of internal-use domains which change frequently.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
===== Response =====<br />
<br />
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
===== Response =====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
===== Response =====<br />
<br />
Why would someone DOS a random camera somewhere else on the Internet just because it was there?<br />
<br />
=== Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.<br />
<br />
=== Logging Reveals Commercially Sensitive Information ===<br />
<br />
* Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
* Competitors scanning CT logs could infer new product/service offerings prior to their public release.<br />
<br />
===== Response =====<br />
<br />
* How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
* Wildcard certificates would suffice for new unreleased services even when being tested publicly. Those could be replaced with fully-qualified certificates (including EV if desired) when the service is announced.<br />
<br />
=== Logging Reveals Personally Identifiable Information ===<br />
<br />
Certificates used for S/MIME, code digning, and digital signatures contain various forms of Personally Identifiable Information (PII).<br />
<br />
===== Response =====<br />
<br />
Currently there are no applications that use and make trust decisions based on SCTs for these types of certificates, and so their consideration is out of scope for this discussion.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
===== Response =====<br />
<br />
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.<br />
<br />
Note that this is issue is not caused by redaction. A domain owner today might find an unredacted cert in a CT log that they don't recognize. They need some recourse too, so we don't need a new recourse mechanism/process just for redacted certs.<br />
<br />
=== Redaction Makes Clients More Complex ===<br />
<br />
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).<br />
<br />
=== Redaction Reduces Visibility and Accountability To The Public ===<br />
<br />
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns. Some CAs may simply choose to redact all certificates or redact by default.<br />
<br />
===== Response =====<br />
<br />
How much visibility and accountability would be lost by redaction? Redaction would hide a few domain labels in the CN and SANs, but every other DN field and every other extension would be present, allowing monitors to detect nearly all the BR-noncompliance they detect today.<br />
<br />
=== Redaction Reduces Visibility and Accountability to Domain Owners ===<br />
<br />
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.<br />
<br />
== Alternatives to Redaction ==<br />
<br />
A quick summary of suggestions people have made:<br />
<br />
* Disabling CT via browser policy in enterprises<br />
* Private roots<br />
* Wildcard certs<br />
* Log a name-constrained intermediate<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1184575CA/CT Redaction2017-11-21T15:01:58Z<p>Gerv: First version</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
===== Response =====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
===== Response =====<br />
<br />
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
===== Response =====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs. The WebPKI should only be used by modern, routinely-updated, security-patched devices in order for us to be able to keep our crypto and security agility.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
===== Response =====<br />
<br />
Why would someone DOS a random camera just because it was there?<br />
<br />
=== Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geolocation information is very sensitive. However, IoT manufacturers may want to put geolocation information into the certificate to make management of large numbers of devices easier. This leads to a desire for redaction so the attacker does not have both the server's addressable name and its location.<br />
<br />
=== Logging Reveals Commercially Sensitive Information ===<br />
<br />
Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
<br />
===== Response =====<br />
<br />
How? even if we grant for the sake of discussion that counting certificates is a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
===== Response =====<br />
<br />
Such concerns can be addressed by requiring each CA which uses redaction to have a public process whereby domain owners (who would need to be validated as such) can apply for information about redacted certificates for their domains, and request revocation if they wish. This would need to give the original Applicant for the certificates the right of objection and so could not be an instant or near-instant process.<br />
<br />
=== Redaction Makes Clients More Complex ===<br />
<br />
CT redaction would reduce internet security by increasing the complexity and bug surface of SCT-consuming clients (such as browsers and monitors) and SCT-producing systems (such as CAs).<br />
<br />
=== Redaction Reduces Visibility and Accountability To The Public ===<br />
<br />
CT redaction would reduce internet security due to a loss of visibility and accountability in the Web PKI. This would reduce the value of CT logs to the ecosystem. There is a strong likelihood of "over-redaction", where enterprises choose to redact certificates by default out of misplaced security concerns.<br />
<br />
=== Redaction Reduces Visibility and Accountability to Domain Owners ===<br />
<br />
There are a variety of situations in which domain owners may lose visibility what certificates are authorized for their own hostnames, either through domain transfers or acquisitions, or through governance issues in sufficiently large enterprises.<br />
<br />
== Alternatives to Redaction ==<br />
<br />
A quick summary of suggestions people have made:<br />
<br />
* Disabling CT via browser policy in enterprises<br />
* Private roots<br />
* Wildcard certs<br />
* Log a name-constrained intermediate<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1184565CA/CT Redaction2017-11-21T14:00:13Z<p>Gerv: More draftiness</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
==== Response ====<br />
<br />
In Chrome at least, which is currently the only browser that checks CT, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. The alternative, multiple otherwise-identical wildcard certs with different key pairs, would be hard to track.<br />
<br />
==== Response ====<br />
<br />
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought because hostnames leak in a number of other ways.<br />
<br />
As for multiple wildcard certs being hard to track, they would have different serial numbers, so automated provisioning software could tell them apart without difficulty.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
==== Response ====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1 and 1024-bit certs.<br />
<br />
=== Makes DOS Easier ===<br />
<br />
For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.<br />
<br />
==== Response ====<br />
<br />
Why would someone DOS a random camera just because it was there?<br />
<br />
=== CT Logging Reveals Geolocation Information ===<br />
<br />
For some IoT devices (cameras, sensors, etc.), geo-location information is very sensitive. If the certificate is logged with CT, there must be a mechanism like redaction to anonymize.<br />
<br />
==== Response ====<br />
<br />
It is not clear how CT logging would reveal geolocation information for the device using the certificate.<br />
<br />
=== Reveals Commercially Sensitive Information ===<br />
<br />
Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.<br />
<br />
==== Response ====<br />
<br />
How? If counting certificates is indeed a good way of determining how many devices are shipped, redaction won't change the number of certificates logged.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].<br />
<br />
== Alternatives ==<br />
<br />
* Disabling CT via browser policy<br />
* Private roots<br />
* Wildcard certs<br />
* CT-logging anyway</div>Gervhttps://wiki.mozilla.org/index.php?title=MOSS/Secure_Open_Source/Completed&diff=1184475MOSS/Secure Open Source/Completed2017-11-20T18:56:30Z<p>Gerv: Add CakePHP</p>
<hr />
<div>Secure Open Source has completed the following audits.<br />
<br />
==2017==<br />
<br />
===CakePHP===<br />
<br />
Dates: July - November 2017<br />
<br />
[https://cakephp.org/ CakePHP] is an open source web framework in PHP. The audit was performed by [https://www.nccgroup.trust/ NCC Group].<br />
<br />
The team found the following problems:<br />
<br />
* 1 High<br />
* 5 Medium<br />
* 9 Low<br />
* 5 Informational<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Cakephp-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1oJg5XqEZasm6RE-Ql7D7OUSiUhXFKApCPMwZxFaq0W8/edit# Fix and validation log]<br />
<br />
===chrony===<br />
<br />
Dates: June - September 2017<br />
<br />
[http://chrony.tuxfamily.org/ chrony] is an implementation of the Network Time Protocol, used either to set the time on a particular machine or act as an NTP server for other machines on the network. The audit was performed by [https://cure53.de/ Cure53], and kindly funded by [https://www.coreinfrastructure.org/ CII].<br />
<br />
The team found the following problems:<br />
<br />
* 2 Low<br />
<br />
Cure53 write: The overwhelmingly positive result of this security assignment performed by three Cure53 testers can be clearly inferred from a marginal number and low-risk nature of the findings amassed in this report. Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind. The software boasts sound design and is secure across all tested areas. It is quite safe to assume that untested software in the Chrony family is of a similarly exceptional quality. In general, the software proved to be well-structured and marked by the right abstractions at the appropriate locations. While the functional scope of the software is quite wide, the actual implementation is surprisingly elegant and of a minimal and just necessary complexity. In sum, the Chrony NTP software stands solid and can be seen as trustworthy.<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Chrony-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1HpGgX4r-81BWfPmas7L2WGfByJrVEIc4hAOXLEaaV_4/edit# Fix and validation log]<br />
<br />
===expat===<br />
<br />
Dates: February - July 2017<br />
<br />
[https://libexpat.github.io/ expat] is a stream-oriented XML parser library written in C. The audit was performed by [https://radicallyopensecurity.com/ Radically Open Security]. <br />
<br />
The team found the following problems:<br />
<br />
* 4 Medium<br />
* 3 Low<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Libexpat-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1DECt3DQYT_12oJwSFLCf-szGmM-l5JtZK7jwCujskqQ/edit# Fix and validation log]<br />
<br />
===GNU libmicrohttpd===<br />
<br />
Dates: January - May 2017<br />
<br />
[https://www.gnu.org/software/libmicrohttpd/ GNU libmicrohttpd] is a small embeddable HTTP 1.1 server written in C which supports TLS and IPv6. The audit was performed by [https://leastauthority.com/ Least Authority]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 2 Low<br />
* 1 Informational<br />
<br />
The documents are as follows:<br />
<br />
* [[Media:Libmicrohttpd.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1Pq5GQMZreKOPxcvtUwJI3jts2YjtVgCHM6MB4d_eBcg/edit# Fix and validation log]<br />
<br />
===oauth2-server===<br />
<br />
Dates: December 2016 - January 2017<br />
<br />
[https://github.com/thephpleague/oauth2-server oauth2-server] is a standards compliant implementation of an OAuth 2.0 authorization server written in PHP. The audit was performed by independent auditor Brian Carpenter. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Low<br />
<br />
There is no fix and validation log; the subsystem in which the issue was found is [https://github.com/thephpleague/oauth2-server/issues/684#issuecomment-261058564 being removed].<br />
<br />
* [[Media:Oauth2-server-report.pdf|Audit report]]<br />
<br />
===dovecot===<br />
<br />
Dates: October 2016 - January 2017<br />
<br />
[http://www.dovecot.org/ dovecot] is a POP and IMAP mailserver; it is used in 68% of IMAP server deployments worldwide. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 Low<br />
<br />
The Cure53 team were extremely impressed with the quality of the dovecot code. They wrote: "Despite much effort and thoroughly all-encompassing approach, the Cure53 testers only managed to assert the excellent security-standing of Dovecot. More specifically, only three minor security issues have been found in the codebase, thus translating to an exceptionally good outcome for Dovecot, and a true testament to the fact that keeping security promises is at the core of the Dovecot development and operations."<br />
<br />
* [[Media:Dovecot-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1rhzV_2Mw-7qbhXkGfyREzhxi51Rqwt2br8dZBNvI64U/edit# Fix and validation log]<br />
* [http://www.dovecot.fi/impressive-results-from-mozilla-sponsored-dovecot-security-audit/index.html Developer blog post]<br />
<br />
===ntp===<br />
<br />
Dates: December 2016 - March 2017<br />
<br />
[http://www.ntp.org/ ntp] is a implementation of the Network Time Protocol. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Critical<br />
* 2 High<br />
* 1 Medium<br />
* 8 Low<br />
* 2 Informational<br />
<br />
This audit was performed at the same time as an audit of ntpsec, which is based on a version of the ntp code.<br />
<br />
* [[Media:Ntp-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1nyD8j_Q-rhksUgJvIVog7xlID-ktyiuuve-VFVqWXOI/edit# Fix and validation log]<br />
* [http://support.ntp.org/bin/view/Main/SecurityNotice#March_2017_ntp_4_2_8p10_NTP_Secu Developer security announcement]<br />
<br />
===ntpsec===<br />
<br />
Dates: December 2016 - March 2017<br />
<br />
[http://www.ntpsec.org/ ntpsec] is a implementation of the Network Time Protocol, a fork of ntp. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 High<br />
* 1 Medium<br />
* 3 Low<br />
* 1 Informational<br />
<br />
This audit was performed at the same time as an audit of ntp, of which this codebase is a fork.<br />
<br />
* [[Media:Ntpsec-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1_Kps7NGnXUUuiJ8Q7dInryzuPz8qmrgNetAtxmJjOmU/edit# Fix and validation log]<br />
* [https://blog.ntpsec.org/2017/03/21/version-0-9-7.html Developer blog post]<br />
<br />
==2016==<br />
<br />
===PCRE===<br />
<br />
Dates: October 2015 - June 2016<br />
<br />
[http://www.pcre.org/ PCRE] (Perl-Compatible Regular Expressions) is a C library for implementing [https://en.wikipedia.org/wiki/Regular_expression regular expressions] in a codebase. It is used in various open source projects including Exim, Apache, PHP and KDE, as well as Apple Safari. We audited PCRE2, a newer version which is currently less commonly-used but which is expected to become increasingly common. The audit was performed by [https://cure53.de/ Cure53].<br />
<br />
The team found the following problems:<br />
<br />
* 1 Critical<br />
* 5 Medium<br />
* 20 Low<br />
* 3 Informational<br />
<br />
The critical vulnerability was a stack buffer overflow which could have led to arbitrary code execution when compiling untrusted regular expressions.<br />
<br />
* [[Media:Pcre-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1FEGCOGPWt9lVsuFsER9EmkkTU-LIH9ggtWSDhgvwr0Q/edit Fix and validation log]<br />
<br />
===libjpeg-turbo===<br />
<br />
Dates: November 2015 - June 2016<br />
<br />
[http://www.libjpeg-turbo.org/ libjpeg-turbo] is a fork of the libjpeg codebase which is particularly focussed on speed, and on compatibility with the most commonly-used standard profiles of JPEG. It is used by a number of open source projects, including Chrome, LibreOffice, Firefox and various flavours of VNC. The audit was performed by [https://cure53.de/ Cure53].<br />
<br />
The team found the following problems:<br />
<br />
* 1 High<br />
* 2 Medium<br />
* 2 Low<br />
<br />
The high vulnerability was an out-of-bounds read. It is unclear exactly how exploitable it was. However, more interesting were the two medium vulnerabilities, which were initially reported as DoS bugs in the libjpeg-turbo library but on further investigation were found to be issues with the JPEG standard itself. These issues were reproduced across multiple JPEG implementations, can be triggered by entirely legal JPEGs, and so are not easy to mitigate in any JPEG library itself. We have written up these issues in a separate report, along with our suggestions as to how applications using JPEG can mitigate them in their own code.<br />
<br />
* [[Media:Libjpeg-turbo-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1uxETuTL7_tVgE8EB49RhxxHuCyDIbcsS9fHNimBixm4/edit Fix and validation log]<br />
* [https://docs.google.com/document/d/17exDyGr2txYJ5Ntv4Q8B3MnLSvbcSfs5dje_xuDZPNA/edit Special report on issues in the JPEG standard]<br />
<br />
===phpMyAdmin===<br />
<br />
Dates: May - June 2016<br />
<br />
[https://www.phpmyadmin.net/ phpMyAdmin] is a web-based administration tool for MySQL databases. The audit was performed by [https://www.nccgroup.trust/ NCC Group]. <br />
<br />
The team found the following problems:<br />
<br />
* 3 Medium<br />
* 5 Low<br />
* 1 Informational<br />
<br />
NCC Group found no serious issues in this codebase.<br />
<br />
* [[Media:Phpmyadmin-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/1mrKwVKkcC22JeYIcXQeTNbq_kjTLlMIfHAxdffFMDXk/edit Fix and validation log]<br />
* [https://www.phpmyadmin.net/news/2016/6/13/phpmyadmin-project-successfully-completes-security-audit/ Developer blog post]<br />
<br />
===dnsmasq===<br />
<br />
Dates: May - August 2016<br />
<br />
[http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] is a lightweight implementation of DNS, DHCP, router advertisement and network boot. It is used in resource-constrained environments such as routers and firewalls (e.g. openWRT and DD-WRT), Android, and OpenStack. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 5 Low<br />
<br />
* [[Media:Dnsmasq-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/14y2kiXgB69fLBY0xuMeqc-YiZg4UDCw2xd4-mZspoP8/edit Fix and validation log]<br />
<br />
===zlib===<br />
<br />
Dates: July - September 2016<br />
<br />
[http://www.zlib.net/ zlib] is a compression library implementing the 'deflate' compression algorithm, used in countless applications. The audit was performed by [https://www.trailofbits.com/ Trail of Bits]. <br />
<br />
The team found the following problems:<br />
<br />
* 1 Medium<br />
* 4 Low<br />
<br />
* [[Media:Zlib-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit Fix and validation log]<br />
<br />
One of the Low severity issues is still under discussion between the zlib development team and the auditors, as they are working out how to resolve it without performance degradation.<br />
<br />
===curl===<br />
<br />
Dates: August - November 2016<br />
<br />
[https://curl.haxx.se/ curl] is a command-line application for transferring data, most usually over HTTP or HTTPS. The audit was performed by [https://cure53.de/ Cure53]. <br />
<br />
The team found the following problems:<br />
<br />
* 4 High<br />
* 5 Medium<br />
* 9 Low<br />
* 5 Informational<br />
<br />
8 of the vulnerabilities resulted in [https://curl.haxx.se/docs/security.html security advisories] being produced by the curl team on November 2nd, 2016.<br />
<br />
* [[Media:Curl-report.pdf|Audit report]]<br />
* [https://docs.google.com/document/d/17EvPM_LHJiOQPGC8cZ7nd2_7Hs7PIhrQqa7s9-pylm0/edit Fix and validation log]<br />
* [https://daniel.haxx.se/blog/2016/11/23/curl-security-audit/ Developer blog post]</div>Gervhttps://wiki.mozilla.org/index.php?title=File:Cakephp-report.pdf&diff=1184474File:Cakephp-report.pdf2017-11-20T18:55:30Z<p>Gerv: </p>
<hr />
<div></div>Gervhttps://wiki.mozilla.org/index.php?title=CA/CT_Redaction&diff=1184381CA/CT Redaction2017-11-17T21:59:13Z<p>Gerv: Not even a full draft yet</p>
<hr />
<div>{{draft}}<br />
<br />
This page is an attempt to summarise the arguments for and against the idea of redaction in CT.<br />
<br />
== For ==<br />
<br />
=== Enterprise Users Are Requesting It ===<br />
<br />
CAs report that enterprise customers are requesting this feature, for some of the reasons given in this document.<br />
<br />
==== Response ====<br />
<br />
In Chrome at least, enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA. I.e. they can turn off the CT requirement for particular roots.<br />
<br />
=== Concealing Network Topography ===<br />
<br />
Redaction means organizations can use publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging. Multiple wildcard certs with different key pairs would be hard to track.<br />
<br />
==== Response ====<br />
<br />
This is an argument for security through obscurity. And, in fact, will not succeed in achieving the obscurity sought.<br />
<br />
=== IoT Usage ===<br />
<br />
"Things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes. While private roots could be used, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn’t receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can’t be updated that we saw during SHA-1 deprecation problems. For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker. <br />
<br />
==== Response ====<br />
<br />
Chrome, at least, believes that the IoT should use private roots, or roots separate from the WebPKI, to avoid the sort of stagnation and legacy compatibility problems we have seen previously, e.g. with SHA-1.<br />
<br />
== Against ==<br />
<br />
=== Recourse is Hard ===<br />
<br />
It is difficult to build robust policies and procedures around what happens when a domain owner sees a redacted cert they didn't request. How can they get an unredacted copy of the original? What happens if the CA can't or won't provide it? What recourse does the domain owner have? More details on this can be found in [https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B76-100%5D this CT policy post].</div>Gervhttps://wiki.mozilla.org/index.php?title=CA&diff=1183409CA2017-11-03T09:39:40Z<p>Gerv: Move incident reporting link</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [http://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.5)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
<br />
== Lists of CAs and Certificates ==<br />
<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [http://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/BR_Self-Assessment|Baseline Requirements Self Assessment]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA:Root_Change_Process|Making Changes to Included Roots]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
* [https://github.com/awslabs/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
* [[CA:TestErrors|Common Test Errors]]<br />
<br />
== Information for Auditors ==<br />
<br />
* [[CA/Auditors|Information for Auditors]]<br />
<br />
== Information for the Public ==<br />
<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance Report an Incident] (be sure to click the "Security" checkbox during the filing process)<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[PSM:Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
* [https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's Certificate Explainer]<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
<br />
== Discussion Forums ==<br />
<br />
The following Mozilla public forums are relevant to CA evaluation and related issues. Each forum can be accessed either as a mailing list, over the web or as a newsgroup.<br />
<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] (MDSP). This forum is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. Among other things, it is the preferred forum for the public comment phase of CA evaluation. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto]. This forum is used for discussions of the [http://www.mozilla.org/projects/security/pki/nss/ NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [http://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security mozilla.dev.security]. This forum is used for discussions of Mozilla security issues in general.</div>Gervhttps://wiki.mozilla.org/index.php?title=Bugzilla:Meetings:2017-11-01&diff=1183368Bugzilla:Meetings:2017-11-012017-11-02T17:31:11Z<p>Gerv: Transfer notes</p>
<hr />
<div>* Appoint note taker and get them editing the Etherpad<br />
** Gerv<br />
* Dylan's plan for redirecting development - documentation, and how can others help?<br />
** Moving to the new branch is a big task<br />
** Dylan to make a plan for how to do it in his personal day tomorrow<br />
* Current release-critical challenges<br />
** See above<br />
* Switching www.bugzilla.org over to the GH pages version<br />
** justdave has a ticket open to get permission to update the DNS, which is required for the switch<br />
** https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 is an alternative plan if this doesn't work<br />
* Getting rid of infra - progress?<br />
** Justdave is updating the infra page on the wiki so we have a correct picture of what we have<br />
* Any other business</div>Gervhttps://wiki.mozilla.org/index.php?title=Bugzilla:Meetings&diff=1183367Bugzilla:Meetings2017-11-02T17:29:48Z<p>Gerv: Update for December</p>
<hr />
<div>==When and Where?==<br />
<br />
The Bugzilla community holds public meetings on the '''1st Wednesday''' of every month at 21:00 UK time. Everyone interested in being actively involved in the Bugzilla project can attend. Project leads and core developers will hopefully be there, but we welcome anyone interested in contributing, whether it be to development, testing, planning, the website, or anything else.<br />
<br />
The next meeting will be on Wednesday, [http://arewemeetingyet.com/London/2017-12-06/21:00/Bugzilla%20Meeting 2017-December-06, at 21:00 London time] (click for time in your timezone).<br />
<br />
You can participate in the following ways:<br />
<br />
* '''Mozilla Vidyo:''' in the 'Bugzilla' room; if you don't have a Mozilla LDAP login, use [https://v.mozilla.com/flex.html?roomdirect.html&key=kCjGNHjpT8sj this guest link] (requires install of proprietary client, sadly)<br />
* '''Air Mozilla:''' https://air.mozilla.org/search/?q=tag%3A+bugzilla (streaming; view/listen only)<br />
{{vidyoconf|8008}} <br />
<br />
If you want to both see and hear but don't want to use Vidyo you can connect on Air Mozilla, mute the speaker, and also dial in.<br />
<br />
Minutes will be taken on [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad] and transcribed to the wiki shortly after the meeting ends. There is also an IRC back channel on the Mozilla IRC server: irc.mozilla.org, channel #bugzilla.<br />
<br />
Video recordings of past meetings can be viewed at https://air.mozilla.org/search/?q=tag%3A+bugzilla<br />
<br />
==Agenda==<br />
<br />
# Appoint note taker and get them editing the [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad]<br />
# Dylan's plan for redirecting development - documentation, and how can others help?<br />
# Current release-critical challenges<br />
# Switching www.bugzilla.org over to the GH pages version<br />
# Getting rid of infra - progress?<br />
# Any other business<br />
<br />
== Summaries of previous meetings ==<br />
<br />
=== 2017 ===<br />
<br />
[[Bugzilla:Meetings:2017-11-01 | Wednesday, November 1st]] ([https://air.mozilla.org/bugzilla-project-meeting-20171108/ video])<br />
<br />
[[Bugzilla:Meetings:2017-10-04 | Wednesday, October 4th]] ([https://air.mozilla.org/bugzilla-project-meeting-20171004/ video])<br />
<br />
[[Bugzilla:Meetings:2017-09-06 | Wednesday, September 6th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170906/ video])<br />
<br />
Wednesday, August 2nd ''(cancelled due to lack of things to discuss - let's hack instead :-)''<br />
<br />
[[Bugzilla:Meetings:2017-07-05 | Wednesday, July 5th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170705/ video])<br />
<br />
[[Bugzilla:Meetings:2017-06-07 | Wednesday, June 7th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170607/ video])<br />
<br />
[[Bugzilla:Meetings:2017-05-24 | Wednesday, May 24th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170524/ video])<br />
<br />
[[Bugzilla:Meetings:2017-04-26 | Wednesday, April 26th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170426/ video])<br />
<br />
[[Bugzilla:Meetings:2017-03-22 | Wednesday, March 22nd]] ([https://air.mozilla.org/bugzilla-project-meeting-2017-03-22/ video])<br />
<br />
Wednesday, February 22nd ''(cancelled due to lack of attendance by key people - see developers mailing list for followup discussion)''<br />
<br />
Wednesday, January 25th ''(cancelled due to lack of attendance by key people)''<br />
<br />
=== 2016 ===<br />
[[Bugzilla:Meetings:2016-12-28 | Wednesday, December 28th]]<br />
<br />
Wednesday, November 23rd ''(cancelled due to US holidays)''<br />
<br />
[[Bugzilla:Meetings:2016-10-26 | Wednesday, October 26th]]<br />
<br />
[[Bugzilla:Meetings:2016-09-28 | Wednesday, September 28th]]<br />
<br />
[[Bugzilla:Meetings:2016-08-24 | Wednesday, August 24th]] -- notes missing<br />
<br />
[[Bugzilla:Meetings:2016-07-27 | Wednesday, July 27th]]<br />
<br />
Wednesday, June 22nd ''(cancelled)''<br />
<br />
[[Bugzilla:Meetings:2016-05-25 | Wednesday, May 25th]]<br />
<br />
[[Bugzilla:Meetings:2016-04-27 | Wednesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2016-03-23 | Wednesday, March 23rd]]<br />
<br />
[[Bugzilla:Meetings:2016-02-24 | Wednesday, February 24th]]<br />
<br />
[[Bugzilla:Meetings:2016-01-27 | Wednesday, January 27th]]<br />
<br />
=== 2015 ===<br />
[[Bugzilla:Meetings:2015-12-23 | Wednesday, December 23rd]]<br />
<br />
[[Bugzilla:Meetings:2015-11-25 | Wednesday, November 25th]]<br />
<br />
Wednesday, October 28th ''(skipped due to one attendee; meeting moves time next month)''<br />
<br />
Wednesday, September 23 ''(meeting happened but no notes taken)''<br />
<br />
[[Bugzilla:Meetings:2015-08-26 | Wednesday, August 26th]]<br />
<br />
[[Bugzilla:Meetings:2015-07-22 | Wednesday, July 22nd]]<br />
<br />
Wednesday, June 24th ''(skipped due to Mozilla all-hands)''<br />
<br />
[[Bugzilla:Meetings:2015-05-26 | Wednesday, May 26th]]<br />
<br />
Wednesday, April 22nd ''(skipped due to a single agenda item and no attendees)''<br />
<br />
[[Bugzilla:Meetings:2015-03-25 | Wednesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-02-25 | Wednesday, February 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-01-28 | Wednesday, January 28th]] ''(skipped due to lack of agenda items)''<br />
<br />
=== 2014 ===<br />
[[Bugzilla:Meetings:2014-11-26 | Wednesday, November 26th]]<br />
<br />
[[Bugzilla:Meetings:2014-10-22 | Wednesday, October 22nd]]<br />
<br />
[[Bugzilla:Meetings:2014-09-24 | Wednesday, September 24th]]<br />
<br />
[[Bugzilla:Meetings:2014-08-27 | Wednesday, August 27th]]<br />
<br />
[[Bugzilla:Meetings:2014-07-23 | Wednesday, July 23rd]]<br />
<br />
[[Bugzilla:Meetings:2014-06-25 | Wednesday, June 25th]]<br />
<br />
[[Bugzilla:Meetings:2014-05-28 | Wednesday, May 28th]]<br />
<br />
[[Bugzilla:Meetings:2014-04-23 | Wednesday, April 23rd]]<br />
<br />
=== 2013 ===<br />
[[Bugzilla:Meetings:2013-07-17 | Wednesday, July 17th]]<br />
<br />
=== 2012 ===<br />
[[Bugzilla:Meetings:2012-02-15 | Wednesday, February 15th]]<br />
<br />
=== 2011 ===<br />
<br />
[[Bugzilla:Meetings:2011-03-01 | Tuesday, March 1st]]<br />
<br />
=== 2010 ===<br />
<br />
[[Bugzilla:Meetings:2010-01-12 | Tuesday, January 12th]]<br />
<br />
[[Bugzilla:Meetings:2010-04-27 | Tuesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2010-10-05 | Tuesday, October 5th]]<br />
<br />
=== 2009 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-13 | Tuesday, January 13th]]<br />
<br />
[[Bugzilla:Meetings:2009-02-10 | Tuesday, February 10th]]<br />
<br />
[[Bugzilla:Meetings:2009-03-10 | Tuesday, March 10th]] (50th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2009-04-14 | Tuesday, April 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-07-14 | Tuesday, July 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-08-18 | Tuesday, August 18th]]<br />
<br />
[[Bugzilla:Meetings:2009-10-27 | Tuesday, October 27th]]<br />
<br />
=== 2008 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-15 | Tuesday, January 15th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-12 | Tuesday, February 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-26 | Tuesday, February 26th]]<br />
<br />
[[Bugzilla:Meetings:2008-03-25 | Tuesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2008-04-08 | Tuesday, April 8th]] (40th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2008-05-06 | Tuesday, May 6th]]<br />
<br />
[[Bugzilla:Meetings:2008-05-20 | Tuesday, May 20th]]<br />
<br />
[[Bugzilla:Meetings:2008-07-01 | Tuesday, July 1st]]<br />
<br />
[[Bugzilla:Meetings:2008-08-12 | Tuesday, August 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-09-16 | Tuesday, September 16th]]<br />
<br />
[[Bugzilla:Meetings:2008-10-21 | Tuesday, October 21st]]<br />
<br />
[[Bugzilla:Meetings:2008-11-18 | Tuesday, November 18th]]<br />
<br />
=== 2007 ===<br />
<br />
[[Bugzilla:Meetings:2007-01-09 | Tuesday, January 9th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-06 | Tuesday, February 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-27 | Tuesday, February 27th]]<br />
<br />
[[Bugzilla:Meetings:2007-03-20 | Tuesday, March 20th]]<br />
<br />
[[Bugzilla:Meetings:2007-05-15 | Tuesday, May 15th]]<br />
<br />
[[Bugzilla:Meetings:2007-06-12 | Tuesday, June 12th]]<br />
<br />
[[Bugzilla:Meetings:2007-07-10 | Tuesday, July 10th]] (30th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2007-08-07 | Tuesday, August 7th]]<br />
<br />
[[Bugzilla:Meetings:2007-09-04 | Tuesday, September 4th]]<br />
<br />
[[Bugzilla:Meetings:2007-10-02 | Tuesday, October 2nd]]<br />
<br />
[[Bugzilla:Meetings:2007-11-06 | Tuesday, November 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-12-04 | Tuesday, December 4th]]<br />
<br />
=== 2006 ===<br />
<br />
[[Bugzilla:Meetings:2006-02-02 | Thursday, February 2nd]] (our first IRC meeting!)<br />
<br />
[[Bugzilla:Meetings:2006-02-14 | Tuesday, February 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-02-28 | Tuesday, February 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-14 | Tuesday, March 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-28 | Tuesday, March 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-11 | Tuesday, April 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-25 | Tuesday, April 25th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-09 | Tuesday, May 9th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-23 | Tuesday, May 23rd]]<br />
<br />
[[Bugzilla:Meetings:2006-06-06 | Tuesday, June 6th]] (10th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-06-22 | Thursday, June 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-07-11 | Tuesday, July 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-07-24 | Monday, July 24th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-08 | Tuesday, August 8th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-22 | Tuesday, August 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-09-05 | Tuesday, September 5th]]<br />
<br />
[[Bugzilla:Meetings:2006-09-19 | Tuesday, September 19th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-03 | Tuesday, October 3rd]]<br />
<br />
[[Bugzilla:Meetings:2006-10-17 | Tuesday, October 17th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-31 | Tuesday, October 31st]] (20th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-11-14 | Tuesday, November 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-11-28 | Tuesday, November 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-12-12 | Tuesday, December 12th]]<br />
<br />
[http://www.bugzilla.jp/bzwiki/bz/Bugzilla:Meetings ja]<br />
<br />
[[category:Bugzilla|Meetings]]</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Upcoming_Distrust_Actions&diff=1182976CA/Upcoming Distrust Actions2017-10-27T15:53:26Z<p>Gerv: First version</p>
<hr />
<div>==Symantec==<br />
<br />
In line with a [https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ consensus proposal] agreed by a number of browser vendors, Firefox is implemented a gradual distrust of all roots controlled by the CA "Symantec". The dates and associated scopes for this distrust are as follows:<br />
<br />
* May 2018 (Firefox 60, currently [[RapidRelease/Calendar|due for release]] 2018-05-01): All certificates issued by Symantec roots before 2016-06-01.<br />
* October 2018 (Firefox 63, currently [[RapidRelease/Calendar|due for release]] 2018-10-16): All certificates issued by Symantec roots.<br />
<br />
You should make sure to migrate sites you control to newer or alternative certificates well before the dates given.<br />
<br />
<small>Certificates issued by the independently-operated Google and Apple sub-CAs are exempt, but unless you are Google or Apple you will not be using those.</small></div>Gervhttps://wiki.mozilla.org/index.php?title=Bugzilla:Meetings&diff=1182904Bugzilla:Meetings2017-10-26T08:53:20Z<p>Gerv: Add November</p>
<hr />
<div>==When and Where?==<br />
<br />
The Bugzilla community holds public meetings on the '''1st Wednesday''' of every month at 21:00 UK time. Everyone interested in being actively involved in the Bugzilla project can attend. Project leads and core developers will hopefully be there, but we welcome anyone interested in contributing, whether it be to development, testing, planning, the website, or anything else.<br />
<br />
The next meeting will be on Wednesday, [http://arewemeetingyet.com/London/2017-11-01/21:00/Bugzilla%20Meeting 2017-November-01, at 21:00 London time] (click for time in your timezone). Note that at this point, Europe has changed their clocks but the US has not and so the meeting is at a different time in the US this month.<br />
<br />
You can participate in the following ways:<br />
<br />
* '''Mozilla Vidyo:''' in the 'Bugzilla' room; if you don't have a Mozilla LDAP login, use [https://v.mozilla.com/flex.html?roomdirect.html&key=kCjGNHjpT8sj this guest link] (requires install of proprietary client, sadly)<br />
* '''Air Mozilla:''' https://air.mozilla.org/search/?q=tag%3A+bugzilla (streaming; view/listen only)<br />
{{vidyoconf|8008}} <br />
<br />
If you want to both see and hear but don't want to use Vidyo you can connect on Air Mozilla, mute the speaker, and also dial in.<br />
<br />
Minutes will be taken on [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad] and transcribed to the wiki shortly after the meeting ends. There is also an IRC back channel on the Mozilla IRC server: irc.mozilla.org, channel #bugzilla.<br />
<br />
Video recordings of past meetings can be viewed at https://air.mozilla.org/search/?q=tag%3A+bugzilla<br />
<br />
==Agenda==<br />
<br />
# Appoint note taker and get them editing the [https://public.etherpad-mozilla.org/p/bugzilla-meeting Etherpad]<br />
# Dylan's plan for redirecting development - documentation, and how can others help?<br />
# Current release-critical challenges<br />
# Switching www.bugzilla.org over to the GH pages version<br />
# Getting rid of infra - progress?<br />
# Any other business<br />
<br />
== Summaries of previous meetings ==<br />
<br />
=== 2017 ===<br />
<br />
[[Bugzilla:Meetings:2017-10-04 | Wednesday, October 4th]] ([https://air.mozilla.org/bugzilla-project-meeting-20171004/ video])<br />
<br />
[[Bugzilla:Meetings:2017-09-06 | Wednesday, September 6th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170906/ video])<br />
<br />
Wednesday, August 2nd ''(cancelled due to lack of things to discuss - let's hack instead :-)''<br />
<br />
[[Bugzilla:Meetings:2017-07-05 | Wednesday, July 5th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170705/ video])<br />
<br />
[[Bugzilla:Meetings:2017-06-07 | Wednesday, June 7th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170607/ video])<br />
<br />
[[Bugzilla:Meetings:2017-05-24 | Wednesday, May 24th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170524/ video])<br />
<br />
[[Bugzilla:Meetings:2017-04-26 | Wednesday, April 26th]] ([https://air.mozilla.org/bugzilla-project-meeting-20170426/ video])<br />
<br />
[[Bugzilla:Meetings:2017-03-22 | Wednesday, March 22nd]] ([https://air.mozilla.org/bugzilla-project-meeting-2017-03-22/ video])<br />
<br />
Wednesday, February 22nd ''(cancelled due to lack of attendance by key people - see developers mailing list for followup discussion)''<br />
<br />
Wednesday, January 25th ''(cancelled due to lack of attendance by key people)''<br />
<br />
=== 2016 ===<br />
[[Bugzilla:Meetings:2016-12-28 | Wednesday, December 28th]]<br />
<br />
Wednesday, November 23rd ''(cancelled due to US holidays)''<br />
<br />
[[Bugzilla:Meetings:2016-10-26 | Wednesday, October 26th]]<br />
<br />
[[Bugzilla:Meetings:2016-09-28 | Wednesday, September 28th]]<br />
<br />
[[Bugzilla:Meetings:2016-08-24 | Wednesday, August 24th]] -- notes missing<br />
<br />
[[Bugzilla:Meetings:2016-07-27 | Wednesday, July 27th]]<br />
<br />
Wednesday, June 22nd ''(cancelled)''<br />
<br />
[[Bugzilla:Meetings:2016-05-25 | Wednesday, May 25th]]<br />
<br />
[[Bugzilla:Meetings:2016-04-27 | Wednesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2016-03-23 | Wednesday, March 23rd]]<br />
<br />
[[Bugzilla:Meetings:2016-02-24 | Wednesday, February 24th]]<br />
<br />
[[Bugzilla:Meetings:2016-01-27 | Wednesday, January 27th]]<br />
<br />
=== 2015 ===<br />
[[Bugzilla:Meetings:2015-12-23 | Wednesday, December 23rd]]<br />
<br />
[[Bugzilla:Meetings:2015-11-25 | Wednesday, November 25th]]<br />
<br />
Wednesday, October 28th ''(skipped due to one attendee; meeting moves time next month)''<br />
<br />
Wednesday, September 23 ''(meeting happened but no notes taken)''<br />
<br />
[[Bugzilla:Meetings:2015-08-26 | Wednesday, August 26th]]<br />
<br />
[[Bugzilla:Meetings:2015-07-22 | Wednesday, July 22nd]]<br />
<br />
Wednesday, June 24th ''(skipped due to Mozilla all-hands)''<br />
<br />
[[Bugzilla:Meetings:2015-05-26 | Wednesday, May 26th]]<br />
<br />
Wednesday, April 22nd ''(skipped due to a single agenda item and no attendees)''<br />
<br />
[[Bugzilla:Meetings:2015-03-25 | Wednesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-02-25 | Wednesday, February 25th]]<br />
<br />
[[Bugzilla:Meetings:2015-01-28 | Wednesday, January 28th]] ''(skipped due to lack of agenda items)''<br />
<br />
=== 2014 ===<br />
[[Bugzilla:Meetings:2014-11-26 | Wednesday, November 26th]]<br />
<br />
[[Bugzilla:Meetings:2014-10-22 | Wednesday, October 22nd]]<br />
<br />
[[Bugzilla:Meetings:2014-09-24 | Wednesday, September 24th]]<br />
<br />
[[Bugzilla:Meetings:2014-08-27 | Wednesday, August 27th]]<br />
<br />
[[Bugzilla:Meetings:2014-07-23 | Wednesday, July 23rd]]<br />
<br />
[[Bugzilla:Meetings:2014-06-25 | Wednesday, June 25th]]<br />
<br />
[[Bugzilla:Meetings:2014-05-28 | Wednesday, May 28th]]<br />
<br />
[[Bugzilla:Meetings:2014-04-23 | Wednesday, April 23rd]]<br />
<br />
=== 2013 ===<br />
[[Bugzilla:Meetings:2013-07-17 | Wednesday, July 17th]]<br />
<br />
=== 2012 ===<br />
[[Bugzilla:Meetings:2012-02-15 | Wednesday, February 15th]]<br />
<br />
=== 2011 ===<br />
<br />
[[Bugzilla:Meetings:2011-03-01 | Tuesday, March 1st]]<br />
<br />
=== 2010 ===<br />
<br />
[[Bugzilla:Meetings:2010-01-12 | Tuesday, January 12th]]<br />
<br />
[[Bugzilla:Meetings:2010-04-27 | Tuesday, April 27th]]<br />
<br />
[[Bugzilla:Meetings:2010-10-05 | Tuesday, October 5th]]<br />
<br />
=== 2009 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-13 | Tuesday, January 13th]]<br />
<br />
[[Bugzilla:Meetings:2009-02-10 | Tuesday, February 10th]]<br />
<br />
[[Bugzilla:Meetings:2009-03-10 | Tuesday, March 10th]] (50th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2009-04-14 | Tuesday, April 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-07-14 | Tuesday, July 14th]]<br />
<br />
[[Bugzilla:Meetings:2009-08-18 | Tuesday, August 18th]]<br />
<br />
[[Bugzilla:Meetings:2009-10-27 | Tuesday, October 27th]]<br />
<br />
=== 2008 ===<br />
<br />
[[Bugzilla:Meetings:2008-01-15 | Tuesday, January 15th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-12 | Tuesday, February 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-02-26 | Tuesday, February 26th]]<br />
<br />
[[Bugzilla:Meetings:2008-03-25 | Tuesday, March 25th]]<br />
<br />
[[Bugzilla:Meetings:2008-04-08 | Tuesday, April 8th]] (40th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2008-05-06 | Tuesday, May 6th]]<br />
<br />
[[Bugzilla:Meetings:2008-05-20 | Tuesday, May 20th]]<br />
<br />
[[Bugzilla:Meetings:2008-07-01 | Tuesday, July 1st]]<br />
<br />
[[Bugzilla:Meetings:2008-08-12 | Tuesday, August 12th]]<br />
<br />
[[Bugzilla:Meetings:2008-09-16 | Tuesday, September 16th]]<br />
<br />
[[Bugzilla:Meetings:2008-10-21 | Tuesday, October 21st]]<br />
<br />
[[Bugzilla:Meetings:2008-11-18 | Tuesday, November 18th]]<br />
<br />
=== 2007 ===<br />
<br />
[[Bugzilla:Meetings:2007-01-09 | Tuesday, January 9th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-06 | Tuesday, February 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-02-27 | Tuesday, February 27th]]<br />
<br />
[[Bugzilla:Meetings:2007-03-20 | Tuesday, March 20th]]<br />
<br />
[[Bugzilla:Meetings:2007-05-15 | Tuesday, May 15th]]<br />
<br />
[[Bugzilla:Meetings:2007-06-12 | Tuesday, June 12th]]<br />
<br />
[[Bugzilla:Meetings:2007-07-10 | Tuesday, July 10th]] (30th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2007-08-07 | Tuesday, August 7th]]<br />
<br />
[[Bugzilla:Meetings:2007-09-04 | Tuesday, September 4th]]<br />
<br />
[[Bugzilla:Meetings:2007-10-02 | Tuesday, October 2nd]]<br />
<br />
[[Bugzilla:Meetings:2007-11-06 | Tuesday, November 6th]]<br />
<br />
[[Bugzilla:Meetings:2007-12-04 | Tuesday, December 4th]]<br />
<br />
=== 2006 ===<br />
<br />
[[Bugzilla:Meetings:2006-02-02 | Thursday, February 2nd]] (our first IRC meeting!)<br />
<br />
[[Bugzilla:Meetings:2006-02-14 | Tuesday, February 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-02-28 | Tuesday, February 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-14 | Tuesday, March 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-03-28 | Tuesday, March 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-11 | Tuesday, April 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-04-25 | Tuesday, April 25th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-09 | Tuesday, May 9th]]<br />
<br />
[[Bugzilla:Meetings:2006-05-23 | Tuesday, May 23rd]]<br />
<br />
[[Bugzilla:Meetings:2006-06-06 | Tuesday, June 6th]] (10th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-06-22 | Thursday, June 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-07-11 | Tuesday, July 11th]]<br />
<br />
[[Bugzilla:Meetings:2006-07-24 | Monday, July 24th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-08 | Tuesday, August 8th]]<br />
<br />
[[Bugzilla:Meetings:2006-08-22 | Tuesday, August 22nd]]<br />
<br />
[[Bugzilla:Meetings:2006-09-05 | Tuesday, September 5th]]<br />
<br />
[[Bugzilla:Meetings:2006-09-19 | Tuesday, September 19th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-03 | Tuesday, October 3rd]]<br />
<br />
[[Bugzilla:Meetings:2006-10-17 | Tuesday, October 17th]]<br />
<br />
[[Bugzilla:Meetings:2006-10-31 | Tuesday, October 31st]] (20th IRC meeting)<br />
<br />
[[Bugzilla:Meetings:2006-11-14 | Tuesday, November 14th]]<br />
<br />
[[Bugzilla:Meetings:2006-11-28 | Tuesday, November 28th]]<br />
<br />
[[Bugzilla:Meetings:2006-12-12 | Tuesday, December 12th]]<br />
<br />
[http://www.bugzilla.jp/bzwiki/bz/Bugzilla:Meetings ja]<br />
<br />
[[category:Bugzilla|Meetings]]</div>Gervhttps://wiki.mozilla.org/index.php?title=Bugzilla:Meetings:2017-10-04&diff=1182903Bugzilla:Meetings:2017-10-042017-10-26T08:52:27Z<p>Gerv: Created page with "* Note-taker is justdave * Dylan has a volunteer (Matt) helping with the bmo -> bugzilla6 migration code * user login IDs getting backed out, but bmo has a different implement..."</p>
<hr />
<div>* Note-taker is justdave<br />
* Dylan has a volunteer (Matt) helping with the bmo -> bugzilla6 migration code<br />
* user login IDs getting backed out, but bmo has a different implementation of that so the feature will still exist, and the migration code will migrate it.<br />
* multiple aliases is getting backed ou<br />
* Website was attempted to move from Mozilla hosting to Github+CloudFlare, we had a mishap with the SSL certificate which failed</div>Gervhttps://wiki.mozilla.org/index.php?title=User_talk:Klis.mateus&diff=1182654User talk:Klis.mateus2017-10-23T05:24:11Z<p>Gerv: Welcome!</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Gerv|Gerv]] ([[User talk:Gerv|talk]]) 22:24, 22 October 2017 (PDT)</div>Gervhttps://wiki.mozilla.org/index.php?title=User:Klis.mateus&diff=1182653User:Klis.mateus2017-10-23T05:24:05Z<p>Gerv: Creating user page for new user.</p>
<hr />
<div>Student of IT, finishing the licenciature ate UAL (Lisbon), looking on GeckoView for mobile to my final project using Xamarin and Flash</div>Gervhttps://wiki.mozilla.org/index.php?title=User_talk:Ankeshp03&diff=1182579User talk:Ankeshp032017-10-20T11:27:28Z<p>Gerv: Welcome!</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Gerv|Gerv]] ([[User talk:Gerv|talk]]) 04:27, 20 October 2017 (PDT)</div>Gervhttps://wiki.mozilla.org/index.php?title=User:Ankeshp03&diff=1182578User:Ankeshp032017-10-20T11:27:22Z<p>Gerv: Creating user page for new user.</p>
<hr />
<div>I want to learn how to find bugs and apply them in making firefox better. Also it will help me making better web apps.</div>Gervhttps://wiki.mozilla.org/index.php?title=User_talk:Ptrpov&diff=1182445User talk:Ptrpov2017-10-18T09:10:14Z<p>Gerv: Welcome!</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Gerv|Gerv]] ([[User talk:Gerv|talk]]) 02:10, 18 October 2017 (PDT)</div>Gervhttps://wiki.mozilla.org/index.php?title=User:Ptrpov&diff=1182444User:Ptrpov2017-10-18T09:10:08Z<p>Gerv: Creating user page for new user.</p>
<hr />
<div>I am a software engineer currently living in Steung Treng Province, Cambodia. My interests range from photography to basketball. I am also interested in swimming, design, and music.</div>Gervhttps://wiki.mozilla.org/index.php?title=User_talk:Pragmaticpolyglot&diff=1182293User talk:Pragmaticpolyglot2017-10-16T14:53:12Z<p>Gerv: Welcome!</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Gerv|Gerv]] ([[User talk:Gerv|talk]]) 07:53, 16 October 2017 (PDT)</div>Gervhttps://wiki.mozilla.org/index.php?title=User:Pragmaticpolyglot&diff=1182292User:Pragmaticpolyglot2017-10-16T14:53:06Z<p>Gerv: Creating user page for new user.</p>
<hr />
<div>http://linkedin.com/in/linkedin<br />
<br />
I've been a damned fool for not getting out of the damn ugly Chrome/Edge/IE box for so long. I was in love with Mozilla ideologically earlier in life, and now it's quite tangible. Moz has the hotness. Better than Google. Better than Baidu. Simply better - intended, implemented, and evolving.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Symantec_Issues&diff=1182106CA/Symantec Issues2017-10-11T10:47:01Z<p>Gerv: Add dates for Symantec</p>
<hr />
<div>Following the investigation documented below, a [https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ consensus proposal] was reached among multiple browser makers for a graduated distrust of Symantec roots. The dates in that proposal and how they apply to Mozilla's Root Program and Firefox are as follows:<br />
<br />
* December 1st, 2017: Symantec to implement "Managed CA" proposal<br />
* April 17th, 2018: Dis-trust of all Symantec certificates issued before 2016-06-01 (in practice, to be implemented in Firefox 60 on May 1st)<br />
* October 23rd, 2018: Final dis-trust of Symantec roots (in practice, to be implemented either in Firefox 63 on October 16th or Firefox 64 on November 27th)<br />
<br />
It is planned for Firefox 58 (January 16th, 2018) to also feature a console warning for Symantec certificates issued before 2016-06-01 to help sites notice they need to migrate.<br />
<br />
-----<br />
<br />
<br />
This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.<br />
<br />
The issues are in broadly chronological order by end date.<br />
<br />
==Issue B: Issuance of 1024-bit Certificate Expiring After Deadline (Dec 2013 - Jan 2014)==<br />
<br />
Symantec issued a cert to one of its customers that did not comply with at least one provision of both the CA/Browser Forum Baseline Requirements and Mozilla policy. It was a 1024-bit cert which expired after the end of 2013. Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. <br />
<br />
This cert was issued directly from the root. Symantec's [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x_vrJtv7A0Y write-up] points out that issuance from the root is permitted by [https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf BRs version 1.1.6], the version in force at the time, if 5 conditions are met, and they say they were met.<br />
<br />
This cert was backdated, but that is not a BR or Mozilla policy violation, as long as it was not done to evade a technical control. <br />
<br />
The cert had a short serial number. Entropy in the serial number is a SHOULD in BRs 1.1.6. 20 bits of entropy is a MUST in the Mozilla policy ([https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md version 2.2]), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time. I am told Microsoft removed the allowance for doing entropy in the Date field on 11th November 2013, so this was a violation of their policies. Symantec say that they got a verbal exception from Microsoft.<br />
<br />
Symantec did not request permission to issue in advance, they disclosed the issuance at least a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.<br />
<br />
The incident is recorded in {{bug|966350}}. <br />
<br />
===Symantec Response===<br />
<br />
Symantec self-reported this issuance to Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=966350 via Bugzilla] at the end of January 2014. Even though a [https://bugzilla.mozilla.org/show_bug.cgi?id=966350#c2 question was asked] about the BR Compliance OID that the new cert asserted, they did not comment on the bug beyond the initial report. Recently, Symantec have produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x_vrJtv7A0Y longer write-up] of the incident.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
Given that we did not query it at the time, we must accept that the BR criteria for direct issuance from the root were met. The Mozilla policy does not include the exceptions directly, but does reference BRs chapter 12, and so could be said to include the exceptions by reference. <br />
<br />
The issuance of a 1024-bit cert expiring after the deadline was both a BR and a Mozilla policy violation. Symantec say: "we did not engage the broader browser community due to the time pressure around the holiday." This seems like a weak excuse.<br />
<br />
The inclusion of a BR-compliant OID in a non-BR cert was disappointing, but can be accepted as an oversight.<br />
<br />
==Issue C: Unauthorized EV Issuance by RAs (January 2014 - February 2015)==<br />
<br />
Symantec have [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 stated] that their four RA partners (CrossCert, CertSuperior, Certisign and Certisur) had the technical ability to issue EV certificates despite not having EV audits for their operations. Symantec does not directly state so, but it is assumed that, given the lack of audits and the infrequency of occurrence (normal process was for them to pass EV request information on to Symantec) that the RAs were not authorized to make such issuances. However, three of those organizations did so on a number of occasions. Looking at the dates, this appears to have happened in two successive audit periods.<br />
<br />
===Symantec Response===<br />
<br />
Symantec says that they revalidated the EV information used to issue the certs once they discovered the issuance, and that the validations met the EV authentication guidelines. However, it seems that they did not implement technical measures to prevent further occurrences. Symantec discovered all this before the recent investigation, but did not disclose these events to Mozilla as misissuances at the time.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
EV issuance is a trusted privilege; Symantec should not have made it possible for organizations without the appropriate audits to issue EV, and they should have stopped them after it happened.<br />
<br />
==Issue D: Test Certificate Misissuance (April 2009 - September 2015)==<br />
<br />
Between 2009 and 2015, Symantec issued a large number of test certificates in their publicly trusted hierarchies. These contained domains that Symantec did not own or control, and for which domain validation was not performed. Some of these domains were unregistered, and others were owned by other organizations. Issuing test certificates for unregistered domains was not a BR violation before 3rd April 2014 (ballot 112), because they counted as Internal Server Names, but they continued the practice even after that date. The registered domains used included those belonging to Google and Opera Software. Given the numbers involved, this sort of test certificate issuance appears to have been common practice at Symantec. Some of the test certificates (including one for www.google.com) left Symantec's network because they were logged in CT. (Symantec claim that no certificates left their network; however, it's not clear how this can be true, and clarification is being sought.) However, Symantec personnel would have had access to the public and private keys of the certs. <br />
<br />
Some details of this incident are recorded in {{bug|1214321}}.<br />
<br />
===Symantec Response===<br />
<br />
It took quite a while for the full scale of the problem to emerge, and Symantec had to publish numerous updates to their "Final Report". Symantec released a number of documents relating to this - [https://bugzilla.mozilla.org/attachment.cgi?id=8852861 Final Report], [https://bugzilla.mozilla.org/attachment.cgi?id=8852862 Final Report v2], [https://bugzilla.mozilla.org/attachment.cgi?id=8852863 Final Report v3], [https://bugzilla.mozilla.org/attachment.cgi?id=8852864 list of certs containing owned domains], [[Media:TestCertificateIncidentReportUnregisteredv2.pdf|list of certs containing unregistered domains]], [https://www.symantec.com/page.jsp?id=test-certs-update further update]. They also issued a blog post, "[http://archive.is/Ro70U A Tough Day As Leaders]", which is no longer on their website but has been archived. It indicates that 3 employees were fired as a result of the misissuance. They posted another page with "[https://www.symantec.com/page.jsp?id=test-certs-update# complete investigation results]".<br />
<br />
In their report, Symantec wrote:<br />
<br />
<blockquote><br />
We have identified three root causes underlying the mis-issuance of these test certificates. First, we continued to issue internal test certificates to unregistered domains after the April 2014 change in the Baseline Requirements that removed authorization to do so. The overwhelming majority of the mis-issued test certificates fall into this first category. Second, certain Symantec Quality Assurance (QA) personnel had systems access, including the ability to use certain legacy tools, which enabled them to request a limited number of test certificates that were issued without review by authentication personnel. Third, authentication personnel did not consistently follow all verification steps when they received test certificate requests from their Symantec colleagues, or requested test certificates themselves. <br />
</blockquote><br />
<br />
Symantec took a number of remediation steps, as outlined in the report.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
Symantec later [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 revealed] that there was a further small (6 certificate) incident of this type in March 2016, "involving approved domains in a test account".<br />
<br />
==Issue E: Domain Validation Vulnerability (October 2015)==<br />
<br />
In October 2015, it was [https://www.agwa.name/blog/post/domain_validation_vulnerability_in_symantec_ca discovered] that Symantec's DV certificate products (e.g. RapidSSL, QuickSSL) had a flaw when parsing email address data from WHOIS, in that they did not parse + and = characters correctly. This meant that, in cases where the domain owner had used these characters, the address as parsed by Symantec was not the one the domain owner had inserted, and if other email addresses of a particular form could be registered at that domain, there was a possibility that an attacker could get a cert for the domain.<br />
<br />
===Symantec Response===<br />
<br />
Symantec fixed the issue within a week, audited their logs to make sure the flaw had not been abused, and issued a [https://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20160204_00 security advisory]. They have [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM said] they have no further comment.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
The set of circumstances which would have allowed this issue to be exploited (+ or = character in WHOIS, domain where arbitrary email address registration by 3rd parties is possible, necessary email address still available to register) are relatively rare, and Symantec fixed the issue quickly and performed appropriate remediation. Software has bugs. I do not consider this issue to be particularly severe.<br />
<br />
==Issue F: Symantec Audit Issues 2015 (December 2014 - November 2015)==<br />
<br />
Symantec's 2015 audit reports can be found in their [https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 legal repository]. Symantec's standard audit period is from December 1st to November 31st.<br />
<br />
The 2015 Baseline Requirements audits for Symantec's [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf GeoTrust roots] and their [https://www.symantec.com/content/en/us/about/media/repository/Symantec-Thawte-WTBR-2015.pdf Symantec and Thawte roots] run from December 1st, 2014 to November 30th, 2015. In those audits, the management assertions (and thereby the auditors) call out the following violations of the Baseline Requirements or Network Security Guidelines:<br />
<br />
# Issuance of Internal Server Names past the deadline date<br />
# Test certificates issued for domains Symantec did not own or control (see above)<br />
# No audit report, or invalid audit report, obtained for 3 of 5 external partner sub-CAs (GeoTrust only)<br />
# Failure to maintain physical security records for an appropriate period of time<br />
# Unauthorized employees with access to certificate issuance capability<br />
# Failure to review application and system logs<br />
<br />
The 2015 WebTrust for CAs audits for Symantec's [https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf Verisign and own-brand roots], their [https://www.symantec.com/content/en/us/about/media/repository/Thawte-WTCA-2015.pdf Thawte roots] and their [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTCA-2015.pdf GeoTrust roots] run from December 1st, 2014 to November 30th, 2015. In those audits, the management assertions (and thereby the auditors) call out the following violations:<br />
<br />
# Background checks not renewed for trusted personnel<br />
# Unauthorized employees with access to certificate issuance capability<br />
# Failure to maintain physical security records for an appropriate period of time (GeoTrust only)<br />
# Test certificates issued for domains Symantec did not own or control (see above)<br />
<br />
Of these, only the 'background checks' issue is not a repeat of an issue raised in the BR audits.<br />
<br />
The 2015 Extended Validation audits for Symantec's [https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTEV-2015.pdf Verisign and own-brand roots], their [https://www.symantec.com/content/en/us/about/media/repository/Thawte-WTEV-2015.pdf Thawte roots] and their [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTEV-2015.pdf GeoTrust roots] run from December 1st, 2014 to November 30th, 2015. In those audits, the management assertions (and thereby the auditors) call out the 'test certificates' and the 'physical security records' issues which are noted above.<br />
<br />
===Symantec Response===<br />
<br />
Each of the documents contains, in a following table, Symantec's comments on the qualifications and what they have done or are doing to remedy them. They have [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/8Z2uE1sGaO0 said] that they have no further comment.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
Mozilla did not object to these qualifications in Symantec's audits at the time the audit documentation was submitted to us. Because of this, it is not reasonable for us to take action based on the mere existence of these qualifications. They are listed here because they are one part of the general picture of Symantec's compliance or otherwise with the BRs.<br />
<br />
==Issue H: SHA-1 Issuance After Deadline (January 2016)==<br />
<br />
Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested ("enrolled") in 2015 but issued in 2016. Therefore, they passed through the point in the process where the presence of SHA-1 was checked for before the check was enabled.<br />
<br />
===Symantec Response===<br />
<br />
Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html self-reported this issue] to the CAB Forum public mailing list, and recently [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/ueV_q7Js4Sk stated] that they have no further comment. <br />
<br />
===Further Comments and Conclusion===<br />
<br />
Symantec were not the only CA to have similar issues with accidental SHA-1 issuance. This issue is listed here because it was not the only time it happened (see below).<br />
<br />
==Issue J: SHA-1 Issuance After Deadline, Again (February 2016)==<br />
<br />
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then seemed to claim that misissuance of a pre-certificate is not misissuance although they now acknowledge that it was. (The CT RFC states that issuance of a pre-certificate is considered equivalent to issuance of the certificate, and so Mozilla considers that pre-certificate misissuance is misissuance.)<br />
<br />
===Symantec Response===<br />
<br />
Their explanation for the incident was as follows:<br />
<br />
<blockquote><br />
Following discussions with the customer who initiated this order, we have identified a technical deficiency in our system that allowed for hash algorithm modifications by a subset of customers to existing enrollments in limited circumstances, and only when pending administrator review prior to issuance. We released a patch today to add this case to our system-wide SHA1 blocking mechanisms. In addition, as an added precaution, we are evaluating an update to actively change any SHA1 orders encountered in our system to SHA256.<br />
</blockquote><br />
<br />
They have also produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Jj9ZpMs-pWM more detailed explanation] of the events, including details of the remediation steps taken.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem, or to put in place SHA-1 blocks in enough places to catch this.<br />
<br />
==Issue L: Cross-Signing the US Federal Bridge (2009 - July 2016)==<br />
<br />
The US Government has an [https://fpki-graph.fpki-lab.gov extremely complicated] PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies. During the period in question, it had a number of non-audited subordinate CAs.<br />
<br />
Since 2009, Symantec has regularly had a valid cross-sign for one or both of "[https://crt.sh/?caid=1324 Federal Bridge CA]" and "[https://crt.sh/?caid=1410 Federal Bridge CA 2013]", which are both part of the FPKI, thereby making (as far as I can tell) all certificates in the FPKI be publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the FPKI, including any BR violations. The intermediate CA certificate(s) concerned were not disclosed in the CCADB, as Mozilla practice at the time required. This was [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ reported in m.d.s.policy].<br />
<br />
Symantec is not the only CA to have done this; IdenTrust [https://crt.sh/?id=9114292 also did it on multiple occasions] from 2011-01-14 onwards. I don't believe there are any unexpired unrevoked (by OneCRL) links between the FPKI and the Mozilla trust store any more, via any CA. <br />
<br />
Symantec appear not to have been aware that this would lead to certificates from the FPKI being trusted in browsers until around the time it was [https://github.com/18F/fpki-testing/issues/1 drawn to their attention] by Eric Mill in February 2016.<br />
<br />
===Symantec Response===<br />
<br />
After this was drawn to their attention, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did not revoke] the cross-sign certificate under discussion, instead allowing it to expire. (By contrast, Identrust revoked their similar cross-signature in mid-late February, a week or so after being notified of the issue by Mozilla.)<br />
<br />
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/KKqGmzQIOno claim] that the problem is with browsers not processing certificate policy extensions which are used within the FPKI. When they realised the problem, they negotiated with the FPKI to allow the relevant cross-cert to expire rather than renewing it.<br />
<br />
===Further Comments and Conclusions===<br />
<br />
Symantec [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 state] that they were aware of the issues with this cross-signing since 2014 and were investigating whether it was actually required. It would seem it took two years to figure that out, and at no time was Mozilla informed about the fact that Symantec was enabling public trust for the entire Federal PKI.<br />
<br />
While technical controls within the FPKI may have prevented it, Symantec had no way of knowing or controlling whether the FPKI was issuing EV certificates using Symantec's OID.<br />
<br />
==Issue N: Premature Manual Signing Using SHA-1 (July 2016)==<br />
<br />
Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they accidentally issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. This was supposedly a manual process but it seems like the relevant instructions were either deficient (in that they specified too many steps) or not followed.<br />
<br />
===Symantec Response===<br />
<br />
Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ self-reported] this issue to Mozilla. Their remediation was to revoke all of those certificates, and issue new ones after permission was granted.<br />
<br />
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UnTJ1AfCT7U state]:<br />
<br />
<blockquote><br />
This matter represents the first time any CA attempted to follow the exception process which was developed over the course of weeks, beginning at the Bilbao CABF face-to-face meeting in May 2016, and with the input of our partners. Google initially proposed this exception process, which was later modified following input from other CABF members. Our internal process did not clearly specify to our PKI Operations team to stop at the point of TBS creation, which subsequently resulted in the creation of signed certificates instead of TBS Certificates. Importantly, our audit process promptly identified the error, and Symantec never released the certificates. We also promptly improved our internal process.<br />
</blockquote><br />
<br />
===Further Comments and Conclusion===<br />
<br />
Is is true that this is a new process, and that stopping the issuance process at the point of creating TBSCertificates is unusual. While perhaps embarrassing, the risk here seems minimal given that near-identical certificates were issued and distributed a week later.<br />
<br />
==Issue P: UniCredit Sub CA Failing To Follow BRs (March - October 2016)==<br />
<br />
Symantec issued an unconstrained sub-CA to a company called UniCredit as part of their GeoRoot program (see also Issue V). This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this. Symantec [https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 claimed], in response to the CA Communication of March 2016, that they had disclosed to Mozilla all their intermediate CAs along with audits, but this was not true in the case of UniCredit. The [http://ca.unicredit.eu/CPS/cps.html UniCredit CPS] was also BR-noncompliant, in that it said that SANs were optional. <br />
<br />
This incident is recorded in {{bug|1261919}}.<br />
<br />
===Symantec Response===<br />
<br />
Symantec's initial response was to get UniCredit to put in place controls to fix the violations found, and to review and replace any affected certificates. However, they continued to be without an audit. Symantec eventually asked them for one, and when they were unable to produce (presumably, pass) one, ordered them to stop issuing. However they continued, in violation of that agreement. Symantec then finally revoked their intermediate.<br />
<br />
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/CkMpJbuTGOI admit] that the omission of UniCredit from their CA Communication response was an oversight. They further state:<br />
<br />
<blockquote><br />
We worked with UniCredit over a long period of time to enforce their compliance with audit requirements. In July 2016, we received an assessment that did not meet WebTrust audit standards. We then took action, helping UniCredit transition to a managed PKI solution for their certificate needs that did not require an audit. In parallel, we notified them of termination of their subordinate CA.<br />
<br />
Because our customers are our top priority, we attempted to minimize business disruption while they transitioned by permitting UniCredit to operate only its CRL service until November 30, 2016, at which point we would revoke the UniCredit subordinate CA. In October 2016, UniCredit issued one new certificate in violation of the terms of that transition plan. Following that, Symantec promptly revoked the UniCredit subordinate CA on October 18, 2016.<br />
</blockquote><br />
<br />
===Further Comments and Conclusion===<br />
<br />
There is doubt as to whether Symantec's indulgence of UniCredit's continued incompetence is within the letter and/or spirit of the BRs and root policy. Firstly, there is the long timeline over which UniCredit was out of compliance. But even when Symantec took action, Baseline Requirements 1.4.4, Section 4.9.1.2, item 8 states that Symantec should have revoked the intermediate immediately upon removing their right to issue, unless Symantec took over the CRL and OCSP duties, which they did not.<br />
<br />
This section of the BRs is presumably there to prevent an incompetent or untrustworthy ex-sub-CA owner from continuing to add risk to the WebPKI once their incompetence has been acknowledged.<br />
<br />
==Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)==<br />
<br />
The Baseline Requirements section 8.6 says that CAs SHOULD provide audits within 90 days of the end of the audit period; this SHOULD was not followed by Symantec for both the 2014/15 and 2015/16 audit cycles. However, Symantec is not the only CA which regularly supplies its audits late.<br />
<br />
Symantec's 2016 audit reports can be found in their [https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 legal repository]. Symantec's standard audit period is from December 1st to November 31st. However, for 2016, they have split the audits into two roughly six-month periods, and had separate audit opinions issued for each.<br />
<br />
As detailed in their [https://www.symantec.com/content/en/us/about/media/repository/Cover_Letter_for_WebTrust_Audit.pdf covering letter], the audits for the second period, June 16th to November 30th 2016, are mostly unqualified. The BR audits have a total of five qualifications, two of which relate to previously disclosed incidents which are not of concern, and three other qualifications which seem to be only of minor concern.<br />
<br />
The audits for the first period contain many or all of the same issues as the 2015 audits (Issue F). One can surmise that Symantec chose to split the audits in order that they would not have a qualified audit covering the entirety of 2016. This raised questions about how long the issues which led to these qualifications persisted.<br />
<br />
None of the audits contain any qualification related to the audit status of the GeoRoot or RA program partners.<br />
<br />
===Symantec Response===<br />
<br />
Each of the documents contains, in a following table, Symantec's comments on the qualifications and what they have done or are doing to remedy them.<br />
<br />
Symantec recently [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0dOt9JDsE0k stated]: "In our 2014-2015 audits, certain issues were identified that we promptly took action on, including addressing the test certificate incident. We continued these efforts until the Point in Time audit was conducted."<br />
<br />
When asked about the amount of time taken to remediate, Symantec's [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 response] stated that the issues were discovered late in 2015 or early in 2016, and some took several months to remediate if you include the need for revalidations and HR team reorganizations, which is why they persisted into the 2016 audit period. Specifically:<br />
<br />
* Test certs to registered domains: Discovered and fixed in Sep 2015, but "while inappropriate use of registered domains for testing stopped during the course of our 2014-2015 audits, we did not complete the ID and revocation of all certificates until Mar 2016, and so the finding remained in our first-half Dec 1, 2015-Jun 15, 2016 audits."<br />
* Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016."<br />
* Unauthorized employees with access to certificate issuance capability: discovered in September 2015, last problem of this type remediated in June 2016 after extensive security review. <br />
* Failure to maintain physical security records for 7 years: discovered and fixed in January 2016.<br />
* Failure to review application and system logs: discovered and fixed in January 2016.<br />
* The failure to refresh background checks every 5 years: discovered in February 2016, fixed in June 2016 (required an internal reorganization).<br />
<br />
In regard to the lack of qualifications related to GeoRoot and the RA program, Symantec said: "We acknowledge there were deficiencies in audits for both the GeoRoot and RA programs. The plan for the GeoRoot deficiencies was communicated in the cover letter accompanying our Point in Time audit (see issue V) and for the RA program, in the cover letter to browsers with our 2015-2016 audits."<br />
<br />
===Additional Comments and Conclusion===<br />
<br />
It is noteworthy that even if third party audits are qualified, that does not lead to a qualification on Symantec's main audit.<br />
<br />
==STRUCK: <strike>Issue R: Insecure Issuance API (2013 or earlier - November 2016)</strike>==<br />
<br />
According to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 a report], it is alleged that for several years Symantec operated an issuance API which was insufficiently secure, such that URL parameter substitution attacks would allow one customer to view, reissue, revoke and otherwise control certificates (including non-server certs) belonging to another customer. It is further alleged that, when made aware of these issues, Symantec took a very long time to fix them, and they may not have been fully fixed at the time Symantec terminated its RA program entirely.<br />
<br />
===Symantec Response===<br />
<br />
Symantec commented [http://www.csoonline.com/article/3184897/security/api-flaws-said-to-have-left-symantec-ssl-certificates-vulnerable-to-compromise.html to the press]:<br />
<br />
<blockquote><br />
"We have looked into Chris Byrne’s research claim and could not recreate the problem. We would welcome the proof of concept from the original research in 2015 as well as the most recent research. In addition, we are unaware of any real-world scenario of harm or evidence of the problem. However, we can confirm that no private keys were accessed, as that is not technically feasible. <br />
</blockquote><br />
<br />
In addition, Tarah from Symantec has posted a [https://groups.google.com/d/msg/mozilla.dev.security.policy/CEww8w9q2zE/KvF2fU8ZCgAJ detailed comment] which suggests that the issue is or was substantially less serious than the initial write-up made it sound. They have also made [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Wm2MrLGLjSI additional comment] in response to this document.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
At the moment, there is no compelling evidence that Symantec's account of events is incorrect. If their account of events is correct then I don't see a problem here. For better or worse, the sending of emails with somewhat privileged access URLs in them is common practice in this and other industries.<br />
<br />
==Issue T: CrossCert Misissuances (January 2010 - January 2017)==<br />
<br />
For several years, Symantec operated an RA (Registration Authority) program. The companies in this program had independent authority to issue certificates under Symantec intermediates, and those certificates were not specifically marked to say that a particular RA had issued them instead of Symantec directly. This by itself is not against any existing policy.<br />
<br />
However, In January 2017, [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ it was discovered] that a small number of certificates had been misissued using Symantec intermediates by an RA called CrossCert in Korea. The investigation of these matters led to increasing further discoveries of misissuances (totalling 127 confirmed cases) and potential misissuances by CrossCert, together with poor CA practice by them and other companies in Symantec's RA network. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered.<br />
<br />
Types of misissuance by CrossCert:<br />
<br />
* Use of unvalidated domain names not owned by either Symantec or CrossCert<br />
* Typos in domain names<br />
* Bogus ST, L, O and OU fields: numbers, "test" or similar<br />
* Violation of CPS (use of non-KR country code)<br />
<br />
Some of these misissuance were caused by employees of CrossCert overriding compliance flags in Symantec's issuance system. Symantec had no process in place to review the logs of overridden flags. For some of the certs, they contained domains neither Symantec nor CrossCert own or control, and CrossCert did not complete the appropriate domain validations for them.<br />
<br />
Lastly, it later emerged that for a number of Certs, CrossCert has incompletely logged records of their telephone validations and so it could not be confirmed that the validation work had been performed correctly.<br />
<br />
This incident is recorded in {{bug|1334377}}.<br />
<br />
===Symantec Response===<br />
<br />
Symantec made a number of comments on this issue - [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 0], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 1], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 2], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 3], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8843448 4].<br />
<br />
The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement". However, Symantec did not revoke all the certificates.<br />
<br />
Instead, Symantec decided to shut down the RA program entirely and re-assess every certificate issued under it. Symantec committed to revalidating all of the CrossCert-issued certificates (10,000+) and any of the 20,000+ certificates issued by their other RAs if deficient validation was discovered. However, the determination of deficient validation (in cases other than CrossCert) was made based on the RAs own logs of activity, which may themselves be suspect given some of the audit deficiencies found at these RAs. <br />
<br />
Symantec has produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/dVMxrUVygS0 further, long account] of the situation. It confirms that, while there were multiple systems designed to teach the RAs what to do, the only system which checked that they were actually doing it (and which Symantec paid attention to) were the WebTrust audits. They disagree that full revocation of all certs is a proportionate response.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
Symantec's reaction to the discovery of these problems was, to mind, swift and comprehensive - the entire RA program was shut down in fairly short order. <br />
<br />
Their case is that WebTrust audit monitoring should have been sufficient, but that they were let down by their auditor, who failed to notice some of the problems, or in other cases it just so happened that the issues were either a long time ago or too recent to be caught by audit. This case is undermined by Issue W - CrossCert and many of the other RA partners had significantly deficient audits and/or audits with serious qualifications.<br />
<br />
I conclude that the reason that the situation at CrossCert was not replicated elsewhere was a matter of luck, and that Symantec's monitoring regime for its RA partners - who had full powers of issuance in the WebPKI - was not sufficiently robust.<br />
<br />
==Issue V: GeoRoot Program Audit Issues (2013 or earlier - January 2017)==<br />
<br />
Symantec runs a program called GeoRoot, where intermediate CAs have been created for the sole use and independent operation by specific customers at premises under their control. Some of these customers appear to have had a history of poor compliance with the BRs and other audit requirements.<br />
<br />
Over multiple years ([https://www.symantec.com/content/en/us/about/media/repository/symantec-webtrust-audit-report.pdf 2013-12-01 to 2014-11-30], [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf 2014-12-01 to 2015-11-30]), Symantec's "GeoTrust" audits were qualified to say that they did not have proper audit information for some of these GeoRoot customers. This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known.<br />
<br />
There are five customers mentioned in the audits, and Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70 say] they are [https://crt.sh/?sha1=924b357fc7b9d8c9d26e41d4af4dc6c4babe90e5 Intel], [https://crt.sh/?id=33549 Aetna], [https://crt.sh/?CN=UniCredit+Subordinate+External UniCredit], [https://crt.sh/?CN=Google+Internet+Authority+G2 Google] and [https://crt.sh/?CN=Apple+IST+CA%25 Apple]. They also say:<br />
<br />
<blockquote><br />
Separately, Symantec operates two subordinate CAs solely for NTT DoCoMo in an enterprise PKI application. These subordinate CAs had been considered part of the "GeoRoot" program as well, and we had therefore excluded them (similar to the above externally operated ones) from the list of Symantec CAs in our audits. After reviewing our approach, our compliance team determined that they should be included going forward. As such, for the 2016-2017 Period in Time, these subordinate CAs are included in the GeoTrust WebTrust for CA and BR audits.<br />
</blockquote><br />
<br />
===Symantec Response===<br />
<br />
* Symantec state: "Intel's subordinate CA, which expired in 2016, was not subject to audits either contractually or by previous agreements with both Mozilla and Microsoft given its limited use." This is true; the CA is mothballed and got out of storage only once a quarter to issue a CRL. Symantec agreed privately with Mozilla that audits were not necessary for a CA in such a state.<br />
<br />
* Symantec state: "Symantec provided the letter quoted below to Google, Mozilla, Microsoft, and Apple when we shared the Point in Time Audits on September 6, 2016 to specifically address the GeoRoot audit status and remediation plan. That cover letter outlined the plan to wind down the Aetna and UniCredit subordinate CAs." This is true, although Aetna and UniCredit are not mentioned by name in the letter.<br />
<br />
Symantec have also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 stated] that, as of April 21st, 2017, the "Intel, Aetna, and Unicredit CAs have all expired or been revoked." This leaves Google and Apple as the only participants in the GeoRoot program. They also say that: "We agree that getting audits for Aetna and Unicredit took too long. After many discussions, requests, and delays, they finally produced the reports that they did. This experience informed our decision to transition them to alternative solutions."<br />
<br />
On the subject of NTT DoCoMo, Symantec [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 write]: "All authentication performed for the NTT CA’s has been completed by Symantec personnel. The authentication applications used have historically been fully within the scope of our WTCA/WTBR audits. The infrastructure on which this specific enterprise PKI application and those CAs operate was not covered under audit until these CAs were added to the 2015-2016 audits."<br />
<br />
===Further Comments and Conclusion===<br />
<br />
It seems that the NTT DoCoMo infrastructure did fall through the cracks audit-wise until 2015-2016.<br />
<br />
Given the power which those organizations held, Symantec did not pursue Aetna and UniCredit for proper audits and appropriate compliance with sufficient alacrity (on UniCredit, see Issue P). However, to a degree, Symantec did keep Mozilla somewhat informed of what was going on, and Mozilla made no comment. It is our understanding that at least one other root program was applying more pressure to remediate this situation than Mozilla was.<br />
<br />
==Issue W: RA Program Audit Issues (2013 or earlier - January 2017)==<br />
<br />
Symantec's RA program had four participating companies - CrossCert, Certisign, Certsuperior, and Certisur.<br />
<br />
[https://bug1334377.bmoattachments.org/attachment.cgi?id=8831930 Certsuperior's audit] is particularly dreadful: <br />
<br />
* There was no legible CPS;<br />
* inadequately-trained personnel were doing issuance;<br />
* the network was an insecure mess; and<br />
* non-trusted staff had access to issuance.<br />
<br />
Prior to 2016, Certsuperior was providing WebTrust audits from an unlicensed auditor.<br />
<br />
[https://cert.webtrust.org/SealFile?seal=2168&file=pdf CrossCert's audit] does not list or cover the full number of Symantec roots under which they had issuance capability. Symantec did not notice this mismatch until their recent investigations, when they discovered that CrossCert had the scope of the audit reduced for cost reasons.<br />
<br />
[https://cert.webtrust.org/SealFile?seal=2067&file=pdf Certisur's audit] is only a WebTrust for CAs audits - they do not appear to have a Baseline Requirements audit. According to Symantec's records, this has been true ever since BR audits became required. Mozilla policy requires "CA operations and issuance of certificates to be used for SSL-enabled servers" to conform to the Baseline Requirements. As Symantec has stated that audit was their only mechanism for monitoring their RAs, they can have had no assurance that RAs without a BR audit were actually following the BRs.<br />
<br />
[https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929 Certisign's audits] appear to be in order, although their 2016 audit is past due.<br />
<br />
===Symantec Response===<br />
<br />
Symantec required the issues at CertSuperior to be fixed and a 90-day action plan was executed to fix them. However, until they decided to shut down the RA program, no certificates issued during the period of suspect operations were checked to see if the poor practice had caused misissuance. They have requested that their next audit include both WebTrust for CAs and WebTrust Baseline.<br />
<br />
Symantec appears to have taken no action to deal with that fact that Certisur did not have a BR audit until recently, when they have requested that their next audit include both WebTrust for CAs and WebTrust Baseline.<br />
<br />
Symantec did not notice that CrossCert's audits did not cover all the relevant roots until they did the RA investigation in early 2017.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
Despite the clear warning signs shown on the Certsuperior audit, Symantec did not put in place any monitoring of their RAs, other than audit, to check that they were correctly performing the tasks delegated to them under the BRs. (There were some - overridable - technical checks on certificate issuance.)<br />
<br />
Symantec's compliance department [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70 did not notice] many or any of these audit scope problems until 2016 - in particular those from Certisur and CrossCert.<br />
<br />
Symantec have asserted that their oversight of these RA partners was primarily based on reviewing audits. However, the audits had a number of irregularities of various kinds, including being of the wrong type and so not covering the BRs at all, or not covering all issuance, which were not noted until recently. This claim of oversight therefore rings fairly hollow.<br />
<br />
==STRUCK: <strike>Issue X: Incomplete RA Program Remediation (February - March 2017)</strike>==<br />
<br />
At the time Symantec shut down their RA program, they had four RAs - CrossCert, Certisign, Certsuperior, and Certisur. Symantec committed to revalidating all certificates issued by those RAs. Independent of the rightness or otherwise of this course of action, it should have been applied consistently. However, the program seems to have previously had additional RAs, and Symantec has as yet taken no action to revalidate the certificates that they issued, despite some still being valid. <br />
<br />
Those RAs include at least E-Sign, for which we have found audits from [https://cert.webtrust.org/SealFile?seal=1873&file=pdf March - June 2014], [https://cert.webtrust.org/SealFile?seal=1931&file=pdf April - July 2015] and [https://cert.webtrust.org/SealFile?seal=2180&file=pdf July - September 2016]. This party does not appear to have an unbroken series of audits; it is unclear what that means.<br />
<br />
Another possible RA is MSC TrustGate, which appears to have been operating as a sub-CA based on the scope of [https://cert.webtrust.org/SealFile?seal=2127&file=pdf their audit]. However this audit, like those for some other Symantec RAs, is only to the WebTrust for CAs criteria and does not cover the Baseline Requirements. The WebTrust audit criteria require that such a CA has a BR audit.<br />
<br />
===Symantec Response===<br />
<br />
Symantec [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/B3Pcag-afJI state]:<br />
<br />
<blockquote><br />
The only Symantec RAs capable of authorizing and issuing publicly trusted SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur. Symantec continues to maintain a partner program for non-TLS certificates. E-Sign SA and MSC Trustgate are amongst these partners.<br />
</blockquote><br />
<br />
Symantec agree that the audits are not clear about what specific CAs are used for, but assert that these organizations are not in a position to issue SSL/TLS certificates.<br />
<br />
===Further Comments and Conclusion===<br />
<br />
In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.<br />
<br />
==Issue Y: Under-audited or Unaudited Unconstrained Intermediates (December 2015 - April 2017)==<br />
<br />
Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority (which is EV-enabled), have audit and control problems:<br />
<br />
* [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2]<br />
* [https://crt.sh/?Identity=%25&iCAID=12352&exclude=expired Symantec Class 3 SSP Intermediate CA - G3]<br />
<br />
Both intermediates are disclosed in Salesforce, and both have 15 or so also-disclosed sub-CAs which seem to be specific to particular companies. The audit associated with both of them in Salesforce is [https://www.symantec.com/content/en/us/about/media/repository/symantec_nfssp_wtca_5_13_2016.pdf this one] from May 2016, i.e. from Symantec's 2015 set of audits (i.e. the set before the current one), but that audit document does not list the intermediate CAs that it covers. Symantec has produced a [https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf more recent audit] but not yet updated Salesforce. This one does list the intermediate CAs covered. However, like that from the previous year, this is a WebTrust for CAs audit, and does not include a BR audit.<br />
<br />
These intermediates appear to be related to the US Federal Bridge PKI (see Issue L) As far as we can tell, they are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers. Mozilla policy is based on capability, not intent - if a sub-CA is capable of issuing SSL certs we trust, it must be appropriately constrained or audited. These intermediates have deficient audits and, as far as we can tell, sub-CAs of them are effectively controlled by entities without any audits at all. Specifically:<br />
<br />
* The CP/CPS does not state adherence to the Baseline Requirements.<br />
* The audit is only a WebTrust for CAs audit, not a BR audit.<br />
* A number of sub-CAs seem excluded from even the scope of that audit, as they are not listed in it: [https://crt.sh/?id=19602740 1], [https://crt.sh/?id=19602709 2], [https://crt.sh/?id=19602733 3], [https://crt.sh/?id=19602720 4], [https://crt.sh/?id=19602670 5], [https://crt.sh/?id=19602679 6], [https://crt.sh/?id=19602705 7], [https://crt.sh/?id=19602730 8].<br />
* The CP/CPS has a profile which includes issuing certificates with dNSName and iPAddress SANs, and Symantec states that Windows domain controller certs are within scope for the program. Such certs are fully TLS server certificates.<br />
* [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 A Symantec statement] suggests that customers of their NF SSP program can perform RA duties for the issuance of certs for Windows domain controllers and, according to the audit report, those RA activities are outside the scope of the audit entirely.<br />
<br />
===Symantec Response===<br />
<br />
Symantec say that the subCAs under these intermediates are under Symantec's control and, in all cases but one, are technically prevented from issuing for TLS server authentication. In one case, a customer does have the ability to issue TLS server auth certificates. The subCAs concerned ("CSC Device CA – G2" and "CSRA FBCA C3 Device CA"), like all the others, do not have BR audits.<br />
<br />
They say that their technical controls, which apply to all these subCAs, prevent EV issuance.<br />
<br />
Nevertheless, they plan to privatise this bit of the PKI by revoking trust in the certificates which link it to the WebPKI on May 24th, 2017.<br />
<br />
===Further Comments and Conclusions===<br />
<br />
Symantec say that these hierarchies were not BR audited based on the system controls they have in place and the intended usage. But Mozilla policy is based on capability, not intent. And in one case, both capability and intent led to the issuance of TLS server certs, and yet no audit was obtained.</div>Gervhttps://wiki.mozilla.org/index.php?title=User_talk:Gerardo&diff=1182104User talk:Gerardo2017-10-11T09:19:28Z<p>Gerv: Welcome!</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Gerv|Gerv]] ([[User talk:Gerv|talk]]) 02:19, 11 October 2017 (PDT)</div>Gervhttps://wiki.mozilla.org/index.php?title=User:Gerardo&diff=1182103User:Gerardo2017-10-11T09:19:21Z<p>Gerv: Creating user page for new user.</p>
<hr />
<div>I have been using Thunderbird for years and know my way around. As I live in Venezuela and exchange controls don´t allow me to contribute financially, I would like to help in other ways.<br />
I checked your questions forum and could answer some, but I have to sign in to do so.<br />
I am not a programmer but I have been using computers since 1976 and build my own.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Required_or_Recommended_Practices&diff=1182053CA/Required or Recommended Practices2017-10-10T14:45:01Z<p>Gerv: Add Pre-Issuance Linting</p>
<hr />
<div>This page contains a set of practices for CAs wishing to have their root CA certificates included in Mozilla products. In some cases these practices are required by the [http://www.mozilla.org/projects/security/certs/policy Mozilla Root Store Policy] and so are mandatory for a CA to have its root certificate(s) included. They are listed here because they are things CAs often get wrong. In other cases the practices are only recommended, but will help speed up a CA's application for inclusion and maximize the chances of its application being approved.<br />
<br />
== Required Practices ==<br />
<br />
=== Publicly Available CP and CPS ===<br />
<br />
CAs must supply the complete Certification Policy (CP) and Certification Practice Statement (CPS) containing sufficient information to determine whether and how the CA complies with the Mozilla policy requirements.<br />
<br />
* The CP/CPS must be publicly available from the CA's official web site.<br />
* The format of the CP/CPS document must be PDF or another suitable format for reading documents. CAs should ''not'' use Microsoft Word or other formats intended primarily for editable documents.<br />
* The CP/CPS must be available in an English version. The non-English version may be authoritative (as that's the working language of the CA) but the CA is responsible for ensuring that the translation is not materially different from the authoritative version of the document.<br />
* The CA must provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy.<br />
<br />
===== CP/CPS Documents will be Reviewed! =====<br />
<br />
During the [[CA:How_to_apply#Public_discussion|public discussion phase]], your CP/CPS documentation will be reviewed and commented on in the [http://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy forum]. Here are some examples of previous reviews of CP/CPS documents:<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/R2uG3wisU7s/ie_v7RHMBwAJ Review Feedback on TrustCor]<br />
** CP and CPS documents clear, well written, and they provided sufficient detail to assess the policies in place. <br />
* Review Feedback on Kamu SM (Government of Turkey)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/EtJpw8r7uGs/NmOfjdKIAwAJ CPS document clear and well written]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/vjXyml8Hy-E/bhxftrNkEAAJ New requirements for Domain Validation] -- all CAs must update their CP/CPS according to section 3.2.2.4 of [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf version 1.4.1 of the BRs].<br />
* Review Feedback on Guangdong Certificate Authority (GDCA)<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/YVOKPfnSAQAJ English translations of documents MUST match the original document.]<br />
** [https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/blMVMaHlAwAJ CA is responsible for providing accurate translation.]<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/zZ5RHXCkpGM/dvx0DjswBgAJ Review Feedback on Amazon Trust Services' CP/CPS]<br />
** Amazon was commended for the clarity of their CP and CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/eHC0JDQwBgAJ Review Feedback on Japan GPKI's CP/CPS]<br />
** Japan GPKI's CP/CPS did not contain sufficient detail, so discussion put on hold pending updated CP/CPS.<br />
* A-Trust discussion [https://groups.google.com/d/msg/mozilla.dev.security.policy/Q1beEDFdzxg/6ZILykF0AgAJ put on hold pending translation of CP/CPS into English].<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ Review Feedback on ComSign's CP/CPS]<br />
** ComSign's discussion was put on hold until the CP/CPS is updated to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. And be translated into English.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ Review Feedback on SSC's CP/CPS]<br />
** SSC's discussion was put on hold pending updated CP/CPS.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/gKCqWRmBQ_8/A1eI_zsoAAAJ Review Feedback on ISRG's CP/CPS]<br />
** ISRG's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/z1rc7vUSlb0/wJkwv5x3AgAJ Review Feedback on DocuSign's CP/CPS]<br />
** DocuSign's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/dYoQcI0e1qA/ucp1cHfVAAAJ Review Feedback on HARICA's CP/CPS]<br />
** HARICA's CP/CPS had enough detail, and there were only minor corrections/clarifications to be made.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/47Jz7f8E4RI/ACHCpG2KCpYJ Review Feedback on LuxTrust's CP/CPS]<br />
** The concerns raised regarding LuxTrust's CP/CPS resulted in the inclusion request being put on hold until the CP/CPS was updated.<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/Xvmolz36PsEJ Review Feedback on Krajowa Izba Rozliczeniowa (KIR) CP/CPS]<br />
** KIR updated their CP/CPS according to the [https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/wmwnbVbLb8cJ review feedback provided in their first discussion] <br />
** Then had to update their CP/CPS again due to feedback in their second discussion.<br />
<br />
=== Audit Criteria ===<br />
<br />
CAs must supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy.<br />
<br />
* The CA must indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy).<br />
* All documents supplied as evidence must be publicly available.<br />
* Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site).<br />
<br />
=== Revocation of Compromised Certificates ===<br />
<br />
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.<br />
<br />
=== Verifying Domain Name Ownership ===<br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2.3 of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla Root Store Policy] states: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf"<br />
<br />
The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name.<br />
<br />
===== Baseline Requirements: =====<br />
<br />
It is '''not''' sufficient to simply reference section 3.2.2.4 of the [https://cabforum.org/baseline-requirements-documents/ CA/Brower Forum's Baseline Requirements (BR)]. The BRs list several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 3.2.2.4 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. Section 2 of the BRs says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes '''in detail''' how the CA implements the latest version of these Requirements."<br />
<br />
===== WHOIS =====<br />
<br />
[http://en.wikipedia.org/wiki/WHOIS WHOIS] is used by some CAs as a source of information for checking <br />
ownership/control of the domain name for SSL certificate applications. WHOIS information may be subject to compromise. CAs are responsible for implementing appropriate methods to reduce the risk of compromise. For example, direct command line, HTTPS to the original registrar, or correlating multiple sources. The CA should include information in their CP/CPS about the method that they use to validate the integrity of the data.<br />
<br />
It is not sufficient for the CP/CPS to just state that WHOIS is checked. The CP/CPS needs to have a high level description of how the WHOIS information is used. What information must match with that provided by the certificate subscriber? Is a phone call made or email sent to the technical or administrative contact field of the domain's WHOIS record? If an email is sent, does it include non-predictable information that the technical or administrative contact must use to respond?<br />
<br />
===== Email Challenge-Response: =====<br />
<br />
Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. See [[CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs|Mozilla's restrictions on the set of verification addresses that may be used.]]<br />
<br />
CAs using this method of domain validation must ensure that they are using the full email, and that none of their systems misinterpret the localpart of an email. If your system fails to process the exact email, it will misinterpret the '+' sign as a delimiter. Consider, for example, the WHOIS contact information for a domain of "user+word@example.com" or "user=word@example.com". Both of these email addresses conform to the rules set out in RFC 822 with respect to the 'localpart' syntax. If your system emails to "word@example.com", rather than to the full "user+word@example.com" / "user=word@example.com", it will allow an attacker (who obtains "word@example.com") to cause and obtain certificates for example.com. Please work with your engineering department to ensure your systems properly handle such cases, as well as handling productions such as quoted-string, as also detailed in RFC 822 and subsequent RFCs. This is especially important as EAI addresses (described in RFC 6530 and related) come into play.<br />
<br />
=== Verifying Email Address Control === <br />
<br />
We rely on public documentation and audits of those documented processes to ascertain that the requirements of the Mozilla Root Store Policy are met.<br />
<br />
Section 2.2.2 of the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla Root Store Policy] states: “for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate”<br />
<br />
The CA's public documentation needs to provide sufficient information describing how the email address is verified to be owned/controlled by the certificate subscriber. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the email address.<br />
<br />
The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within.<br />
<br />
It is not sufficient for the CP/CPS to just say that an email is sent to the customer. The CP/CPS needs to be clear that the RA sends email to the email address to be included in the certificate. The CP/CPS needs to be clear that the email shall contain some non-predictable information that the subscriber must then use or respond with to confirm that the owner of the email address actually received the email and responded.<br />
<br />
=== DNS names go in SAN ===<br />
<br />
Some CAs '''mistakenly''' believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. <br />
<br />
According to the [https://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements:]<br />
* BR #9.2.1 (section 7.1.4.2.1 in BR version 1.3), Subject Alternative Name Extension<br />
** Required/Optional: '''Required'''<br />
** Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server.<br />
* BR #9.2.2 (section 7.1.4.2.2 in BR version 1.3) , Subject Common Name Field<br />
** Required/Optional: '''Deprecated (Discouraged, but not prohibited)'''<br />
** Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1 - or section 7.1.4.2.1 in BR version 1.3).<br />
<br />
=== OCSP ===<br />
<br />
OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. Firefox and some other clients do not work with HTTPS OCSP responders, and many firewalls block requests that aren't over port 80, so OCSP responders must be accessible over HTTP (not only HTTPS) on port 80. <br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates], the OCSP URI must be provided in the certificate, except when OCSP stapling is used. BR #13.2.2 (section 4.9.10 in BR version 1.3): "The CA SHALL update information provided via an Online Certificate Status Protocol..." From Appendix B (section 7.1.2 in BR version 1.3) regarding authorityInformationAccess in Subordinate CA Certificate and Subscriber Certificate: "With the exception of stapling ... this extension MUST be present ... and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder..."<br />
<br />
As per the [https://www.cabforum.org/documents.html CA/Browser Forum’s Guidelines for EV Certs], CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. ({{Bug|585122}})<br />
<br />
OCSP service for end-entity certs must be updated at least every four days, and OCSP responses must have a maximum expiration time of ten days. <br />
<br />
RFC 2560, sections 2.2, 2.6, 3.2 and 4.2.2.2 define the requirements for the OCSP response signer's certificate and certificate chain. NSS enforces these requirements exactly.<br />
<br />
You MUST test your OCSP service in Firefox! We expect OCSP responders to function without error in Mozilla products. To test in Firefox:<br />
* Go to Firefox -> Preferences... -> Advanced -> Certificates<br />
* Check the box for "Query OCSP responder servers to confirm the current validity of certificates"<br />
* Close the popup<br />
* You may need to clear your history cache<br />
* Browse to a website whose SSL certificate chains up to your root and has the corresponding OCSP URI in the AIA extension.<br />
<br />
Errors that CAs sometimes encounter when testing OCSP in Firefox:<br />
* Error code: sec_error_ocsp_unauthorized_response<br />
** Please read section 4.2.2.2 "Authorized Responders" on pages 10-11 of RFC 2560. CAs that emit certificates for the general public must use a configuration that conforms to either rule 2 or 3. NSS also supports rule 1, but it requires manually configuring Firefox to set the [[CA:OCSP-TrustedResponder|trusted OCSP responder.]] This makes this choice relevant only when the Firefox installation is part of a centralized deployment where a local OCSP responder has been setup to send back OCSP responses for all the CAs that are locally trusted. The IETF pkix group that authored RFC 2560 has confirmed that rule 1 is intended to cover similar situations and not public deployments.<br />
* Error code: sec_error_ocsp_bad_http_response<br />
** the http response from the OCSP responder had some result code other than 200.<br />
** The http 200 response from the OCSP responder could not be decoded.<br />
* Error code: sec_error_ocsp_invalid_signing_cert<br />
** OCSP response signer's certificate was issued by the CA that issued the certificate whose status is being checked, but the response signer's certificate does not bear an ExtendedKeyUsage extension with the OCSP Responder OID, or<br />
** OCSP response signer's certificate chain does not validate (e.g. expired, or bad signature, etc.)<br />
** Trusted OCSP Responder Signing cert has not been imported. Mozilla users should not have to find and install the OCSP responder's certificate. See [[CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root|Potentially Problematic Practices.]]<br />
* Error code: sec_error_bad_database<br />
** the OCSP response gives a cert subject name to identify its signer's certificate, but no certificate by that name can be found -- not in the response, not in the database, and not in the cert chain of the certificate whose status is being checked. See [https://bugzilla.mozilla.org/show_bug.cgi?id=560091 this bugzilla bug] for more details.<br />
<br />
=== Network Security Controls ===<br />
<br />
CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.<br />
<br />
It is expected that CAs do the following on a regular basis:<br />
* Maintain network security controls that at minimum meet the [https://www.cabforum.org/documents.html Network and Certificate System Security Requirements.]<br />
* Check for mis-issuance of certificates, especially for high-profile domains.<br />
* Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.<br />
* Ensure Intrusion Detection System and other monitoring software is up-to-date.<br />
* Confirm the ability to shut down certificate issuance quickly if alerted of intrusion.<br />
<br />
== Recommended Practices ==<br />
<br />
=== CA Hierarchy ===<br />
<br />
A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not. See [[CA:Recommendations_for_Roots]].<br />
<br />
CAs that issue certificates under multiple subordinate CAs (i.e., under a root CA whose CA certificate is being requested for inclusion) or under multiple CA hierarchies (i.e., rooted at multiple root CAs, one or more of whose certificates is being requested for inclusion) should provide additional information as noted:<br />
* The CA should provide a graphical or textual description of the CA hierarchy or hierarchies, including which subordinates are under which root CAs<br />
* The CA should indicate the general types of certificates (i.e., for SSL/TLS servers, email signing/encryption, and code signing) issued by each subordinate CA under each root.<br />
* Where a CP/CPS applies to multiple subordinate CAs and/or multiple CA hierarchies, the CA should indicate whether particular sections of the CP/CPS apply to different subordinates and/or hierarchies and, if so, what the differences are.<br />
<br />
We also recommend that CAs consider using separate root CA certificates with separate public keys (or separate intermediate CA certificates with separate public keys under a single root) when issuing certificates according to different Certificate Policies, so that we or others may selectively enable or disable acceptance of certificates issued according to a particular policy, or may otherwise treat such certificates differently (e.g., in our products' user interfaces).<br />
<br />
=== Document Handling of IDNs in CP/CPS ===<br />
<br />
If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)<br />
<br />
=== Usage of Appropriate Constraints ===<br />
<br />
Root certificates in Mozilla's program can have either the SSL trust bit set, or the Email trust bit, or both. If only one of those bits is set, relying software will trust certificates in that hierarchy for only that purpose. Nevertheless, it is a best practice for the immediately-issuing intermediate certificate to also contain EKU constraints of either id-kp-serverAuth or id-kp-emailProtection as appropriate, such that if the trust status of the root ever changes (or is not enforced for some reason), the end-entity certificates are still appropriately constrained.<br />
<br />
=== Pre-Issuance Linting ===<br />
<br />
Recently, several tools have been developed ([https://github.com/awslabs/certlint certlint/cablint], [https://github.com/kroeckx/x509lint x509lint], [https://github.com/zmap/zlint zlint]) which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (BRs, RFCs etc.). It is strongly recommended that CAs integrate such tools into their issuance pipelines such that issuance is, minimally, held up for manual review if an error or warning is found. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences, if earlier parts of their pipeline fail in their job of keeping certificates compliant.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Intermediate_Certificates&diff=1182035CA/Intermediate Certificates2017-10-10T10:23:22Z<p>Gerv: Standardize link text format</p>
<hr />
<div>= Intermediate Certificates =<br />
<br />
[[CA/Included_Certificates|CAs]] are required to provide the data for all of their [[CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F|publicly disclosed and audited intermediate certificates]] which chain up to root certificates in Mozilla's program. They do this using the [[CA:SalesforceCommunity|CCADB]]. <br />
<br />
The following reports are '''generated once per day''' and include valid intermediates and expired intermediates but not revoked intermediates:<br />
<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts Intermediate CA Certificates] (HTML)<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCertsCSV Intermediate CA Certificates] (CSV)<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCertsWithPEMCSV Intermediate CA Certificates] (CSV with PEM of raw certificate data)<br />
<br />
The following reports list revoked intermediates:<br />
<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevoked Revoked Intermediate CA Certificates] (HTML)<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedCSVFormat Revoked Intermediate CA Certificates] (CSV)<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV Revoked Intermediate CA Certificates] (CSV with PEM of raw certificate data)<br />
<br />
The following reports list the intermediate certs that are ready to be added to OneCRL. Some non-revoked intermediate certs are added to OneCRL because they are not intended to be used for SSL/TLS.<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicInterCertsReadyToAddToOneCRL Intermediate CA Certificates Ready to Add to OneCRL] (HTML)<br />
* [https://ccadb-public.secure.force.com/mozilla/PublicInterCertsReadyToAddToOneCRLPEMCSV Intermediate CA Certificates Ready to Add to OneCRL] (CSV with PEM of raw certificate data)<br />
<br />
Firefox (version 37 and later) uses the [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL] system, which pushes a list of revoked certificates to the browser. It includes (or should include) all the revoked intermediates in the above report.<br />
<br />
* [https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records OneCRL Raw Data]<br />
* [https://crt.sh/mozilla-onecrl OneCRL data table with links to each certificate in crt.sh and the corresponding Bugzilla bugs]</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident&diff=1181935CA/Responding To An Incident2017-10-07T07:11:55Z<p>Gerv: Improvements suggested by Jakob</p>
<hr />
<div>The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. <br />
<br />
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.<br />
<br />
Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates.<br />
<br />
While some forms of incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.<br />
<br />
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response. <br />
<br />
= Immediate Actions =<br />
<br />
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done.<br />
<br />
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.<br />
<br />
= Revocation =<br />
<br />
It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.4.9):<br />
<br />
<blockquote><br />
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …<br><br />
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br><br />
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …<br><br />
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br><br />
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).<br />
</blockquote><br />
<br />
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 24 hours.<br />
<br />
However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR-compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then your report will need to explain those reasons and provide a timeline for when the bulk of the certificates will expire or be revoked/replaced.<br />
<br />
If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will need to be listed as a finding in your CA’s BR audit statement.<br />
<br />
We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates. <br />
<br />
= Follow-Up Actions =<br />
<br />
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?<br />
<br />
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?<br />
<br />
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?<br />
<br />
* Scan your corpus of certificates to look for others with the same issue. It does not look good for a CA to claim they have revoked all affected certificates and resolved the issue, and then for a researcher to discover another set of certificates with the same or a similar problem.<br />
<br />
* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] to harden your issuance pipeline against further problems.<br />
<br />
* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.<br />
<br />
= Incident Report =<br />
<br />
Each incident should result in an incident report, written as soon as the problem is fully diagnosed and (temporary or permanent) measures have been put in place to make sure it will not re-occur. If the permanent fix is going to take significant time to implement, you should not wait until this is done before issuing the report. We expect to see incident reports as soon as possible, and certainly within two weeks of the initial issue report. While remediation work may still be ongoing, a satisfactory incident report will serve to resolve the issue from a Mozilla perspective. <br />
<br />
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report.<br />
<br />
The incident report should cover at least the following topics:<br />
<br />
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.<br />
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.<br />
# Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.<br />
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.<br />
# The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.<br />
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.<br />
# List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.<br />
<br />
= Keeping Us Informed =<br />
<br />
Once the report is posted, you should provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree a different update schedule with you. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug, if there is one. The bug will be closed when remediation is completed.<br />
<br />
= Examples of Good Practice =<br />
<br />
Here are some examples of good practice, where a CA did most or all of the things recommended above.<br />
<br />
== Let's Encrypt Unicode Normalization Compliance Incident ==<br />
<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/g6_zGA2exXw Initial Public Problem Report], 2017-08-10 20:23 UTC (apparently LE were made aware of the problem privately earlier that day)<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/g6_zGA2exXw/_tXldrbIBwAJ Initial Public Response from CA], 2017-08-10 21:53 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/nMxaxhYb_iY/AmjCI3_ZBwAJY Final Report from CA], 2017-08-11 03:00 UTC<br />
<br />
In this case, the CA managed to diagnose the problem, remediate it, and deploy the fix to production within 24 hours.<br />
<br />
== PKIOverheid Short Serial Number Incident ==<br />
<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Initial Public Problem Report], 2017-07-18 22:26 UTC<br />
* [https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/TzH5eI9dAQAJ Initial Public Response from CA], 2017-07-25 19:20 UTC<br />
* [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ Final Report from CA], 2017-08-11 14:39 UTC<br />
<br />
While the CA could have provided interim updates, and the final report was a little delayed, the contents of it were excellent.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA&diff=1181934CA2017-10-07T07:06:31Z<p>Gerv: /* Information for CAs */</p>
<hr />
<div>__NOTOC__<br />
= Mozilla's CA Certificate Program =<br />
<br />
Mozilla’s CA Certificate Program governs inclusion of root [https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates certificates] in [https://developer.mozilla.org/en-US/docs/NSS Network Security Services (NSS),] a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of products. The program is overseen by the module owner and peers of the [[Modules/Activities#CA_Certificates|CA Certificates Module]]; the policy itself is overseen by the module owner and peers of the [[Modules/Activities#Mozilla_CA_Certificate_Policy|CA Certificate Policy Module]].<br />
<br />
== Policy ==<br />
<br />
* [http://www.mozilla.org/projects/security/certs/policy/ Root Store Policy] (current stable version: 2.5)<br />
* [[CA/Communications | CA Communications]] and their responses. Such communications may also set policy in advance of it being included in the Root Store Policy.<br />
* [[CA/Root_Store_Policy_Archive|Root Store Policy Archive]]<br />
* [[CA/Updating_Root_Store_Policy|Process for updating the Root Store Policy]]<br />
** [https://github.com/mozilla/pkipolicy/issues Root Store Policy Issue Tracker]<br />
** [https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Latest draft of Root Store Policy] (will become the next version)<br />
<br />
== Lists of CAs and Certificates ==<br />
<br />
* [[CA/Included_CAs|Included CAs]] (in the Root Program and in Firefox)<br />
* [[CA/Included_Certificates|Included CA Certificates]]<br />
* [[CA/Intermediate_Certificates|Intermediate Certificates]]<br />
* [[CA/Removed_Certificates|Removed CA Certificates]]<br />
* [[NSS:Release_Versions|NSS Release Versions]] - shows in which version of Mozilla products each root certificate was first available<br />
<br />
== Program Administration ==<br />
<br />
Most information relating to the administration of our program is stored either in [https://bugzilla.mozilla.org/ Bugzilla] or in the [[CA:CommonCADatabase|Common CA Database]].<br />
<br />
* [[CA/Dashboard|Certificate Change Request Dashboard]] - tracks applications and trust changes through the process in Bugzilla<br />
* [[CA/Certificate_Change_Requests|Certificate Change Requests]] as tracked in the CCADB<br />
* [[CA/Incident_Dashboard|Incident and Compliance Dashboard]]<br />
* [[CA/Bug_Triage|Bugzilla Bug Triage Process]]<br />
<br />
====crt.sh====<br />
<br />
* [https://crt.sh/mozilla-disclosures Disclosure status of all certificates known to CT]<br />
* [https://crt.sh/?cablint=issues Problematic certificates issued in the past week known to CT]<br />
<br />
== Information for CAs ==<br />
* [http://ccadb.org/cas/ CCADB Login]<br />
* [[CA/Responding_To_An_Incident|Responding to an Incident]] (such as a misissuance)<br />
* [[CA/Application_Process|Application Process for Mozilla's Root Program]]<br />
** [[CA/BR_Self-Assessment|Baseline Requirements Self Assessment]]<br />
** [[CA/Information_Checklist|CA Information Checklist]]<br />
** [[CA/Subordinate_CA_Checklist|Subordinate CA Information Checklist]]<br />
* [[CA:Root_Change_Process|Making Changes to Included Roots]]<br />
* [[CA/Required_or_Recommended_Practices|Required or Recommended CA Practices]]<br />
* [[CA/Forbidden_or_Problematic_Practices|Forbidden or Problematic CA Practices]]<br />
* [[PSM:EV_Testing_Easy_Version|EV Readiness Test]]<br />
* [https://github.com/awslabs/certlint BR Lint Certificate Test] - source code download<br />
* [https://github.com/kroeckx/x509lint X.509 Lint Certificate Test] - source code download<br />
<br />
== Information for Auditors ==<br />
<br />
* [[CA/Auditors|Information for Auditors]]<br />
<br />
== Information for the Public ==<br />
<br />
* [[CA/Terminology|Glossary of CA and Certificate Terminology]]<br />
* [[PSM:Changing_Trust_Settings|Changing Certificate Trust Settings in Firefox]]<br />
* [https://tls-observatory.services.mozilla.com/static/certsplainer.html Mozilla's Certificate Explainer]<br />
* [https://www.ssllabs.com/ssltest/analyze.html Qualys SSL Server Quality Checker]<br />
* [https://observatory.mozilla.org/ Mozilla SSL Server Quality Checker]<br />
* [https://certificate.revocationcheck.com/ Certificate Revocation Checker] (also checks CRL and OCSP server quality and compliance)<br />
<br />
== Discussion Forums ==<br />
<br />
The following Mozilla public forums are relevant to CA evaluation and related issues. Each forum can be accessed either as a mailing list, over the web or as a newsgroup.<br />
<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security-policy mozilla.dev.security.policy] (MDSP). This forum is used for discussions of Mozilla policies related to security in general and CAs in particular, and for wider discussions about the WebPKI. Among other things, it is the preferred forum for the public comment phase of CA evaluation. If you are a regular participant in MDSP, then please add your name to the [[CA/Policy_Participants|Policy Participants]] page.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto]. This forum is used for discussions of the [http://www.mozilla.org/projects/security/pki/nss/ NSS] cryptographic library used in Firefox and other Mozilla-based products, as well as the [http://www.mozilla.org/projects/security/pki/psm/ PSM] module that implements higher-level security protocols for Firefox.<br />
* [https://www.mozilla.org/en-US/about/forums/#dev-security mozilla.dev.security]. This forum is used for discussions of Mozilla security issues in general.</div>Gervhttps://wiki.mozilla.org/index.php?title=CA/Responding_To_A_Misissuance&diff=1181933CA/Responding To A Misissuance2017-10-07T07:05:10Z<p>Gerv: Gerv moved page CA/Responding To A Misissuance to CA/Responding To An Incident: Generalizing title</p>
<hr />
<div>#REDIRECT [[CA/Responding To An Incident]]</div>Gerv