Dear EUGridPMA and IGTF members, The 25th EUGridPMA and 3rd IGTF All Hands meeting is now over, and I would like to take this opportunity to again thank Ursula Epting and the Steinbuch Centre for Computing in Karlsruhe for their excellent role as hosts! The minutes of the meeting, kindly provided by David O'Callaghan and Cosmin will follow shortly, but meanwhile I would like to share with you a few of the highlights of the meeting and draw your attention to a few action items that will concern you all. The next EUGridPMA meeting will be in Lyon, France, September 10-12, kindly organized by Jean-Francois Gezou of RENATER in collaboration with CCIN2P3. But now, the summary: - The SHA-1 Risk assessment is ongoing, but it is also clear that, especially on the software and RP side, more testing needs to be done in order to estimate the risks of disrupting the infrastructure and the impact of moving to SHA-2 now. However, the only real way of finding out which things break, is by actually doing it - and moving early and having the software 'break' in Jan 2013 may in the long run cause less pain for the users than waiting until the last moment and then having to hurry - and be off-line for weeks on end while we try to reconstruct the trust fabric. As for the Risk Assessment document itself: several new elements were identified and added to the ToC. The new version of the document (0.3) is on-line and linked from the agenda pages. We now need *active* contributors that *write* substantive elements of the actual risk assessment: o in section 4, detailing the course of action for the IGTF and the CAs: what will be do once SHA-1 is broken, and what actions do the *CAs* need to take o in section 5, detailing the impact on the operational (grid) infrastructure: which elements are likely to break when we (suddenly or scheduled) move to SHA-2, and how will RPs and subscribers be impacted o in section 6 (new): which elements need to be tested beforehand Action items for the CAs: o 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. o This implementation of SHA-2 should encompass BOTH end-entity certs AND CRLs o 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). o There should be user explanatory documents describing the move to SHA-2 o From Jan 2013 onwards, users SHOULD have the capability of requesting SHA-2 based certs from all CAs o CAs MAY consider shortening the validity period for EECs that are still SHA-1 based after 1-1-2013, so that the subset date for SHA- 1 (March 2014) is maintained. This will also encourage users to move to SHA-2. o 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. Action items for RPs: o the actual use of SHA-2 certs and CAs should be tested for every software release from now. So EGI should do the certification and Staged Roll-out of their UMD 2.0 distribution with SHA-2 based certificates. The EGI RT ticket #3078 has been updated for this issue. Jules will similarly collect this info from PRACE-RI and its software providers. o At least SHA-256 and SHA-512 should be tested o There are 'test CAs' available for the cerification process (e.g. the OpenID based one by NCSA which is already in the experimental IGTF distribution area), and there are several IGTF CAs that will be willing to issue dedicated test certs off their production instance. Remember that the US Federal Govt put a ban on using SHA-1 in their tender requirements, and that was the only way software vendors started to move... we need to maintain the pressure. So Jan 1, 2013 it will be - of course unless SHA-1 is broken before that time! - The Attribute Authority Operations guidelines were updated. Please review version 1.1 at http://www.eugridpma.org/guidelines/aaops/ and the modifications made during the meeting at http://agenda.nikhef.nl/getFile.py/access?contribId=9&resId=2&materialId=0&confId=1890 - The IPv6 Launch Day is imminent, and there will be a more pressing need for IPv6 soon. For this, all CRL distribution points and URL should also be accessible over IPv6, and have DNS names that also refer to an IPv6 ("AAAA") record. The presentation in ISGC2012 by Marek Eliáš (see agenda page), shows that more and more CAs are enabling IPv6, but not enough yet: there are only 13 out of 96 that are v6 capable. 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. PLEASE deploy IPv6, and make sure it is a production-quality service: v6 capable clients will prefer the AAAA record if it is there, and may fail if it is now. The CRL monitoring service will use IPv6 when possible. - CAs should start deploying OCSP responders, to allow for more timely revocation but also to (in the future) allow the CRL download frequency to go down and lessen the load on servers. All IGTF CAs SHOULD provide a production OCSP responder by JAN 1, 2013 To enable this to happen, the following actions will be taken: o 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 o CABForum will (in about 3+ month) produce two whitepapers on OCSP: one for service operators and one for RP clients o All CAs should start deploying OCSP responders now, and setup a server for that o authorityInfoAccess OCSP endpopint extensions should be included in all EECs issued after Jan 1, 2013 o from then on, AIA in client certs will be used, and after 400 days all EECs should have it. o 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. o 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'). - There was extended discussion on the introduction of 'well organised' communities of subscribers (communities which are called 'RAs' in the context of for example DoEGrids and the TAGPMA). These communities could benefit significantly from having their own well-defined 'Registration Practices Statement' (RPS), and by also keepting their own records and vetting data gain the ability to 'outlive' their CA issuing providers and even migrate between CAs with only limited impact to the individual subscribers. The RPS in general is beneficial to all of the IGTF community as well, allowing for good documentation of best practices and harmonization thereof amongst the CAs. The presentation by Scott, as well as the email from Jens on the list, contain additional thoughts about the RPS. 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. However, in the end an organised community whose RPS has already been studies as part of the accreditation of one CA may move to a different accredited CA without causing a lot of new accreditation work. - The HellasGrid and SEE-GRID/EGI CatchAll CA performed their self-audit, and a new CP/CPS and some changes in practices will be forthcoming soon. The peer reviewers are Edgars and DavidG. - The January meeting is tentatively scheduled in Abu Dhabi - however we should make sure that enough members actually can come there and will be able to get funding to go there. Enough people need to be able to go. An alternative offered would be Florence, Italy, hosted by Roberto and INFN. A poll will go out shortly asking the members to commit to actually going to either place - making sure we go somewhere that is most effective for the PMA - In some cases, RAs are more persistent and organised than the CAs in their contry, which is evident now for example in Australia and NZ, where the community persists but the CA may close down the catch-all function. 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 o the RA has retained all documents and vetting data o the existing CA will continue to operate in a 'transitionary' mode, so there is an authentication point for the RA's subscribers o the documentation and vetting processed for the old and new CA are compatible o 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. - The Egyptian Universities Network EUN presented the new EG-CA, which is a grid-specific CA but extremely well integrated with the both the academic community as well as the national PKI initiatives. The review is almost complete, and both reviewers (Usman and Feyza) will continue with the operational review and assess the latest version. This process is expected to complete in a few weeks, after which accreditation ensues over email. It is likely that EUN EG-CA will be included in the end-of-June IGTF distribution. - Roberto presented the new IGI CA series. Although the state of IGI itself is in heavy flux, the software development needed for the on-line portal CA continues. The service conforms to the architecture assessed earlier by the PMA in Marrakesh, and should address all concerns. Once the test setup is there, also controlled pen-testing of the system should show that there are no obvious holes left. At the same time, this presents a nice central servce, which is outside the regular scope of most CAs. Modifying or creating a dedicated CP/CPS for such an on-line portal CA is complicated, so this IGI CA has something unique to offer that could be turned into a multi-national 'service'. The possibilities (both technically and from a business point of view) of turning this into a service offering should be very interesting. - Jens reviewed the Private Key Protected guidelines, and identified most of the issues. A new version will be started on a new Wiki page, and Jens will provide the first text version *before* OGF35 in Delft, where it will be discussed in the IGTF session. - Also have a look at Scott's presentation on Revocation enhancements on PKI and the TLS/SSL alternatives. The presentations are an excellent overview, and if you did not attend the meeting, please read through them! - The GDF.125 bis 'Grid Certificate Profile' was reviewed and several changes proposed. The new draft version is linked to the IGTF agenda pages and will soon be uploaded to the OGF document editing site. Please review the changes, and join the CAOPS session on Monday June 18 in Delft during OGF35 (and sign up for OGF!) - Willy will be the co-chair of the IGTF Risk Assessment team, which will allow us to run more response challenges against all the CAs (expected: 2 per year), as well as making sure that the RAT internal communication structure with the encrypted email list remains up to date. - The *dates* for all meetings have been fixed: 10-12 September 2012: Lyon, FR [RENATER/CCIN2P3] 14-16 January 2013: Abu Dhabi, UAE [ANKABUT]/Firenze, IT [INFN] 13-15 May 2013: Kyiv, UA [NTU] 9-11 Sept 2013: Bucharest, RO [ROSA] I would like to thank all who participated in-person and over the videolinks, and see you all at OGF35 or in Lyon! Best regards, David Groep.