110 likes | 223 Views
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
E N D
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
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
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
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
Differentiated Assurance IOTA Authentication Profile EUGridPMA for EGI-TF13
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
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
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
Credential Repositories EUGridPMA for EGI-TF13
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
Summary • Review detailed summary athttps://www.eugridpma.org/meetings/2013-09/ • Questions? EUGridPMA for EGI-TF13