Dear EUGridPMA and IGTF members, The 33rd EUGridPMA meeting is now over, and I would like to take this opportunity to again thank Reimer and Angela for hosting us and the subsequent SCI meeting at the DFN Verein offices in Berlin. This summary and the minutes kindly taken by Jules Wolfrat are on-line, with some more of my own notes to be posted later, 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. Subsequent meetings will be: - Copenhagen, May 11-13, kindly hosted by Anders Waananen and the Nils Bohr Institute of the university of Copenhagen - IGTF All Hands Hands meeting - this time co-hosted with the APGridPMA on March 16 in Taipei, TW - APGridPMA and ISCG: March 16 (and 17-19) in Taipei, TW - OGF 34: Crystal City, VA, USA on March 25-27 - TNC The Networking Conference, with lots of identity management sessions and workshops: Porto, Lisbon on June 14th (REFEDS) - 19th For the September meeting, we may co-locate with an AARC event, but otherwise the tentative dates are September 7-9. See all of you in Copenhagen, or at any of the upcoming meeting of the IGTF or elsewhere. Slides with background of the Berlin meeting are attached to the agenda pages at ! Best regards, DavidG. Subject discussed and listed below ---------------------------------- - Generalized IGTF Levels of Authentication Assurance - TCS Certificate Service G3 updates - Registration Practice Statement - Auditing, accreditation, and compliance - Communication Challenge and Risk Assessment - SHA-2 implementation status (and RAT Communications Challenge) - On-line CA Architectures Guidelines document and Robot 1SCP update - Wildcard naming - Miscellaneous topics * auto-enrollment based on a IdM for networked devices * Jens' Soapbox - integrity and robustness for CA operations * SirTFi - Security Incident Response Trust Framework for Federated Identity All presentations are available on the agenda page: http://www.eugridpma.org/agenda/33 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. I also apologize for any omissions and misrepresentations - this summary is taken mostly from memory and scribbles (and the scribbles will be posted on-line later - they WILL contain more detail). Generalized IGTF Levels of Authentication Assurance --------------------------------------------------- The LoA generalization process aims to extract those elements from the IGTF APs that are of general value to the community well beyond PKI. This has not always been clear from the AP document, since they have both LoA elements and PKI implementation requirements combined in a single document. Previously, the Classic, MICS and SLCS profiles had been analysed and the 'effective relying party (service provider)' requirements extracted. The IOTA profile has now been incorporated in the same way, and it is clear that the resulting LoA document shows significant differences between Classic (CEDAR), MICS (BIRCH) and SLCS (ASPEN) on the one hand, and the IOTA LoA, with identifier "DOGWOOD" on the other. But also commonalities between SLCS and IOTA have been found, and thus expressed in the new LoA document version 4 The latest version of the generalised IGTF LoA document is now available at http://wiki.eugridpma.org/Main/IGTFLoAGeneralisation now defining four assurance levels. Although BIRCH and CEDAR are closely related, it will need further discussion to decide if these two levels can be merged. The document itself has been assigned OID 1.2.840.113612.5.2.6.0, and the four definitions an LoA OID as listed at https://www.eugridpma.org/objectid/?oid=1.2.840.113612.5.2.5 This document now goes on for consultation with the other PMAs, for discussion at the IGTF All Hands meeting. It should be of value both for a consolidation of the authentication profiles as well as for future work in authentication and authorization for research collaborations. Elements identified for further work: - a section on incident response (like sec 5.1 in IOTA) should also be added to the Classic, MICS and SLCS profiles - for MICS and SLCS, the line from IOTA needs to be added to the profiles: "The authority must not knowingly continue to rely on data from third parties that provide inaccurate or fraudulent information. It is strongly recommended that any third party on which the issuing authority relies has an incident response capability and is willing to participate in resolving such incidents" - "well documented" really means "well documented and maintained" - a good description of the face-to-face requirements (including the models where it is supported by attestations by notary publics and video conf, for example) still needs to be written TCS Certificate Service G3 updates ---------------------------------- The 3rd generation TERENA Certificate Service, provided by the GEANT Association (formerly TERENA) via the member NRENs in Europe, has selected DigiCert (of Lehi, Utah, USA) as its CA operator for the new service TCS also presentd its self-audit, and at the same time introduced the new TCS G3 Certificate Practice Statement, which is aligned with the already accredited DigiCert CP and CPS. DigiCert is a member of TAGPMA and already has its OV roots and several issuing (Classic) CAs in the IGTF distribution. For TCS, several new subordinate CAs will be introduced. The new TCS CPS has been restructured to only specify the TERENA TCS specific elements (like the name space, identity vetting, and registration process - all of which remain the same), and rely for further details on the accredited DigiCert documents. IGTF members can review all details at https://wiki.eugridpma.org/Members/TCSG3Documents The self-audit presentation and the details about identity vetting can be found there as well, in the presentation at https://wiki.eugridpma.org/pub/Members/TCSG3Documents/TCS-update-2015-newCPCPS.pptx Additional operational details regarding the DigiCert operations were provided by Scott tho those present. Although DigiCert is already accredited, given that the TCS is a MICS service (so the back-end IdM is significant) and the CPS has been substantially changed it will be reviewed quickly by Dave Kelsey, Jules Wolfrat, Urpo Kaila, and Reimer Karlsen-Masur. The necessary subordinate trust anchors will be introduced in the end-of-February release (depending on the comments from the reviews) Registration Practice Statement ------------------------------- The RPS outlines the procedures that the community members follow to comply with the CA Profile. It allows communicaties with a defined set of registration practices to move between issuing CAs. This document, which has been worked on by both TAGPMA and EUGridPMA, was further evolved and refined, with particular attention to sections 1, 3, and 9. The latest version can be found at https://wiki.eugridpma.org/Main/RPS where also further updates can be attached and managed. The concept of the RPS very much aligns with the new TCSG3 CPS, although in that specific case the precedence is reversed (there TCS managed its onw CPS with details the same elements as the RPS would, but then incorporates the CA Operators CPS by references, whereas the RPS model would do that the other way round). SHA-2 implementation status --------------------------- The SHA-1 depreciation time line is maintained at https://www.eugridpma.org/documentation/hashrat/sha2-timeline with most of the key dates now having passed. In practice, we anticipated that not all SHA-1 based certs will have disappeared by February, especially since there are specific use cases where (hardware) limitations still require the use of SHA-1 certs. Although all CAs now MUST issue SHA-2 by default, it is permissible to issue SHA-1 still for exceptional cases. Robots on hold 32K Aladin tokens are one case in point. Some older Oracle software suffers as well. To make this clearer, we propose to add to the time line page: "If SHA-1 is broken, certificates based on SHA-1 must be revoked within the IGTF RAT determined time line, which may be within one working day. " to be discussed and agreed at the IGTF All Hands in Taipei. TAG and APGridPMA have now fully migrated to SHA-2. But there are still some SHA-1 based intermediate certs in the distribution. These should be re-issued, based off the same key pair but with a new serial number, and can then be included (via the TI/Chair of each PMA) in the Distribution. To assess if really all CAs have moved, and to find out when we will be 'sha-1-free', this will be asked alongside the next RAT Communications Challenge (RATCC). Ursula will soon run a RAT CC where - there MUST be a response within one working day - the question "do you issue SHA-2 by default" must be answered (with a yes or no ;-) a later response may be given for the question "when will your last SHA-1 cert expire?". The use of SHA-1 for CSR is not of substantial concern, since the need for integrity is shorter-lived and there are many compensatory controls (e.g. digests of the key pair during validation). On-line CA Architectures Guidelines document and Robot 1SCP update ------------------------------------------------------------------ Both documents: https://www.eugridpma.org/guidelines/1scp/1SCP-certtype-robot-0.3.pdf with OID: { igtf (1.2.840.113612.5) policies (2) one-statement-certificate-policies (3) entity-definition (3) robot (1) version-1 (1) } and https://www.eugridpma.org/guidelines/online-cas/ are now in their final format and endorsed by the PMA. Wildcard naming --------------- Although some TLS RFCs have defined the syntax for including wild cards in the subject (and subject alternative) names, only a few syntaxes actually work, and also CABforum guidance limits what clients consider acceptable. In particular a wildcard character must *only* be used in the most-left-hand subdomain name of the FQDN, and it must be the only character in that subdomain name. So *.web.example.org is technically correct, but "fts-*.example.org" is not. Nor is "fts.*.example.org". There are also conceptual issues in validation (determining 'ownership' of the names). Although the Classic Profile is not explicit about wild cards, we hereby state that and the PMA agreed: - a single "*" wildcard character is allowed, only in the left-most subdomain element of an FQDN - each node (systems) must have its own key pair, although the same (wildcard) name may be associated with multiple certs based on those distinct key pairs - it is recommended to have a specific subdomain to which a responsible person is assigned the latter means that for e.g. a set of web load balancers, a subdomain "web.example.org" is created and a responsible person assigned thereto. The wild card certificates *.web.example.org" are then controlled by said responsible. The guidance on the permissible location of the "*" character should be added to GFD.225 (in progress) Auditing, accreditation, and compliance --------------------------------------- Both Grid-PK and CERN-IT/IS presented their self-audit results at the meeting. Reviewers have been assigned to complement the self-assessments, with Temur and Nabil reviewing the Grid-PK results and new CP/CPS, and DavidG and Adeel to review the one from CERN-IT/IS. In addition Scott Rea will comment on the new auto-enrollment process once that is described in an upcoming CPS document. Also the UKeScience CA was presented - the longer term collaboration with JCS remains a topic for ongoing discussions. Following the updates to the MICS profile, and in light of the changing threat landscape (where user education with respect to phishing attacks is now a very important consideration), the additional identity question and re-entry of the password for the CERN CA has been discontinued. By asking users to provide credentials via a non-standard paths may entire them to enter such credentials in more places, harming overall account integrity. These user considerations should be taken seriously by all that provide integrated MICS services that are linked to institutional accounts. Serious concern was expressed about non-response, both after the RAT Communication Challenges and later in interactions with specific CA managers by the PMA and PMA Chair that ought to have been reachable and where there were no obvious mitigating circumstances. In order for the PMA not to have to develop specific actions on a case-by-case basis, the following guidance was defined, to be proposed IGTF-wide at the upcoming All Hands meeting: - suspend a CA for operational reasons if - after N days of commencement of a failure condition it cannot be resolved - suspend a CA also after failure to respond to a Communications Challenge for more than N days where the value of N is subject to discussion, with 30 days suggested. It is also considered to increase the frequency of the RAT Challenges to twice-yearly. Meanwhile, there is no current case where this has to be applied - all CAs where no mitigating circumstances exist are now compliant. For operational reasons, we unfortunately will have to suspend the HIAST trust anchor from the IGTF distribution for lack of CRL availablity over a longer period, as relying parties increasingly report issues and cannot correctly function without this service being available. The PMA regrets this, and wishes strength to our HIAST colleagues. When availability of the CRL is restored, the trust anchor will be reinstated. The self-audit reviews of MREN and NIIG have now completed successfully and are considered done. Kaspars Krampis has had to stand down as self-audit review coordinator. We thank Kaspars for the great job he did in making sure reviews moved forward! Cosmin has kindly agreed to guide this process from now on. Miscellaneous topics -------------------- - The CERN CA, leveraging the network device database that is linked to the identity management system, proposed and will describe in an upcoming CPS a way to auto-provision systems (VMs) that are linked to user accounts or administrative groups. This system will automate the same actions that are currently performed by the RA manually. The CPS will be distributed to the PMA mailing list and receive additional review by the designated peers (DavidG, Adeel, Scott Rea) - Jens' Soap Box is on-line as well and worth a detailed look if you value integrity and robustness! - Security Incident Response Trust Framework for Federated Identity (SirTFi) building initially on the SCI work, has made significant process and gained traction on both sides of the Atlantic. Review Dave's presentation! The focus is very much on practical work that supports incident response (which itself gets more challenging by the day).