1 / 22

‘Rome Meeting’ and beyond

This article discusses the timeline for adopting SHA-2, CA readiness, MICS Profile, OCSP support, private key protection, IGTF Test Suite, IPv6, and online CAs.

kdeberry
Download Presentation

‘Rome Meeting’ and beyond

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. SHA-2, current trendsand some technical topicsMarch 2013Taipei, TWDavid Groep, Nikhef & EUGridPMA

  2. ‘Rome Meeting’ and beyond • SHA-2 time line • CA readiness for SHA-2 and 2048+ bit keys • MICS Profile and Kantara LoA-2 • OCSP support documents and guidelines • Private Key Protection Guidelines v1.2 • IGTF Test Suite, IPv6 • On on-line CAs and FIPS 140-2 level3 HSMs • Risk Assessment Team • Towards an LoA 1.x "light-weight identity vetting" AP https://www.eugridpma.org/meetings/2013-01/

  3. SHA-2 time line (materially ~ the old one) • October 2012 (‘today’) • 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 • August 2013 (may need to move to ~ 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 • 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 • September 2014 • CAs may begin to publish SHA-2 (SHA-256 or SHA-512) CRLs at their official distribution points. • October 2014 (‘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.

  4. 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. the 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. theold AlladineTokens (32k) do not support SHA-2

  5. A forward look: sudden end of MD5! • Some software stacks (Mozilla NSS 3.14+distributed as part of e.g. RHEL6U4) are now disabling MD5! • Will create a nice mess, with several large CA roots still MD5 (even in EL6U4) • At this point, stuff will actually start breaking…

  6. MICS Kantara LoA2 HSMs OCSP and OGF CAOPS-WG PKP Guidelines, Test Suite, IPv6, RAT Ongoing work items

  7. MICS Identity vetting • The initial vetting of identity for any entity in the primary authentication system that is valid for certification should be based on a face-to-face meeting and should be confirmed via photo-identification and/or similar valid official documents. • Sufficient information must be recorded and archived such that the association of the entity and the subject DN can be confirmed at a later date • … From the information stored in the IdM it must be possible to determine if the requestor’s identity has originally been validated using all initial vetting requirements described above.

  8. MICS and Kantara LoA2 • "A primary authentication system that complies with the Kantara Identity Assurance Accreditation and Approval Program at at least assurance level 2 as defined in the Kantara IAF-1400-Service Assessment Criteria qualifies as adequate for the identity vetting requirements of this Authentication Profile.“ • This clarifies the "should" mentioned several times in the second line of paragraph 3.1, as we have now interpreted it several times in this particular way (TCS eScience Personal, CILogon Silver).

  9. HSMs at level 3 for on-line CAs “Inspired by the idea of NIIF for buidling an on-line CA based on a low-power Raspberry Pi and a level-3 HSM in USB format, a discussion emerged on whether it is possible to have enough compensatory controls around a level-2 HSM to make the risk comparable to the current off-line CA or level-3. It is not entirely clear which elements of level-3 improve the risk resilience when compared to an off-line classic CA.” We think it is worthwhile doing the risk analysis compared to the off-line classic CA, and if the risk is comparable allow the use of L2 HSM or eTokens in conjunction with compensatory controls like a safe. We propose to discuss this with the TAGPMA and APGridPMA and have a discussion at the IGTF All Hands in La Plata (October 2013).

  10. OCSP support: OGF & IGTF documents Two documents to guide its introduction • profile and guidance of RFC5019 light-weight OCSP for CAs • CAs already deploying full RFC 2560 are not the audience • https://wiki.eugridpma.org/Main/OCSPProfileForIGTFCAs • 'best practices' guide for RPs and their software developers in using OCSP information • https://wiki.eugridpma.org/Main/OCSPDeploymentGuidelines • Trade-off between pre-computation or on-demand signing depends on number of certs issues and number of requests (choice it not trivial ;-)

  11. PKP Guidelines v1.2 • New text is now available at • https://wiki.eugridpma.org/Main/PrivateKeyProtectionLifeCycle • https://wiki.eugridpma.org/Main/PrivateKeyProtectionRevised • structure is different, but the currently allowed use cases are covered by the new text • companion document on how to secure key stores (be they run by NGIs, CAs, home organisations, or anyone) should also be written. We expect the key stores to be run securely!

  12. IGTF Test Suite Software developers want to do real-life testing! Actions to get to a comprehensive suite • each CA to send a URL to or a sample of end-entity certs, at least personal cert and server cert, and depending on the CA also a robot cert and/or a 'service' ("blah/") cert • each CA to indicate some edge cases for their CA (use of colons, dashes, weird characters) and parameter space of the subject naming • known troublesome certs should be included • requirements developed on the Wiki • https://wiki.eugridpma.org/Main/IGTFTestSuite • now has some samples and conditions

  13. IPv6 status • FZU runs a continuous v6 CRL monitorhttp://www.particle.cz/farm/admin/IPv6EuGridPMACrlChecker/ • 22 CAs offer working v6 CRL • but there are also 4 CAs that give an AAAA record but where the GET fails … • Still 72 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

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

  15. IGTF RAT • Ursula Epting will be coordinating the communications challenges to the CAs and the internal (encrypted) mailing list • Please make sure the registered emergency contacts are up to date in the Distribution • Contact your PMA chair/TI to get this fixed if needed

  16. Light-weight Identity Vetting Environment AP

  17. Light-weight ID vetting environment AP • Cater for those use cases where • the RPs (VOs) already collect identity data • this RP (VO) data is authoritative and provides traceability • the ‘identity’ component of the credential is not used • through an AP where the authority provides only • persistent, non-reused identifiers • traceability only at time of issuance • naming be real or pseudonymous (discussion on going!) • good security for issuance processes and systems • and where the RP will have to take care of • subscribers changing name often (in case traceability at issuing authority is lost) • all ‘named’ identity vetting, naming and contact details

  18. Live AP use cases • Infrastructures where all users have a strong ‘home site’ that anyway has independent out-of-band vetting processes • PRACE RI, XSEDE, • Infra where the community does strong independent vetting • to be decided, mainly by the resource providers! • NOT useful for • Communities that rely on the name to enrol people • Communities that do not keep auditable records • RPs that support loosely organised communties • RPs that need independent authoritative names • LoA higher than Kantara 1, but much lower than 2

  19. https://wiki.eugridpma.org/Main/LiveAPSecuredInfra

  20. New Authentication Profile • The AP is currently being drafted • https://wiki.eugridpma.org/Main/LiveAPSecuredInfra • Many things to be decided • Need for HSM FIPS 140-2 level 3 or 2? • What audit requirements needed? • Real or pseudonymous naming • Disallow host/server SSL certs? • 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

  21. Upcoming meetings

  22. EUGridPMA (IGTF) Agenda • TAGPMA + SCI meetingBoulder, CO, USA, 6-8 May 2013 • 28th PMA meetingKyiv, UA, 13-15 May 2013http://www.eugridpma.org/meetings/2013-05/ • 29th PMA meetingBucharest, RO, 9-11 Sept 2013 • APGridPMA meeting date t.b.d. • IGTF All HandsLa Plata, ArgentinaNovember* 2013

More Related