Document control
Procedure reviews
The following table is updated after every review of this procedure.
Table of contents
Overview
About this distribution
This page describe the procedure for the announcement and propagation of a new release of the EGI Trust Anchor distribution. The EGI Policy on Approved Certification Authorities describes the set of trust anchors accepted by EGI and put forward for consideration by the NGIs to install as the 'agreed set' of Identity Management trust anchors. For the time being, only PKI trust anchors ('Certification Authorities') are included in this release.
The announcement and distribution of trust anchors within EGI and the NGIs should be done in a well defined order to ensure consistent deployment and to ensure that the monitoring of the NGIs and sites matches the currently recommended version of the trust anchors.
Trust Anchor Policy and Transition Processes
The trust anchor distribution contains two variants integrated in a single release: the "ca-policy-egi-core" that is suitable for all EGI trust scenarios, and a "ca-policy-egi-cam" (combined assurance/adequacy) package based on the approved policy on differentiated assurance. Technically, this means that relying parties, independently or by way of their NGI, must only install the new "ca-policy-egi-cam"
packages if they also at the same time implement VO-specific authorisation controls in the software stack.Both variants are always co-released at the dame time, using this same procedure.
Some EGI relying parties that have been in operation since before 2012 may be using the "lcg-CA" meta-package that reflects a combination of EGI as well as wLCG policy on approved CAs. This package is deprecated, and new sites must install the new "ca-policy-egi-core" or "ca-policy-egi-cam" package. In current releases, installing the "lcg-CA" meta-package, having triggered installation of both the "ca-policy-egi-core" package as well as the "ca-policy-lcg" package, can subsequently be removed. It is not guaranteed that in the future the EGI and wLCG policies will stay aligned, so sites that relied on the "lcg-CA" package distributed by EGI to also comply with the wLCG policies on accepted CAs should keep this in mind. Also, the acceptable authentication policy for your organisation, country, or region may be different from the EGI federation: your organisation, NGI, or country may have approved additional trust anchors for use on your infrastructure, or put in specific constraints. As a result, you may want to review the EGI core or cam list.
Definitions
Please refer to the EGI Glossary for the definitions of the terms used in this procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Entities involved in the procedure
- IGTF/EUGridPMA Liaison (egi-igtf-liaison@nikhef.nl)
- Repository and Staged Rollout (SR) Team via RT (umd-team@mailman.egi.eu)
- Monitoring Team (central monitoring configuration centre) via RT
- NGI managers (noc-managers@mailman.egi.eu)
- Release update recipients: NGI contacts and all sites (via CIC portal)
- Security oversight and determination of grace period: EGI CSIRT (via egi-csirt@mailman.egi.eu)
Triggers
- Scheduled release: EGI Trust Anchor releases are usually done on the last Monday of the month (except for security or critical bug fixes), but only if such a release would be materially different from the deployed version. EGI will get a preview release in the previous week for Staged Rollout.
Steps
Step# | Responsible | Action | Prerequisites, if any | |
---|---|---|---|---|
1 | IGTF Liaison | Prerequisites:
Internal actions:
| ||
2 | IGTF Liaison | Submit a software RT ticket to the sw-rel queue https://rt.egi.eu/rt/Ticket/Create.html?Queue=24:
Add In the description field
In the RT ticket, the monitoring team should be involved via a CC to eimamagi@srce.hr, and the security officers via sveng@nikhef.nl. | ||
2b | SR Repo | Ticket triggers the import of distribution to the EGI Repository "unverified" repository for starting the staged-rollout process as documented in the NSRW New Software Release Workflow To ensure a smooth, parallel update of the repository and the monitoring/Nagios tests, the non-urgent updates should be started before Wednesdays noon-time. | ||
3 | IGTF Liaison | announce new ticket (with ticket ID) (following on or forwarding the EUGridPMA-Announce list) to
Mail paste list: egi-csirt-team@mailman.egi.eu, jpina@lip.pt, jorge@lip.pt, eimamagi@srce.hr, noc-managers@mailman.egi.eu, sveng@nikhef.nl, egi-igtf-liaison@nikhef.nl, dennisvd@nikhef.nl, dsimmel@psc.edu, jteheran@fnal.gov, umd-team@mailman.egi.eu. Either the EGI CSIRT, the EGI Operational Security Coordinators, or the MW unit can declare this update as urgent. | ||
4 | SR team | Run initial acceptance process to check compliance with the package requirements and upload report. Progress ticket state
| distribution available in .../unverified/ | |
5 | SR team | verifies if the package works in an at-most-one-day process, but does not close the ticket and does NOT progress to production at this stage. | At the transition to .../sw/stagerollout/ | |
6 | All entities | WAIT for the official IGTF release, which will be announced through the RT ticket as a comment. The new EGI trust anchor release should not progress to production until the IGTF announcement is out (please!) | ||
7 | SR team | can now progress to release:
|
| |
2 | SR team | sends the announcement with changelog (from the RT ticket) to the NGI contacts and the sites through the Operations Portal (select "To ROC Managers", "To Production Site Admin","Operation tools"), with a CC to the gLite EMT. The change log to be included in the mail is part of the RT ticket NSRW XML and can also be found at http://repository.egi.eu/sw/production/cas/1/current/meta/ as file ca-policy-egi-core-readme-X.Y.txt(with X.Y the version number). | ||
8 | EGI-CSIRT | Verifies that
If a critical update was not released in time, it will (i) warn the technical and operational coordinators of EGI thereof, and (ii) take appropriate action to ensure the security of the infrastructure. | In case the update was marked critical |