Dear EUGridPMA and IGTF members, The 34th EUGridPMA meeting is now over, and I would like to take this opportunity to again thank Anders Waananen, the Niels Bohr Institute, and the Nordic e-Infrastructure Collaboration for hosting us in Copenhagen! This summary and the minutes kindly taken by Emir Imamagic are on-line, with some more of my own notes to be posted later, but meanwhile I would like to share with you a few of the highlights of the meeting. Send corrections and omissions if you spot them, since these have been taken from my own scribbles and memory. Specifically FOR THE TAGPMA and APGridPMA: The Registration Practice Statement draft document and the IGTF Generalised Levels of Authentication Assurance (LoA) document have been reviewed and changed. Please review these changes and send your comments to the igtf-general list! And see below for details. Subsequent meetings will be: - TAGPMA F2F, Pittsburg, VA, USA on May 27-29 - TNC The Networking Conference, with lots of identity management sessions and workshops: Porto, Lisbon on June 14th (REFEDS) - 19th ** 35th EUGridPMA meeting, September 7-9 2015 in Amsterdam, NL - APGridPMA F2F and 40th APAN meeting August 10-14 in Koala Lumpur, MY - REFEDS (and I2TechX), Oct 4 (and 5-7) 2015 in Cleveland, OH, USA ** 36th EUGridPMA meeting, January 2016 location TBD - see below ** 37th EUGridPMA meeting, May 9-11, 2016 hosted by Feyza, TR-Grid and ULAKBIM in Ankara, TR See all of you in Porto and Amsterdam, or at any of the upcoming meeting of the IGTF or elsewhere. Candidates sites (preferably from the middle of Europe in order to maintain some rough geographical balance for the meeting series) for hosting the January 2016 meeting are eagerly sought. If you would consider hosting the meeting, please contact me! Slides with background of the Copenhagen meeting are attached to the agenda pages at ! Best regards, DavidG. Subject discussed and listed below ---------------------------------- - Generalized IGTF Levels of Authentication Assurance - Registration Practice Statement - SHA-2 guidance updates - GFD.225 OGF Certificate Profile now in Public Comment period (till July 3) - Authentication and Authorization for Research and Collaboration (AARC) - Assurance levels and the NIST SP800-63v2 process - Higher Level CA guidelines - Auditing, accreditation, and compliance - Communication Challenge and Risk Assessment - Miscellaneous topics * Certificates for virtual machines * Jens' Soapbox - sustainable operations in view of reduction of resources * Retirement of Yum-2 and apt-rpm support in the distribution * Concerns on short-notice changes in the trust fabric All presentations are available on the agenda page: http://www.eugridpma.org/agenda/34 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. I also apologize for any omissions and misrepresentations - this summary is taken mostly from memory and scribbles (and the scribbles will be posted on-line later - they WILL contain more detail). Generalized IGTF Levels of Authentication Assurance --------------------------------------------------- The LoA generalization process aims to extract those elements from the IGTF APs that are of general value to the community well beyond PKI. This has not always been clear from the AP document, since they have both LoA elements and PKI implementation requirements combined in a single document. The latest version 0.7 of the generalised IGTF LoA document is now available at http://wiki.eugridpma.org/Main/IGTFLoAGeneralisation The Levels very closely represent the current SLCS, MICS, Classic, and IOTA, although some level of harmonisation and alignment has also been performed. Compared to the v05 version (from January), the following material changes have been made, as made explicit in the red-lined version: https://wiki.eugridpma.org/pub/Main/IGTFLoAGeneralisation/IGTF-LoA-authN-set-changes-v05-v07.pdf - It was not deemed suitable to merge the ASPEN, BIRCH, and CEDAR levels, since they do to RPs represent materially different levels - but a preamble has been added (section 1.1) that clarifies the commonality - the section on retaining identity vetting data has been moved from the auditing section (7.1) to the identity section (3.1), and some minor discrepancies removed. (in the comparison document, that's the table formerly on page 6) - the data retention for CEDAR (Classic) used to be expressed as needed for 3 years after issuance. It has been clarified to read "two years after the last credential based on the information is no longer valid", which is equivalent for ~1 year credentials, but takes care of the renewal process - a proper description of the 'face-to-face or equivalent' process has been added for BIRCH (MICS) and CEDAR (Classic). For the benefit of MICS, specific text has been added to describe how the 'membership process' works. For ASPEN (SLCS) the text is clarified but materially exactly the same as it is today. For BIRCH and CEDAR, PLEASE REVIEW the new text on page 3, bottom table - the section on incident response (like sec 5.1 in IOTA) is now a common section in the LoA document applicable to any 3rd-party-backed authority (ASPEN, BIRCH), so it will apply also to MICS and SLCS: "The authority must not knowingly continue to rely on data from third parties that provide inaccurate or fraudulent information. It is strongly recommended that any third party on which the issuing authority relies has an incident response capability and is willing to participate in resolving such incidents" Finally some copy-edit changes were made to improve readability and to list the assigned OIDs in the document itself. The next phase of this process is to write a (single) "PKI Profile" of the Assurance Level document, so that, e.g., the "MICS AP" would merely state "Authorities must comply with the provisions of the IGTF BIRCH IDLoA specification, and implement it as a PKIX infrastructure as specified by the IGTF PKI Technical Guidelines." The assurance level document is merely pending the review of the other PMAs. The technical Guidelines need to be written (and this work is scheduled to be done really soon in the EUGridPMA). Registration Practice Statement ------------------------------- The RPS outlines the procedures that the community members follow to comply with the CA Profile. It allows communities with a defined set of registration practices to move between issuing CAs. This document, which has been worked on by both TAGPMA and EUGridPMA, was further evolved and refined, with particular attention to sections 7 and 8 this time. The new version (only changes in these sections) is again available from https://wiki.eugridpma.org/Main/RPS as https://wiki.eugridpma.org/pub/Main/RPS/RPSTemplate-May2015-EUGridPMA-sec78-reviewed.docx where also further updates can be attached and managed. We would ask the TAGPMA to start with this version again (changes have been tracked). SHA-2 implementation status --------------------------- New developments and discussions like those held on the Mozilla NSS bug tracker at https://bugzilla.mozilla.org/show_bug.cgi?id=1129083 have raised concerns about the long-term viability of SHA-512. Although there are no current poignant issues, it may be advisable to not use SHA-512 for new long-term choices, but instead use SHA-256 (or SHA-384 which is not specifically better but, it being included in the TLS1.2 suite of digest functions is better supported). We remind issuing authorities that - it is now allowed and encouraged to issue SHA-2 familty CRLs - for long lives CRLs (those issues by off-line Root CAs that are not issuing CAs), it is RECOMMENDED to issue SHA-2 (sha256) CRLs now - there are quite a few intermediate CAs still using SHA-1. These can be re-issued with a new serial number (provided the end-entity EEC certificates do not have an explicit serialNumber in their authorityKeyID) Registration is through your PMA chair or trusted registrar and when you are at it, new CAs should probably start using 4096-RSA bit key pairs and sha-256 for longevity and compatibility. GFD.225 OGF Certificate Profile ------------------------------- The successor to the Grid Certificate Profile GFD.125 has re-entered OGF Public Comment at https://redmine.ogf.org/projects/editor-pubcom/boards/14 and your comments are welcome until July 3, 2015. The following open issues were identified: - with the use of commonName (CN) in server certificates, the use of the Kerberism "service/FQDN" should be discouraged. So the commonName should "consistent of" (not: "contain") the FQDN of the server - streetAddress and postalCode SHOULD NOT be used, as they are not consistently represented by software (as noted by Jim Basney) as well as some copy-edits to be done: - "Required" attributes are visually shown in the same style as the table header itself, which is confusing - the trailing "." should be removed from the "*.example.com." example - page #16 has a loose word ("find") in a random place Authentication and Authorization for Research and Collaboration (AARC) ---------------------------------------------------------------------- The AARC Project, https://aarc-project.eu/, has started on May 1st. An overview presentation is available on the agenda page at In short, AARC aims to develop and pilot an integrated cross-discipline authentication and authorisation framework, built on existing AAIs and on production federated infrastructures. Thus, we should be able to avoid a future in which different e-Infrastructures and (new) research collaborations develop and operated independent (and not inter-operable) AAIs. Via user-communities driven pilots, AARC will test critical technical and policy components developed within the AARC project and will pilot the integration of policy frameworks into production services and the adoption of ready to use solutions for institutions to deploy federated. And given that research and education is global nowadays, the solutions to AAI should be global as well. For the best practice and policy coordination, which is closest to the IGTF, please contact us (see the web) and/or join an AARC event. In particular, the work on assurance levels that comes of the generalisation process the IGTF has been doing, is highly relevant for AARC and considered one of its inputs. The interaction with government eID in Europe is also strengthening and important in particular now that eID mobility is promoted to facility cross-border employment for young people. There are of course many technical harmonisation challenges as well. Some can be seen and were discussed on the Wednesday technical session on developments in Federations and non-Web AAI. Others merit longer discussion in the coming months. Registration for the AARC kick-off meeting, June 3+4 in Amsterdam, is still open. There will also be video conferencing available: https://eventr.terena.org/events/2146 Review the documents, presentations, & web site, and join AARC in Amsterdam! Assurance levels and the NIST SP800-63v2 process ------------------------------------------------ Please review the presentation by Bob Cowles at https://indico.nikhef.nl/materialDisplay.py?contribId=12&materialId=slides&confId=166 The discussion following this touched on many points: - using LoA quickly leads to things that are too complex for relying parties to process (akin to what is now seen for the "Vectors of Trust" IETF discussion. Obviously, for data that is more sensitive, RPs are willing to invest more time getting the controls and assurance correct - the STORK (eGov ID) project also described LoA levels, and again got four (4) of these. They consider both organisational factors (quality of the identity vetting, quality of the issuer), and technical factors (security factors used, tokens). The result is a set of 'combined' levels 1..4, although the middle level ("substantial") makes it hard to give an informed judgement as to what you actually get from it. - Ongoing efforts linking STORK and R&E federations, coordinated by ChristosK, may shed some light, but the focus is on technical communication for the exchange of attributes, not on policy agreement. - The future ma well be to 'trust marks', and having (several) groups define such trust marks and associate them with identity providers, specific issued assertions, or both. In SAML meta-data, these could be expressed as entityCategoties and either ePAssurance or SAMLAuthNContextClassRefs, respectively. Obviously, the LoA of a specific assertion should not be higher than the levelof the IdP that issues them ... - For the IGTF, our relying parties will need LoA 'end-to-end', also taking into ccount assurances given by (and deferred to) other entities like attribute authorities, communities, and community enrolment processes. You see in practice that some IGTF levels (Classic, MICS, SLCS) are treated as roughly equivalent, but that's not enough to merge them. There is continuous confusion as to IOTA (DOGWOOD) means, and it is often mistaken for the same thing as the other levels. More specific guidance is needed to make clear that IOTA is *really different*! Higher Level CA guidelines -------------------------- The HLCA (Higher Level CA) trust document/guideline was revived. This document https://indico.nikhef.nl/getFile.py/access?contribId=11&resId=0&materialId=0&confId=166 can define requirements on trust anchors that merely serve to support accredited issuing CAs. However, multiple technical difference remain. In particular, it is unclear how in the current distribution model the relying-party defined name-space constraints (RPDNC, see GFD.189 at https://www.ogf.org/documents/GFD.189.pdf) in the historic Globus format (".signing_policy") could be generated dynamically to allow HLCA models to work. Work on a new distribution format, that has site-local configuration and need for scripting at the RP end, needs to happen first. There is currently no effort available o investigate this (but e.g. summer students are welcome!). Also monitoring would become more complex. Having a single package would also increase the risk of sites and users 'just installing' all possible profiles, even if e.g. IOTA or EXPERIMENTAL are NOT suitable for their needs. The risk for such confusion remains high. There will not be an HLCA meta-package, and as today the relevant 'upstream' trust anchors will be packaged with the 'highest LoA' profile that needs them. Auditing, accreditation, and compliance --------------------------------------- Both SRCE and MARGI presented their self-audit results at the meeting. Reviewers have been assigned to complement the self-assessments, with Feyza and Ian Neilson reviewing the SRCE results and new CP/CPS, and Emir and DavidG to review the one from MARGI. Also the NorduGrid CA will be revised and re-keyed with a longer key. Anders Waananen presented the plans of the NorduGrid CA that will remain for some edge cases that are not served by TCS in the Nordic countries. We again thank Cosmin for his work as self-audit review controller - and ask everyone to please process the requests coming from Cosmin in a timely fashion! Also the UKeScience CA was presented - the longer term collaboration with JCS remains a topic for ongoing discussions. Communication Challenge and Risk Assessment ------------------------------------------- Concern was expressed about non-response and the failure to refresh CRLs in time (it being an indication of activity and autonomy), There is a rough and worrying correlation between the CRL failures and response to the RAT Communication Challenges. Specifically, the "pma-dist-warntool" messages sent by the EUGridPMA service MUST NOT be used as your personal calendering system ;-) The consensus, as endorsed by the IGTF All Hands meeting in March is: - suspend a CA for operational reasons if - after 30 days of commencement of a failure condition it cannot be resolved - suspend a CA also after failure to respond to a Communications Challenge for more than 30 days However, the suspension will of course only take effect if there is a complete lack of communictions. Valid reasons and exceptions will always be possible on a case-by-case basis. It is also considered to increase the frequency of the RAT Challenges to twice-yearly. The questions should be limited to requesting a direct acknowledgement, with follow-up of more complicated things to be done later. To lessen the impact of CRLs being expired for fresh installation by relying parties, it may be advisable to have an 'expired' CRL installed on all fresh installations, which will be replaced as soon as a crl retrieval tool (such as fetch-crl) has updated it. The effect would be to 'disable' a CA by default until current revocation information can be obtained. This is within the domain of our relying parties, and not a primary task of the PMA. We may however make such a package available (or, say, EGI can do that), with all CRLs marked as 'config()' so that re-installation of such a package will not override current good CRLs. Certificates for virtual machines --------------------------------- Generating certificates for dynamic hosts created in IaaS cloud scenarios with unpredictable host names lends itself ill to a manual issuance process. When automatic such a task, the solution should be either close to the one adopted by the CERN IT/IS CA (i.e. use of a trusted database of network endpoints), or consider at least - revocation of certificates once the VM is terminated - short-lived certificates (with the option to renew periodically) - the sending of proper DCV domain validation challenges based on actions by the new VM (i.e. nonce-URLs) and consider that revocation of long-lived credentials in a dynamic environment may lead to very long CRLs. There is no standing recommendation for this use case yet, and it needs further attention and review! Miscellaneous topics -------------------- - the packaging support for Yum version 2 and for apt-rpm will be withdrawn some time in 2015. The PMA sees no longer a need to keep these formats, since the corresponding clients are no longer used and it becomes increasingly difficult to provide the packages (in particular for apt-rpm). Please see the EUGridPMA newsletter for May 2015 (upcoming) for details. - Jens' Soap Box is on-line as well and worth a look if you are running a resource-constraint operation. - it is observed that much of our discussion, documentation and talk is riddled with acronyms. And even if the sentences make full grammatical sense, their content remains obscure. Public communications should be strengthened especially when we want t reach out ot the wider research community, IdPs, and users. - Additionally, Relying parties express their worry that around July 1st a lot of changes will happen in the trust fabric, and not all of these are yet sufficiently communicated, and some changes like those for OSG are not even yet completely assured, resting on pending accreditations, whilst previous contracts have already been cancelled. Also it is of concern that the NRENs of some countries are opting for a very short transition period for the Trusted Certificate Service (TCS) in order to reduce cost, but at the expense of ease of use and user & IdP training possibilities. The RPs wLCG and EGI hope and expect that the changes will all be smooth and transparent, and would prefer fewer changes at short notice that impact large user bases.