1 / 11

IGTF & EUGridPMA status update

IGTF & EUGridPMA status update. SHA-2 – and a tittle more. David Groep, Nikhef and NL-NGI for EGI global task O-E-15 This work is supported by EGI-InSPIRE under NA2 and SA1.2. davidg@nikhef.nl, orcid.org/0000-0003-1026-6606 . IGTF developments. From Recent IGTF meetings

thi
Download Presentation

IGTF & EUGridPMA status update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IGTF & EUGridPMAstatus update SHA-2 – and a tittle more David Groep, Nikhef and NL-NGI for EGI global task O-E-15 This work is supported by EGI-InSPIRE under NA2 and SA1.2 davidg@nikhef.nl, orcid.org/0000-0003-1026-6606

  2. IGTF developments From Recent IGTF meetings • Slightly revised SHA-2 time line • IOTA Authentication Profile: what do you, the Relying Parties, actually need? • Credential Repositories • Link to complete list of topics and discussionshttps://www.eugridpma.org/meetings/2013-09/ EUGridPMA for EGI-TF13

  3. SHA-2 time line agreed • Now • CA certificates in IGTF distribution & CRLs at official distribution points should use SHA-1 • CAs should issue SHA-1 end entity certificates by default • 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 1st October 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 • Some Cas will defer transition till after New Year for helpdesk/support issues • 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 (not: must!) be expired or revoked. In case of new SHA-1 vulnerabilities, the above schedule may be revised. EUGridPMA for EGI-TF13

  4. SHA-2 readiness Introduction of SHA-2 will be gradual • Newly issued certificates will be mostly SHA-2 • Takes up to 13 months to roll over • Some subscribers will continue to request SHA-1 for a while • Some CAs are SHA-2 capable, but their migration time line is not driven solely by us (i.e. some commercials) • Their time line is driven by the largest customer base • All can do SHA-2 already – some do on request(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 quite irrespective of our time table! EUGridPMA for EGI-TF13

  5. Differentiated Assurance IOTA Authentication Profile EUGridPMA for EGI-TF13

  6. Redistributing responsibilities • Subject (ID) based • EffectiveLoA is retained • For given actions, resources, and acceptable residual risk, required ID assurance is a given • can shift ‘line’ in identity trust level • Action (app) based • More constraint actions can lower need for identity LoA • (J)SPG VO Portal policy did just that: 4 levels of actions • Resource (value) based • e.g. access to wireless network does not pose huge risks, so can live with a lower identity LoA (eduroam) Towards differentiated collaborative LoA

  7. IOTA AP Trust difference • Provide only (opaque) identifiers, nothing more • Easier to obtain for users, but must be complemented by RP for traceability and integrity …3,4 LoA 2: 1, 2-factor vetting, verified traceability, externally audited as matter of course 2 MICS, Classic: identified naming, traceability, longer-term, limited auditing VettingLoAscale SLCS: identified naming, point-in-time traceability, time-limited RP task Live AP: unique identification, no identity , limited traceability LoA 1: verified email address with mail-back 1 * somewhat my personal view … sorry for bias LoA 0: ‘like conventional unsigned email’ EUGridPMA for EGI-TF13

  8. Moving the bar towards differentiated assurance http://wiki.eugridpma.org/Main/IOTASecuredInfraAP • IOTA AP assurance level is different, and rest must be taken up by somebody else • Consider questions about • Real names and pseudonyms • Enrolling users in a community • Keeping audit records in the VO • Auditability and tracing • Incident response • Come to session on Identity Management! • 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 Towards differentiated collaborative LoA

  9. Credential Repositories EUGridPMA for EGI-TF13

  10. Credential Repository plug • Did you know … • … that the IGTF Private Key Protection guidelines allow for institutional and national credential repositories, to manage user keys?http://www.eugridpma.info/guidelines/pkp/ • … the Credential Store Operations Guidelines gives best current practice for running a trusted store?http://www.eugridpma.info/guidelines/trustedstores/ • … software to build (federated) credential repos is there, such as MyProxy? • … there are easy ways to get (PKI) certificates through on-line CAs or the TERENA TCS in many countries? EUGridPMA for EGI-TF13

  11. Summary • Review detailed summary athttps://www.eugridpma.org/meetings/2013-09/ • Questions? EUGridPMA for EGI-TF13

More Related