1 / 22

Geographical coverage of the EUGridPMA

EUGridPMA CAOPS-WG and IGTF Issues June 2012 Delft, NL David Groep, Nikhef, EUGridPMA, EGI and BiG Grid. Geographical coverage of the EUGridPMA. 25 of 27 EU member states (all except LU, MT)

scout
Télécharger la présentation

Geographical coverage of the EUGridPMA

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. EUGridPMA CAOPS-WG and IGTF IssuesJune 2012Delft, NLDavid Groep, Nikhef, EUGridPMA, EGI and BiG Grid

  2. Geographical coverage of the EUGridPMA • 25 of 27 EU member states (all except LU, MT) • + AM, CH, DZ, HR, IL, IR, IS, JO, MA, MD, ME, MK, NO, PK, RO, RS, RU, SY, TR, UA, CERN (int), DoEGrids(US)* + TCS (EU) Pending or in progress • ZA, SN, TN, EG, AE

  3. Agenda • 26rd EUGridPMA meeting10-12 September 2012, Lyon FR • 27rd EUGridPMA meetingAbu Dhabi, 14-16 January 2013 • 28th PMA meetingKyiv, UA, 13-15 May 2013 • 29th PMA meetingBucharest, RO, 9-11 Sept 2013

  4. Karlsruhe meeting results and issues • https://www.eugridpma.org/meetings/2012-05/ • SHA-2 migration • AAOPS Guidelines available – to be applied now • IPv6 support • OCSP • RA Practice Profile • RA migration to a new CA** • GFD.125bis

  5. Why the Risk Assessment? • hash algorithms (like SHA-x, MDx, RIPE-MD) are basis for cryptographic integrity of all PKI certs • SHA-1 most commonly used, but weaking rapidly • ‘strength’ is the inherent entropy of the digest value • strength is decreasing due to clever cryptanalysis • good advice (NIST) has deprecated SHA-1 in 2010 • more attacks are forthcoming • but moving to new hash algorithms (SHA-2) requires ubiquitous software support • which needs to be in all M/W used by IGTF RPs • but which is not (yet) there

  6. Weighing the risks • assess the current state of the attacks on SHA-1 • gauge probability of successful exploit in our PKI • document possible remediations • that can be taken to preserve integrity of the IGTF • for various attack scenarios and ‘complexity levels’ • and consider the impact on our RP operations • which things may break? • how severe is a such breakage and balance these risks against each other • in an orderly fashion • ahead of time! Risk Assessment Doc

  7. ToC for https://www.eugridpma.org/review/sha1

  8. SHA-2 Decisions and Road Forward • ALL IGTF CAs should have or get the capability of issuing SHA-2 based certificates. All CAs MUST implement this a.s.a.p, and REPORT on the implementation of SHA-2 issuing capabilities by October 1, 2012. • This implementation of SHA-2 should encompass BOTH end-entity certs AND CRLs • CAs should schedule to start issuing SHA-2 based certs by January 1, 2013 (only if by December 2012 it is clear that everything will still break in more than one infrastructure may some CAs consider not moving). • CAs MAY consider shortening the validity period for EECs that are still SHA-1 based after 1-1-2013, so that the sun-set date for SHA- 1 (March 2014) is maintained. This will also encourage users to move to SHA-2.

  9. SHA-2 decisions – the user end • There should be user explanatory documents describing the move to SHA-2 • From Jan 2013 onwards, users SHOULD have the capability of requesting SHA-2 based certs from all CAs • Since software should accept at least SHA-256 and SHA-512 out of the SHA-2 family of hashes. To ensure that will happen, some CAs should use SHA-256 and others SHA-512, so there will and should be no IGTF guidance as to which one to choose.

  10. IPv6 use at the CA end • All CAs should have an IPv6 capable end-point for their CRL (and OCSP responder), preferably BEFORE OCTOBER 1, 2012! • To encourage CAs to enable IPv6 and get the proper DNS records set, monthly reminders will be sent if your CA does not offer the CRL over IPv6 (or lacks the AAAA records). After October 1st, these reminders will come weekly. • Get your DNS servers on IPv6 as well • And, yes, I know the IGTF itself does not have that yet, but I’m looking into alternatives for Enom Inc.

  11. RA Migration and RPS

  12. RA Practices Profile • 'well organised' communities of subscribers • which are called 'RAs' in the context of e.g. DoEGrids • could benefit significantly • from having their own well-defined 'Registration Practices Statement' (RPS) AND • keeping their own records and vetting data and gain the ability to 'outlive' their CA issuing providers and even migrate between CAs with only limited impact to the individual subscribers. • and contract issuing CAs in competition • However, this is *not* going to result in any change in the IGTF structure itself, nor in additional 'membership categories' for PMAs. It is the CAs that are anyway responsible for ensuring proper RA practices, and as such they get to defend and present RPS practices. All communication will be and remain through the CAs.

  13. RA migration: the practical use case • In this case, the community RA in NZ actually is well organised and has retained all documentation, so a migration of the entire community to the ASGCCA Catch-All function would sole the problem. The IGTF discussed the options and since • the RA has retained all documents and vetting data • the existing CA will continue to operate in a 'transitionary' mode, so there is an authentication point for the RA's subscribers • the documentation and vetting processed for the old and new CA are compatible • the RA will transfer audit capability for their documents to the new RA the users will be allowed to migrate from the old to the new CA without a new F2F vetting step, since the documentation remains available, and through authenticating with the 'old' credentials subscribers that re- apply to the new CAs can link their new request to the original vetting data. The new CA will issue in its own name space, so the full DN of the subscribers will change. This is, however, well solvable in the VO registration systems today, and common practice.

  14. OCSP – Part II

  15. OCSP conclusions IGTF CAs SHOULD provide production OCSP responder JAN 1, 2013 To enable this to happen, the following actions will be taken: • those that run OCSP responders (either the regular 'heavy' ones or the precomputer 'light-weight' OCSP responses that can be cahed and served over a CDN) will send some documentation • CABForum will (in about 3+ month) produce two whitepapers on OCSP: one for service operators and one for RP clients • All CAs should start deploying OCSP responders now, and setup a server for that • authorityInfoAccess OCSP endpopint extensions should be included in all EECs issued after Jan 1, 2013 • from then on, AIA in client certs will be used, and after 400 days all EECs should have it.

  16. OCSP conclusions • the server(s) running the OCSP responders should be highly available, and have controls around them to make sure they are secure and safe. If you use a signing OCSP responder, it should have an OCSP signer cert which is reasonably short-lived , and preferably hosted on an HSM. • pre-computed responses should be preferred, and can be signed beforehand off the normal issuing CA directly (making them smaller and easier to process) Client will interpret the OCSP responses and do the 'right' thing (known should be equal to 'bad').

  17. But: what to do at the client end? Experiments by KrysztofBenedycak (quoting from his mail): “I did a small experiment using all OCSP responders defined in all CA certs from the IGTF distro + one from big guys, i.e. VeriSign. There is only few of them: http://EVSecure-ocsp.verisign.com -> OK http://ocsp.usertrust.com -> OK https://ocsp.quovadisoffshore.com -> OK http://ocsp.digicert.com -> OK http://ocsp.cesnet-ca.cz/ -> no luck, 4xx HTTP error https://ca.grid.arn.dz:2560 -> no luck, connection timeout Results: For all that I managed to query and get a positive answer I've used the same settings and get the same results, i.e.: • I've used unsigned request, however signed one was also accepted • anonymous TLS in case of https (for quo vadis) • nonce extension was not honored, never it seems that all responders create responses once per day (or so) as I always had "producedAt" several hours in the past and it was constant.”

  18. The current proposal by Krysztof “Solely basing on this experiment, here are defaults and assumptions that I'm going to implement. Any comments are welcomed … • use in request or require response nonce? NO, not supported by servers • hash algorithm to be used in requests (for hashing checked cert issuer and key, not the one used for request signing) • fixed to SHA1 • do we need to make it configurable? Are there any SHA2 hashes required/supported? and if the answer is yes: is there any chance that admins will be able to guess a better default value for the hash? • server's authentication in case of https responders • don't support this at all, i.e. use https for connection encryption only, as it would be quite hard in general (hen and egg problem) • alternatively we can check the responder's SSL certificate simply, by requiring it to be the same as the certificate of the authority which signed the later received response. But does such effort makes sense?

  19. More from Krysztof ... • signing of requests --> no; seems to be ignored by servers • client's authentication to the responder in case of https --> as above • no other extensions are going to be supported • OCSP answer for a particular certificate will be cached -> by default up to 24h -> cache time will be configurable

  20. GFD.125bis

  21. Grid Certificate Profile Update • Document URLhttps://forge.ogf.org/sf/go/doc16402 • version 3 with track changes • One addition made based on mail from Roberto • Can we sign off on this version? • Has anyone looked at it?

  22. Agenda • 26rd EUGridPMA meeting10-12 September 2012, Lyon FR • 27rd EUGridPMA meetingAbu Dhabi, 14-16 January 2013 • 28th PMA meetingKyiv, UA, 13-15 May 2013 • 29th PMA meetingBucharest, RO, 9-11 Sept 2013

More Related