Dear EUGridPMA and IGTF members, The 28th EUGridPMA meeting is now over, and I would like to take this opportunity to again thank Sergii Stirenko and all his team at UGrid and KPI NTUU for hosting us in Kyiv and providing truly excellent amenities for everyone. Consolidated minutes of the meeting are to be provided later on, 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. Send corrections and omissions if you spot them, since these have been taken from my own scribbles and memory, supported by the notes that Dave Kelsey took for us all during the meeting (thanks!). Please have a look at the detailed notes since they give excellent insight into the discussions during the IOTA and CredStore discussions. Subsequent meetings will be in Bucharest, RO, from 9-11 September 2013, and Abingdon, UK in January 2014. I would also like to draw your attention to TNC2013 (and any associated OGF meetings) in Maastricht, NL, in two weeks time. The next IGTF All Hands meeting is foreseen for November 2013 in La Plata, Argentina! See all of you in Bucharest (or at TNC2013)! Best regards, DavidG. Subject discussed and listed below ---------------------------------- - SHA-2 time line - The Identifier-Only Trust Assurance (IOTA) AP (formerly known as the "light-weight identity vetting environment" AP) - Guideline on the trusted operation of Credential Stores - IGTF Test Suite - OCSP status - IPv6 readiness - Updates to Self-audit and our new self-audit PMA secretary - Chair election - Risk Assessment Team - Innovation, sharing, common goals, and TechWednesday SHA-2 time line --------------- Based on the discussions at the APGridPMA, TAGPMA, and EUGridPMA, the following SHA-2 time lines has now been endorsed by the entire IGTF. Now: - 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 1st 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 1st 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 1st October 2014: - CAs may begin to publish SHA-2 (SHA-256 or SHA-512) CRLs at their official distribution points. 1st December 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. This set of mile stones will be published shortly on the EUGridPMA web site www.eugridpma.org/documentation/hashrat/sha2-timeline - to be published The Identifier-Only Trust Assurance (IOTA) AP --------------------------------------------- Using on input from TAGPMA, CI Logon Basic, and the UK SARoNGS service, and based on the RP requirements from XSEDE and inspired by PRACE, a new authentication profile specifically designed to provide only persistent unique identifiers has been drafted. This allows for an otherwise light-weight identity vetting (or authentication only). It has been presented and discussed as the "Light-weight Identity Vetting Environment" AP (LIVE AP) before. Significant progress was made during the meeting, and a complete and consistent version is now available for public comment: http://wiki.eugridpma.org/Main/IOTASecuredInfraAP Everyone is invited to comment, specifically looking at the changes made during the TAGPMA meeting (accomodating InCommon and CI Logon Basic): http://wiki.eugridpma.org/twiki/rdiff/Main/IOTASecuredInfraAP?rev1=7;rev2=5 and those made during the EUGridPMA meeting: http://wiki.eugridpma.org/twiki/rdiff/Main/IOTASecuredInfraAP?rev2=7&rev1=9 In particular - we have changed the title of the new profile to make it clearer and prevent confusion for the readers (the "live" acrynym might inadvertently suggest that the other profile had been depricated, which is obviously not the case). The "Indentifier-Only" statement in the title specifically indicated what this profile provides, and is thus considered clearer. - RPs are asked to consider if auditing of the underlying IdPs is required - RPs are asked to consider if a proper incident response procedure needs to extend down to the underlying IdPs There have been minor changes to the CSIRT requirement, the use of HSMs, and the ability to embed contact data in the certificate (sAN), as well as editorial changes to make it publishable. Shortly, the content of the Wiki will be cast in the regular Profile template and be available from the EUGridPMA main web pages. Meanwhile, comments are very welcome on the igtf-general list! Guideline on the trusted operation of Credential Stores ------------------------------------------------------- Increasingly, subscribers are using external credential management systems for generating, storing and serving their private key material, activation data and related credentials. Some of these have been known for a long time (like the MyProxy services that are used to hold long-term delegations and generate short ones), some are operated by or closely linked to portal systems, while increasingly also issuing authorities are considering to run these systems as trusted services for their customers. Also the Private Key Protection Guidelines refer to managed credential stores as 'safe' places to hold long-term credentials for users. Such credential management systems have traditionally been run without much explicit guidance beyond a generic 'they must be run securely'. With the increasing prevalence of these systems, a need for more definitive guidance has come from the RPs, and the IGTF is the most logical place to generate such guidance as is is closely related to the technical security considerations for CAs and Attribute Authority operators. Based on the AA Operations Guidelines, we have now drafted a new "Guideline on the trusted operation of Credential Stores". This tries to list the basic operational and policy security considerations that should be considered when running credential stores. For those credential stores run as part of the CA operations of PMA- accredited (or accreditable) authorities, these should likely be taken into account during the accreditation process of such authorities. For everyone else, it is of course up to the parties and communities relying on the credential repositories to define how these guidelines are applied. The text is available on the EUGridPMA Wiki, and comments from the IGTF members are warmly invited. It can be found under the "Policy Drafts" section on the wiki at: http://wiki.eugridpma.org/Main/CredStoreOperationsGuideline The security consideration are written down more explicitly, since we think the intended audience is likely not to be familiar with the 'customary' security precautions taken by CAs and like authorities... After a short period, this Guideline will be published on the EUGridPMA web site in the conventional format as well. IGTF Test Suite --------------- The IGTF distribution is sufficiently large and complex that software can break in the production environment in ways that could not be easily foreseen. This necessitates a 'test suite' that software developers could use to verify whether their software will work in the IGTF world. The test conditions and requirements are developed on the Wiki and have been clarified during the meeting: http://wiki.eugridpma.org/Main/IGTFTestSuite In addition, we really need all IGTF members to consider the actions: - 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 There is no actual effort identified yet, although with summer coming up there is a chance to get summer/Erasmus students. Anyone is obviously welcome to contribute to a test framework: interested people should contact JensJ or DavidG. OCSP status ----------- There is still limited experience within the PMA on running OCSP responsers. There are some RFC5019 light-weight ones in the IGTF, and some 'full blown' responders as well, but not many. Browsers now by default will use OCSP, and moderns (grid) software can take it into account, but it is not widely used. Also the effects on the availability need to be tested more widely. There is no experience with using OCSP in e-Infrastructure production deployments. Given the current rpessure and focus on SHA-2, it is decided not to actively push for OCSP as long as the SHA-2 campaign is running. For the software developers: - will the inclusion of the AIA extensions automatically result in the use of OCSP, or can it be disabled via configuration? IPv6 readiness -------------- The accessibility over IPv6 is most relevant for CRL downloads and OCSP, but most of the CA host sites have only a testing IPv6 capability or none at all. The /review pages have a link to the tracking status page run by particle.cz. Given that RPs moving to IPv6 exclusive nodes will likely install proxies to get to v4 space (or use the generic dist.eugridpma.info failover), and that setting dates previously did not work out, we are to try a new approach. CAs will be asked to asnwer the following questions: - is IPv6 connectivity available at your location/data centre? - does Ipv6 availability extend to the systems used for CRL distribution? - can the CA software or web servers support IPv6? - please decribe your plans on each of the above, and propose a time line on making CRLs IPv6-available. Updates to Self-audit and our new self-audit PMA secretary ---------------------------------------------------------- During the meeting Javi Masa presented the pkIRISGrid self-audit, and Kaspars the CALG (LV) self-audit. Also Jean-Francois gave an outlook on the likely new CA structures to emerge in France over the coming time. What we do notice is that -- although self-audit are done regularly -- the peer-reviews of the self-audits take an extrodinarily long time, which is is many cases due to the reviewers (and not the CA ;-) Looking tthrough the current list, only PK-Grid, BalticGrid, BG.ACAD can be ticked off as "done and successfully completed". To ensure adequate follow-up of pending peer-reviews, a designated person will track progress, acting as "self-audit secretary to the PMA". This position is to rotate every 6 months (to prevent overload of a single person), and Kaspars Krampis of CALG (IMCS UL) has volunteered to run it for the first period. Thanks! The /review/selfaudit-status pages have been updated. Chair election -------------- There were no new candidates for the EUGridPMA Chair position - and DavidG has now been re-elected for the next year. Hope you like it ;-) Risk Assessment Team -------------------- Ursula Epting will shortly running the communications challenges to the CAs based on the registered contact email addresses. The question will be simple ("please respond to this survey") and is used to measure human response time. Since the survey result is not likely to include any sensitive information, a public survey provider may be used. Please make sure the emergency contact details in the distribution are up-to-date (by contacting your PMA Chair or TI). Innovation, sharing, common goals, and TechWednesday ---------------------------------------------------- Jens' soap box on innovation lead to an interesting discussion on how to improve defining common goals and beter sharing of software that is simple, consistent, usable, correct -- and addresses the needs of the community. Currently, even if there is development aimed on common goals (assuming we have these) this information is not efficiently shared in our community. One of the possibilities is to explicitly foster exchange of technical ideas and software, maybe through the use of (open) TechWednesday sessions, or through other avenues like OGF CAOPS or specific meetings. Ideas are welcome, and we might keep this in mind for the January meeting in Abingdon, UK.