Dear EUGridPMA and IGTF members, The 24th EUGridPMA meeting in Ljubljana is now over. It was a great success, wonderfully hosted by Jan Jona Javorsek and the Josef Stefan Institute in Ljubljana. Thanks also to the Slovenian NGI and Arnes for supporting the event! Full minutes of the meeting will follow shortly, but meanwhile I would like to give you a summary of some of the highlights of the meeting. You can read this at your leisure, accompanied by the slides that are available on the agenda page at The next EUGridPMA meeting will be in Karlsruhe (Germany) on May 7-9. And since the EUGridPMA is due for hosting the IGTF All Hands meeting, we will use the Karlsruhe meeting for this. Thanks for Ursula Epting and the team at KIT for hosting the next meeting! Best regards, DavidG. So now ... The Summary ---------------------- * the Authorization Operations working party has issued its first version of the "Guidelines for Attribute Authority Service Provider Operations" It details operational security guidelines for attribute authority service providers, who can use this document to either look at their own best practices, or to have themselves assessed against them -- It will however not be the PMA 'accrediting' any of these: this task is left to others, maybe NGIs or major relying parties. Read the new full text at: https://grid.ie/eugridpma/wiki/AA_Profile (but nothing should be inferred from the name of the page ;-) which will shortly be posted to the guidelines section of the EUGridPMA web site. * The Classic AP draft version 4.4 was updated with the following changes: - the general architecture section (2) was shortened and all non-technical matters moved to the EUGridPMA Accreditation Guidelines - move to 2048-bit EEC keys as minimum (and clean up section on HSM renewals correspondingly) - recommend new CAs to use a 4096-bit CA key - maximum EEC life time to become 395 days This is now a draft and we hope TAGPMA and APGridPMA approve of these changes as well. We on purpose tried to keep them minimum, and not fiddle with the rest of the text. We know it can be improved, but let's do that in the next iteration! The standard page for this AP: contains the v4.4 draft (with and without track changes) at the bottom! * Accreditation Guidelines have been updates with section 1.1, absorbing the text formerly in the Classic AP section 2. The new accreditation guidelines v2.1 have been approved. * We propose that the minimum key length of end-entity certificates in the Classic AP is raised to 2048 bits RSA-equivalent strength This is in the draft of v4.4 (making the 3-year renewal for 1024 bits HSM-based keys statement obsolete as well) In this we are the last to follow all other major expert bodies... * Participation in the RAT, the Risk Assessment Team, would be highly appreciated, specially if you can devote a few cycles to the coordination or the effort and running the communications challenges. Please contact Jens Jensen to volunteer. * IGTF Release Schedule The EGI Staged Roll-out team prefers a bit more time to test new releases, and doing that /after/ the IGTF release would confuse sites. So the PMA agreed with the following proposal - the EGI SR team will get access to the pre-releases which are now distributed to the IGTF exclusively - these pre-releases ought to be stable AT LEAST 1 WEEK before release - the release is still on the last Monday of the month - ALL authorities must submit modifications AT LEAST 10 days in advance of this, so on the FRIDAY a bit more then one full week BEFORE the end of the month! Changes coming in after that date should move to the next release, one month later. * The requirements formulated in the IGTF Wish List have been endorsed by EGI to be fed to their software providers (EMI and IGE, mainly). A few issued were raised: - for authorization decisions based on OIDs, and exhaustive OID list was requested. We cannot give this list, since CAs can add relevant OIDs themselves. For the most interesting OIDs (those of 1SCPs), a dynamic list can be retrieved from the OID registry. It is up to the policy administrators to decide which OIDs will be used, and a policy decision engine should be able to deal with any OID. Milan Sova has all the details - migrating to SHA2 appears to be non-trivial, since it is convoluted with a move to RFC3820 style proxy certs. There is still a bit of software out these that does not support RFC3820 proxies, and using libraries that support SHA-2 would necessitate the exclusive use of RFC proxies. So there is a deadlock here. The presentation by DaveK (from Maarten Litmaath) explains the dependencies and some wLCG considerations on the time line. We understand the complications, but at the same time the risk of using SHA-1 is increasing as more cryptanalysis is done. Basically, it would not be beneficial to subscribers or RPs to start using SHA-2 now, knowing that many things will break, and a new risk analysis is needed, taking the deployment risks into account. But at the same time the RAT and IGTF must develop a "Plan-B" in case SHA-1 is suddenly broken and we need to move to SHA-2 anyway, regardless of other consequences. With regards to the introduction of SHA-2 the PMA now proposes to the IGTF the following: - the RAT does a risk assessment of staying with SHA-1, in light of current cryptanalytic developments and the deployment issues identified - if SHA-1 is broken, the RAT makes an immediate assessment based on the integrity of the subscriber certs, and will act regardless of RP deployment consequences - we will NOT rpt. NOT recommend CAs to move to SHA-2 for production use until the risk assessment completes - noting that this provision ends in January 2013 - individual CAs MAY start issuing SHA-2 based certs on their own accord anyway (e.g. for testing, or to satisfy other needs) - the date by which SHA-2 production certs may be issued will be NO LATER than January 2013 (and it is likely we will RECOMMEND CAs to move then, since it will take another 395 days to get rid of SHA-1 in a reasonable way) - additional digest algorithms, in particular the successor to SHA-2 which is chosen this year, may ALSO be used in production certs in January 2013, but will NOT be introduced before SHA-2 is recommended for general use Note that SHA-2 is a family, so all of SHA256, SHA384 or SHA512 may be encountered in production certs following this date! * The NIST competition for a new hash algorithm (the successor of the SHA-2 family) is completing in half a year. The new hash family (let's call it "SHA-3") will be available in implementations by the end of this year. RPs may expect the use of SHA-3 based certs early 2013, although not before SHA-2 is released for general use. We urge software developers to be flexible in the use of cryptography, rely on upgradable (dynamic) libraries and not tie to a specific hash, key algorithm or key size. * Sending a wish list may trigger some 'reverse' wishes as well. All CAs are kindly asked to stop using emailAddress (or Email, or "E") attributes. Not only in subject names, but also in their issuer name. There are three CAs (IUCC, IHEP, APAC) that still have those. Eric Yem (APGridPMA) confirmed that APAC and IHEP will roll over to a new issuer name in due time (takes 18 months), and it is expected that all of the IUCC activities will be moved to the TCS anyway in a 3+month time frame, obviating the need to change the IUCC CA certificate. And if you wonder why: GFD.125 explains the reason for not wanting Email! * Alexey presented the CERN computer centre provisioning scenario. Usually opaque to the CA since it's sone by the subscriber, the CERN CA can actually 'see inside' the process and presented a secured deployment scenario which includes the interaction with the CA as well. It is a common problem faced by many CAs: bulk requests for several thousand subjects that need to be issued and re-keyed yearly. An important element is the chain of responsibility for each certificate, and as long as the chain of responsibility is clear is it positively received. It would be good to have not only the (abstract) description in the CP/CPS but also a more technical document describing the controls in place. From this it may be generalised and be useful to more CAs. This will however not be blocking for this implementation. The next steps are also laid out: - first send the new CP/CPS followed b the technical document - Jens, Reimer and Milan will comment really quickly on these documents - this entire process should complete and lead to an accepted set within 2 months. - high-level requirements can then be extracted from these, which should lead to a quick requirements document thereafter. However, this high-level document will not be in the critical path for the deployment of the new solutions at CERN. * The Private Key Protection guidelines were reviewed by Jens. It is important to agree on the principles, but principle #3 (preventing the CA for at any time holding the keypair) was considered too strong, as it prevents Also, the RPs consider the CA one of the most trusted parties, and would be happy to have CAs do the key management and repository. This surely is a different role, but RPs have to trust the CA anyway, so for them having one organisation to trust is better than two+. The discussion is not complete and will come back at future meetings. Issues to mind in particular are: - the extend of auditing ("what should we audit") - reparation of roles - agreeing the principles (and rewrite principle #3 ;-) The resulting document should be brief enough to be readable, even if that meanbs not covering all possible options. * the TNGrid CA presented their draft CP/CPS and operational status. Alexandre and Roberto are their reviewers and will guide them through the rest of the process, which can now complete over email (with a target date in March and the end-of-March distribution). * Self-audits are done regularly now, and many of the CAs in the EUGridPMA have gone through the process at least once. However, the follow-up of these self-audits (with a new CP/CPS that gets peer-reviewed by two others) is not yet up to speed. So if you are a audit peer-reviewer, please try and keep up with the process so that the pending list will shrink instead of grow over time. This meeting, IUCC, DutchGrid and CyGrid presented their self-audits, and for the DutchGrid CA a new CP/CPS version is available as well. See for details. * the meeting after Karlsruhe is tentatively in Belgrade in a date in September yet to be announced. If you know about events in September 2012 you would like us to try and avoid, mail me (but no guarantees, since September is a busy month).