The 26th EUGridPMA meeting is now over, and I would like to take this opportunity to again thank both Jean-Francois of RENATER as well as Helene Cordier of CC-IN2P3 for hosting the meeting and providing excellent amenities for all participants. The minutes of the meeting will be provided later on (although there are already notes available from Alessandro Usai on the SHA-2 discussion - thanks!), 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. Based on the expected attendance for the next meeting, we have unfortunately had to relocate the January meeting to be in Florence, Italy (14-16 January 2013) instead of Abu Dhabi. While I very much appreciate the offer from Ankabut and Ahmed Dabbagh, at this point in time we could not ensure enough attendance at the meeting if it were held in the UAE. I hope we can get there for a later meeting. Meanwhile, I would like to thank Roberto Cecchini for offering Florence, IT, as the new location. Subsequent meetings will be in Kyiv, UA, from 13-15 May, and Bucharest, RO, from 9-11 September 2013. But now, the summary! I apologize for typos and omissions since this is rather quick ... SHA-2 migration --------------- The introduction of SHA-2 as a digest algorithm for certificates and CRLs still facing significant difficulties as software is not ready to deal with this. Although developers are working frantically to resolve any issues, it is unrealistic to assume the new software will in a production-ready state in January 2013. Therefore, the introduction of SHA-2 in certificates and CRLs is itself a kind of "risk to the infrastructure". This must be appropriately taken into account. Based on the feed-back from developers and operations/deployment experts, we decided on a revised time line for the introduction of SHA-2. * CAs will not issue general availability SHA-2 certs before 1 August 2013 THIS IS THE MOST RELEVANT DATUM POINT FOR RELYING PARTIES! * If SHA-1 is broken, revocation and transition will be immediate as inspired by the categorization in the HASHRAT document (this may be within a few hours if it's trivial, or a few months if it takes lots of time to brute-force a message) * The scheduled end of life for SHA-1 EECs is 1 September 2014, meaning that SHA-1 EECs SHOULD have a validUntil date no later than that date. If there are CAs with EECs having a later date, the primary mitigation of the risk in case SHA-1 is broken will be removal of said CA from the IGTF distribution. * CAs SHOULD have SHA-2 issuing capability by October 1st 2012 THIS IS THE RELEVANT DATUM POINT FOR CAs! * No need to move any existing CA self-signed root certs to SHA-2 since we rely only on the distributed metadata. * Since *intermediate* CAs are distributed *but* the distribution may be superseded by the client at-will by dynamic CA chains (subject to the namespace constraints) ... these intermediate CAs SHOULD be SHA-2 after 31 March 2014. However, if these are still SHA-1 based, they MUST be revoked and re-issued immediately if and when SHA-1 is broken (akin to the process for SHA-1 based EECs once SHA-1 is broken). * Once SHA-1 is broken, only SHA-2 intermediates will be distributed or both the SHA-1 intermediates as well as the corresponding root involved will be removed from the IGTF distribution. * New CA certificates generated after April 2014 SHOULD be SHA-512 from, noting that existing (self-signed) CA certs MAY still be SHA-1 based * Only SHA-256 and SHA-512 variants may be used, and NOT 224 NOR 384 nor any other length. Of SHA-256 and SHA-512, each CA MAY pick its own variant * CRLs on the default CDP SHOULD be SHA-1 until at least 1 September 2014. CAs MAY start distributing SHA-2 based CRLs after that date, and MAY have SHA-2 based CRLs available on alternate CDPs after 1 October 2012 * If same entity with the same subject CN obtains two different certificates (i.e. the request is 'signed twice', once with SHA-1 and once SHA-2), the certificates issued must use different cert serial numbers. The same is true of CRLs with same data. Must be different sequence number. * Breakage of the SHA-1 algorithm in a way that allows trivial generation of plaintexts with a specific hash necessitates removal of SHA-1 algo support. This is a software vulnerability issue outside of our scope and SHOULD be dealt with using regular vulnerability mechanisms of the RPs. It then WILL necessitate SHA-2 based root certs as well. * The 'end-of-life' SHA-2 migration recommendation does not apply to certificates with a short life time (for SLCS CAs), until at least 1 September 2014 (or until SHA-1 is broken). * OCSP responders will continue to use SHA-1 as specified in the RFC * The recommendation does not extend to attribute authorities, since these are currently out of scope for the IGTF. These revised recommendations should still be endorsed by the other PMAs, but it is expected that this endorsement will be forthcoming. We note that the new cut-off dates are slightly later than the TAGPMA recommendation, though. The new dates also align with the expected availability of software capable of dealing with SHA-2 in some large infrastructures (in particular wLCG and EGI), although *all* infrastructures and RPs are strongly encouraged to test all scenarios: only then you learn that software may not work as advertised! Currently there are enough accredited CAs capable of issuing SHA2 to allow developers to realistically test their software. By October 1st, one can try for example BalticGrid, ROSA, DutchGrid, and CESNET, likely also DigiCert, GridCanada, and INFN. Not-yet-accredited CAs that have SHA-2 available are for example the alternate instance of the CERN TCA, and CILogon (OpenID). CERN is setting up a parallel infrastructure for a SHA-2 CA, so as to make it easy for end-users to pick the proper one (and use SHA-1 as a default for now). Key length ---------- We remind all CAs that the minimum key length for end-entity certificates should be 2048 bits by the middle of 2013! The IGTF will not consider the introduction of EC crypto until 2018. OCSP support by CAs ------------------- The discussion on the deployment of OCSP at a large scale is still on-going: even the deployment of light-weight OCSP (RFC5019) in production should still be properly tested and surrounded with advise for RP deployment (including caches) before we really force everyone this way. Also features like OCSP stapling should be better developed before we can realistically move this way - but stapling for client-auth (so for user certs sent to a service) is somewhat hairy. The timeline in Karlsruhe was somewhat too optimistic in this case. This was also identified in the TAGPMA Panama meeting. The new recommendations are * for now, there is no need for SLCS CAs to run an OCSP service * only CAs that have a production level (preferably cachable or even anycast- enabled) OCSP service should include the AIA extension There are nice new script available (by the end of September) made by Milan to precompute OCSP responses for OpenSSL-based CAs, which require only apache and php. Milan will send details to the list later. Reviews and accreditation ------------------------- The new EG-GRID CA is accredited, and will be distributed in the 1.50 release on September 24. The CP/CPS is extensively reviewed by Feyza and Usman, and the responses by Dina and the rest of the crew very timely. Accredited by acclamation! - Armenuhi from the ArmeSFo presented an update of the Armenian CA, which resets the clock on the self-audit. The assigned reviewers for the previous self-audit should actually look at the revised CP/CPS which has been available for some time now (Jens?!) - Adeel presented the PK-GRID self-audit, which will be reviewed by Milan and DavidG. - Hardi presented the BalticGrid CA self-audit, to be reviewed by DaveK and Oleksandr. There are other CAs that are due for a self-audit, but have not done so for a very long time, or have consistently failed to meet the in-person attendance requirements from the accreditation guidelines. While we will refrain (for now!) from public shaming, they can have a look at < https://www.eugridpma.org/members/internal/display> for a view of their status. Other CAs not only are overdue for a self-audit, but ALSO failed to show up for a long time. There are 5 of those who will get a warning letter: either show up in-person in Florence (January 2013), or face consideration of removal from the PMA (and thus also from the IGTF distribution). Please: SHOW UP. The table above indicated if you are targeted for this measure ... Other CAs have gone too long without a self-audit (max. 3 years). There are 5 of these as well, who will be firmly asked to do the self-audit and present it. Video-conference attendance --------------------------- To some extent, consistent, repeated and full presence of a CA via video-link can to some extent off-set the lack of in-person attendance. Some of you have been very good at this, sitting remotely through an entire meeting (congrats!). We therefore decided that consistent and frequent attendance of a meeting via video-conf, and where you attent a significant part of that meeting, will count towards personal attendance: if you make it 2 out of 3 meetings each year, the in-person requirement can be deferred by one year (so a true in-person every 2 years, and attend 4 meeting by videoconf). FIM4R ----- The document is at < https://cdsweb.cern.ch/record/1442597> and records the use cases and requirements by research on federated identity/attributes/&c. It highlights the need for differentiated levels of assurance in the IGTF as well, as well as the usefulness of having a data-oriented relying party members of the PMA (in particular EUDAT). LoA-2 and Kantara ----------------- Especially the relying parties are requested to read the Kantara LoA-2 document (linked to the agenda pages). Although it should be already clear that Kantara LoA-2 should be sufficient for the TCS in particular, we could make more general statements and aid other parties doing LoA evaluation. The discussion will be continued in Florence. STS --- The STS presentation (first given by Christoph Witzig in the 22nd Prague meeting) is still relevant, but there is a lack of current and urgent use cases that are sufficiently spelled out for discussion. Although it may look otherwise, the STS is not the universal solution to all the world problems: it does one specific thing (convert token into token) and not more. There is a STS demontation given to the EGI Technical Forum in September 2012, and once ther are good use cases to discuss we can try to use them as a basis for generalizing the SLCS profile. The work is therefore deferred until these use cases are available (in January or May 2013, hopefully). Robot naming ------------ Although interesting solutions exist to accommodate the use of a colon (":") character in Apache's mod_ssl, it is not easy or scalable: it cannot be used in htpasswd files, but only using SSLRequire directives in htaccess stanzas. We already have a variety of naming conventions for robots ("OU=Robots", "CN=Robot/", "CN=Robot:", and "CN=Robot - blah", &c), but new CAs should probably take the latest guidance: ".../CN=Robot - function - contact". The 1SCP on Robot certs as well as the Approved Robot guidelines have been updated and are linked to: where the 1SCP will be agreed at OGF, and the Robot Guidelines gets circulated to the other PMAs and then posted on the EUGridPMA web site (to be done). Roll-over --------- Rollong over the CA at the very last moment (so the CA expired at the same moment that the last EEC expires) makes it difficult to distribute only valid trust anchors in the IGTF distribution. And having expired CA certs (or CRLs) distributed upsets the relying parties and monitoring infrastructure. Therefore, the IGTY ONLY distributed valid trust anchors, and trust anchors MUST be valid until at least the expected scheduled release date of the next distribution. Releases are monthly, on the last Monday of the month (as agreed a year ago in Ljubljana). "the CA certificate must be valid for the entire period during which the distribution is expected to be installed, and at least until the scheduled release of the next distribution by the last Monday of the month" We will write a short "release guideline" document that defines the IGTF release process, time lines, and requirements on validity of the distribution trust anchors. PLEASE roll over at least 16 months in advance of the end date. This IN PARTICULAR applies to CY-Grid, which expires already on Feb 3, 2013! The PMA will try to send warnings well in advance - but the CAs are ultimately responsible for their own processes - just like for CRL updating. Closing ------- I would like to thank all who participated in-person and over the videolinks, and see you all at OGF36 in Chacago next month, or in Florence! Best regards, David Groep.