EUGridPMA Status, current trends and some technical topics March 2013 Taipei, TW David Groep, Nikhef...

EUGridPMA Status, current trendsand some technical topics

March 2013Taipei, TW

David Groep, Nikhef & EUGridPMA

APGridPMA Taipei 2013 meeting – 2David Groep – [email protected]

EUGridPMA & ‘Rome Meeting’ Topics

EUGridPMA (membership) status

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/


Milan Sova

1962-2012


http://milansovacesnet.wordpress.com/


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)

TCS


Membership and other changes

Grid-Ireland The Irish government suddenly withdraw all support for

distributed computing by mid-2012,leading to the end of all ‘grid’ services run by Grid-Ireland and TCD

Grid-Ireland CA operations stopped December 2012 Remained of user community now served by TCS

TCS changes Comodo has very ‘interesting’ view of CABforum requirements ‘OV’ certs (which the TCS eScience SSL certs were) now require

phone calls to numbers that Comodo collects in intractable ways Introduced ‘DV’ certs to deal with this issue

/DC=org/DC=terena/DC=tcs/OU=Domain Validated/CN=fqdn Naming of OV certs still needs to be sorted, but will change Lets hope we can leave eScience Personal unchanged CAs are changing towards TCS (IUCC, BE, …)


SHA-2

Time lineStatus


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.


SHA-2 readiness

For SHA-2 there are still a few CAs not readya 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 Alladin eTokens (32k) do not support SHA-2


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…


ONGOING WORK ITEMS

MICS Kantara LoA2HSMsOCSP and OGF CAOPS-WGPKP Guidelines, Test Suite, IPv6, RAT


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


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


OCSP support: OGF & IGTF documents

Two documents to guide its introductionprofile 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 ;-)


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!


IGTF Test Suite

Software developers want to do real-life testing!Actions to get to a comprehensive suiteeach 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/") certeach CA to indicate some edge cases for their CA (use of colons, dashes, weird characters) and parameter space of the subject namingknown troublesome certs should be includedrequirements developed on the Wiki

https://wiki.eugridpma.org/Main/IGTFTestSuite now has some samples and conditions


IPv6 status

FZU runs a continuous v6 CRL monitor http://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


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


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


LIGHT-WEIGHT IDENTITY VETTING ENVIRONMENT AP


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


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


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


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

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


UPCOMING MEETINGS


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 Hands

La Plata, ArgentinaNovember* 2013

EUGridPMA Status, current trends and some technical topics March 2013 Taipei, TW David Groep, Nikhef...

Documents

Transcript of EUGridPMA Status, current trends and some technical topics March 2013 Taipei, TW David Groep, Nikhef...