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 isnotguaranteed 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.
Scheduled release: EGI Trust Anchor releases are usually done on thelast 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.
this builds the EGI-specific trust anchor package, currently called "ca-policy-egi-cam" and dependencies, and makes that available on the dedicated site intended for internal use and upload by the deployment process. An additional package, "ca-policy-lcg" is included as a convenience service to the wLCG community, but its availability is contingent on it being fully compatible with the EGI processes and policies. It doe snot have a special status and may be withdrawn at any moment regardless.
Agree to copy sync the directories to both targets using rsync
Recreate the file listing for ftp directory listings and archie
cd www-egi/html/distribution/egi/
ls -lR | sed -e 's/davidg/nobody/g;s/emin/nobody/g' > ls-lR
This EGI distribution contains:
all CAs accredited under the IGTF "classic", "mics", "slcs", and "iota" profiles (following the Policy on Accepted CAs)
the "ca-policy-egi-core" and "ca-policy-egi-cam" meta-packages, as well as the legacy/compatibility packages "lcg-CA" and its corresponding "ca-policy-lcg" meta package
any other EGI specific CAs or exception as decided by EGI (currently none)
the patch RPM for the Apache mod_ssl bug (the "dummycas" RPM)
the appropriate NRMS XML, meta-data, SAM/Nagios XML (release date set 2 days to the future), README.txt file, and repo headers.
This distribution is RPM (only!) unit tested before upload by installing it on a reference system, using the RPMs copied to the internal release web. This uses the repo file
[egi-test]
name=EGI Trust Anchors test
baseurl=https://egi-igtf.ndpf.info/distribution/egi/current/
gpgcheck=1
enabled=0
gpgkey=https://dl.igtf.net/distribution/igtf/current/GPG-KEY-EUGridPMA-RPM-3
Configuration and validation
Verify the release date in the release.xml file, pre-dating it by 8 days if this is a security release
Verify the egi-igtf site so that the symlink "egi/" is set to the proper versionbeforeproceeding to send to rsync:// URL.
Verify that rsync -L rsync://egi-igtf.ndpf.info/egi-igtf/egi/ returns the correct distribution
The upstream repository for this release is rsync://egi-igtf.ndpf.info/egi-igtf/egi/
The following hints apply to this release: - this is a (regular|security) release with (8|1)-day grace period - please do NOT release before Monday MM DD, this being the intended release date of the upstream of this version by the IGTF - preferably send this in the beginning of the week, and on or after a Thursday - please send a note to the sites once it moves to production
The following release notes accompany this version:
<insert release notes here>
3
UMD team
Mail to <urt-discuss@mailman.egi.eu> triggers the import of distribution to a staging repository for starting validation & testing process by the UMD team
To ensure a smooth, parallel update of the repository and the monitoring services, non-urgent updates should be started before Wednesdays noon-time.
3b
EGI CSIRT
Either the EGI CSIRT, the EGI Operational Security Coordinators, or the UMD 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 state
to Staged Rollout, or
cancel release and request re-upload. This would bring the process back to step 1 (where the public release version number may be kept to "-1")
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 by email as a reply/update to the trigger. 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:
check the date. If the date in the "release.xml" file (<Date> entry) is already passed, ask Kostas to update this file in the repo on final release. Otherwise, just continue...
moves release from staged roll-outto production, triggering over-write (non-incremental) of the .../sw/production/cas/1/ directory.
IGTF has announced and published the underlying release on https://igtf.net/
Comment in RT ticket is present
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 athttp://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).
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.