110 likes | 243 Vues
This document provides an update on the latest developments from the IGTF and EUGridPMA regarding the implementation of SHA-2 certificate standards and differentiated assurance profiles. Key topics include the SHA-2 timeline, the transition from SHA-1, and the introduction of IOTA Authentication Profiles aimed at enhancing trust and assurance levels for various applications. Important deadlines and responsibilities for Certificate Authorities (CAs) and relying parties (RPs) are also discussed, alongside guidance for credential repositories and associated policies.
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