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

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

3. 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

4. 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

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

6. 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, h, Start of the test
20th June, h, Reminder for not replying CA's
21th June, h, End of the test
Request for
Acknowledge receipt
for each trust anchor

7. 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')

8. Resulting actions proposed
24% late (longer than 24hr), 13% non-response
Some non-response reasons clarified quickly
Incorrect 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

9. IPv6 status
FZU runs a continuous v6 CRL monitor
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 v 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

11. 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

12. 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.

13. 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)

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

15. 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

16. 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

17. 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

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

19. IOTA, a new Authentication Profile
The Identifier-Only TA endorsed at IGTF All Hands
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

20. 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

21. IGTF Byline

22. 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

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

24. 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

25. 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

26. 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
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

27. Upcoming meetings

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