EUGridPMA Status and Current Trends and some IGTF topics March 2014 Taipei, TW David Groep, Nikhef & EUGridPMA

EUGridPMA Topics EUGridPMA (membership) status Risk Assessment Team IPv6 readiness and fetch-crl SHA-2 time line CA readiness for SHA-2 and 2048+ bit keys OCSP support documents and guidelines GFD.125bis Private Key Protection Guidelines v1.2 IGTF Test Suite On on-line CAs and FIPS 140-2 level3 HSMs IOTA AP and RP Questionnaire

Geographical coverage of the EUGridPMA 25 of 27 EU member states (all except LU, MT) + AM, CH, DZ, EG, HR, IL, IR, IS, JO, MA, MD, ME, MK, NO, PK, RO, RS, RU, SY, TR, UA, CERN (int), DoEGrids(US)* + TCS (EU) Pending or in progress ZA, SN, TN, AE, GE

Membership and other changes Responsiveness challenges for some members JUNET CA – suspended HIAST CA – keeps running! (albeit with some connectivity issues) CA reduction More countries moved to TCS: IUCC IL, IE, … DoEGrids & Esnet decommissioned (as of 1.56 release) TCS tender ongoing, target start of overlap period summer 2014 New CA in Georgia (Tblisi), potentially a lot from Ubuntunet Self-audit review Kaspars Krampis as dedicated review process coordinator Self-audits progressing on schedule for most CAs biggest challenge in getting peer reviewers to actually review

Ongoing work items SHA-2 Guideline document revision IPv6, RAT IGTF – 10 years from now Ongoing work items

RAT challange Ursula Epting to conduct early June against all CAs Timeline taking into account time zones 4th June, Announcement of the test 18th June, 10.20 h, Start of the test 20th June, 14.50 h, Reminder for not replying CA's 21th June, 10.20 h, End of the test Request for Acknowledge receipt for each trust anchor

Furthermore 4 CA's replied later, after the official deadline Results (2) Furthermore 4 CA's replied later, after the official deadline So in the very end 13 % did not reply at all. This comes down to 11 CA's (with 'one CA' as 'one structure') 14.11.2018 Ursula.Epting@kit.edu

Resulting actions proposed 24% late (longer than 24hr), 13% non-response Some non-response reasons clarified quickly Incorrect email address in distribution – fixed Already in decommissioning mode Being located in conflict areas, at times near FEBA For others, it correlates with known behaviour  Re-challenge non- and late-responders again After 1.55 distribution release fixing mail contacts ~ December 2013 For some require in-person self-audit remediation

IPv6 status FZU runs a continuous v6 CRL monitor http://www.particle.cz/farm/admin/IPv6EuGridPMACrlChecker/ 23 CAs offer working v6 CRL but there are also 4 CAs that give an AAAA record but where the GET fails … Still 71 endpoints to go (but they go in bulk) dist.eugridpma.info can act as v6 source-of-last-resort fetch-crlv3 v3.0.10+ has an explicit mode to force-enable IPv6 also for older perl versions Added option "--inet6glue" and "inet6glue" config setting to load the Net::INET6Glue perl module (if it is available) to use IPv6 connections in LWP to download CRLs

http://www.particle.cz/farm/admin/IPv6EuGridPMACrlChecker/

SHA-2 readiness For SHA-2 there are still a few CAs not ready a few can do either SHA-2 OR SHA-1 but not both so they need to wait for software to be SHA-2-ready and then change everything at once A select few can do SHA-2 but their time line is not driven solely by us (i.e. some commercials) Their time line is driven by the largest customer base All can so SHA-2 (since non-grid customers do request SHA-2-only PKIs) it is because of these that RPs have to be ready, because when directives come from CABforum they will change, and do it irrespective of our time table! Keep in mind hardware issues, e.g. the old Alladin eTokens (32k) do not support SHA-2

SHA-2 time line https://www. eugridpma Now CA certificates in the IGTF distribution and CRLs at official distribution points should use SHA-1 CAs should issue SHA-1 end entity certificates on request CAs may issue SHA-2 (SHA-256 or SHA-512) end entity certificates on request. CAs may publish SHA-2 (SHA-256 or SHA-512) CRLs at alternate distribution point URLs 1st DECEMBER 2013 CAs should begin to phase out issuance of SHA-1 end entity certificates CAs should issue SHA-2 (SHA-256 or SHA-512) end entity certificates by default 1st April 2014 New CA certificates should use SHA-2 (SHA-512) Existing intermediate CA certificates should be re-issued using SHA-2 (SHA-512) Existing root CA certificates may continue to use SHA-1 1st October 2014 CAs may begin to publish SHA-2 (SHA-256 or SHA-512) CRLs at their official distribution points. 1st February 2015 (‘sunset date’) All issued SHA-1 end entity certificates should be expired or revoked. In case of new SHA-1 vulnerabilities, the above schedule may be revised.

On-line CA architecture - guidelines EUGridPMA will (finally) draft the "On line CA Guidelines” based on current wording in the Classic profile keep the network separation (models A or B, where A with a private link between RA and signing system preferred) Allow import of a key pair into a token (taking it out of FIPS L3 mode) as long as there is a well-documented key generation and import ceremony L2 HSMs allowed if compensatory controls are in place Keeping tokens and their systems in a solid safe-box and in a closed and locked cabinet in a monitored machine room is considered adequate Keys are permanently activated anyway, so L3 mode (separate usage functions like generation or use) is not used for our purposes Activation on boot should be manual (so the operator must be required to be present)

Identifier Only Profile IOTA AP background Guideline document Distribution Identifier Only Profile

Why? New use cases Data read-only access Portals Sharing between pre-trusted individuals or small groups Pre-vetted infrastructures (XSEDE, wLCG) The level is technology agnostic, and can be applied to X509, OIC, WebSSO federations, &c X509 specific stuff is minimal

Differentiated LoA - Collaborative identity vetting Cater for those use cases where the relying parties (VOs) already collect identity data this relying party data is authoritative and provides traceability the ‘identity’ component of the credential is not used through an authentication service that provides only persistent, non-reused identifiers traceability only at time of issuance naming be real, pseudonymous, or set by-the-user-and-usually-OK retains good security for issuance processes and systems and where the RP will have to take care of all ‘named’ identity vetting, naming and contact details

Shifting responsibilities: A new Identity Assurance Level Identity elements identifier management re-binding and revocation binding to entities traceability of entities emergency communications regular communications ‘rich’ attribute assertions correlating identifiers access control

IGTF and other assurance levels my own personal classification of identity LoAs

IOTA, a new Authentication Profile The Identifier-Only TA endorsed at IGTF All Hands https://www.eugridpma.org/guidelines/IOTA/ Unique persistent subjects, but naming can be a pseudonym or non-verified name Targets federations: so home organisation is well known, verified and traceable, some traceability to the end-user For human people and robots, not hosts or services Distinct naming of entities (no ‘auto-upgrade’ to higher LoA unless the original LoA was already high) IOTA is the new name for the Light-weight ID Vetting profile

More end-user explanations on Wednesday in ISGC Ops & security track IGTF Distribution Distribution would be through separate ‘bundle’ Next to ‘classic’, ‘mics’, ‘slcs’, and ‘experimental’ Note there never was an ‘all’ bundle for this very reason RPs will have to make an explicit choice to accept this but unclear how to distinguish users on resources based on the incoming identity LoA level Starts in 1.56 with an empty bundle Subject naming of IOTA must be different from your other CAs More end-user explanations on Wednesday in ISGC Ops & security track

IGTF Byline

IGTF in 10 years from now … Attributes and authorization becoming more important mere identity authentication is likely to become commonplace in the years to come (academic federations, commercial ID providers, etc.) But authorization, (community) assured attributes, and attribute composition are unsolved for research: the IGTF can reposition itself to address these new challenges anyway consolidation of federations in the research and academic space means that there need be less emphasis on the classical CA work

Already ongoing … AA Operations Guideline Guideline on Trusted Credential Stores IOTA as a basis for community-provided assurance

Beyond the current framing: IGTF as a brand, not an acronym Proposal IGTF be no longer considered an acronym, but be treated as a word where we can associate it with a more appropriate byline. Based on an extensive discussion by those present, it was concluded that a proposal be circulated to the other PMAs with a new 'byline': IGTF: Interoperable Global Trust Federation supporting distributed IT infrastructures for research

If you concur … Revise IGTF logo and its use on website and docs Revise the IGTF web site – already scheduled Encourage wider participation in the IGTF, in particular by relying parties and infrastructures, with an emphasis on those having operational (security) aspects and/or representing relying user communities role to play for 'catch-all' cases as well? – many of the current organisations and authorities also work 'bottom-up’ serving limited numbers of researchers across a large number of institutions (with a few people each) – this is not traditional use case for Refederations … but it is for commercial IdPs

IGTF Web Site Ongoing, some changes already done. Proposed public-facing (RP, general public) function should be separated from any internal use primary audience is RPs and 'general' public it should include a section for 'our own' integral IGTF use with links, agenda, &c add an introduction for 'humans' links to interviews and (iSGTW-like) articles about IGTF everyone to send these to <webmaster@igtf.net> add a 'news' box with current information (to change monthly or so). Make map more prominent The mini-map should link to a PMA page with a click-able map or membership list encourage TAGPMA and APGridPMA to maintain a list of their meeting that can be linked to

Upcoming meetings

EUGridPMA Agenda 31th PMA meeting Tartu, EE, 14-15 May 2014 TNC2014: 19-23 May 2014, Dublin, IE 32nd PMA meeting 8-10 September 2014 (location tbd) 33rd PMA meeting 12-14 January 2015, Berlin, DE (offered by DFN)