Dear all, The 18th EUGridPMA meeting, kindly hosted by David O?Callaghan and Trinity College Dublin, is now over. Minutes taken by Christos Triantafyllidis and Dusan Radovanovic will be posted shortly to the web site, but meanwhile I would like to highlight a couple of decisions and new documents that were discussed and agreed during the meeting. Accreditation and review ------------------------ - The TERENA TCS eScience Personal CA was accredited (provisional of some last minute minor textual changes that are already agreed) under the MICS Profile. This will interlink qualified institutional identity providers in the TCS Personal CA constituency to the IGTF. - The TERENA TCS eScience SSL CA (for server and network entities) will be completed soon, but the actual accreditation discussion will conclude during the 19th ?Riga? meeting. - Several CAs presented their self-audit results: pkIRISGrid, ArmeSFo, SRCE CE, and the AEGIS CA. Their presentations to the PMA have been very beneficial also for the other CAs, since ? as always ? the high-quality self-assessment will alert the others to potential improvements. Peer-reviewers have been assigned and progress can be tracked on the web page at https://www.eugridpma.org/review/selfaudit-review - The peer review of the CERN IT/IS CA self-audit is complete, making CERN the first CA to complete the entire process. - Lastly, the RDIG CA must present a self-audit in person during the Riga meeting, as well as send the written self-audit report to the chair for assigning reviewers before the end of February. Authentication Profiles ----------------------- - The Classic Authentication Profile was amended to incorporate the Guidelines on Private Key Protection. This new version (4.3) includes the following line in two places (section 3 and section 9.1): ?For certificates issued to persons, the private key must be protected in accordance with the currently approved version of the ?Guidelines on Private Key Protection?.? - Also, a document identifier was added to the Profile, like those present in the SLCS and MICS - In section 4.3 (?Certificate Profile?), the text describing what policy OIDs MUST be included in the policyIdentifiers section has been brought materially in-line with the text of the MICS profile: a policyIdentifier MUST be included, and MUST contain only OIDs. It MUST include at least the OID for the Classic profile: 1.2.840.113612.5.2.2.1. It MAY also contain an OID identifying the CP document under which the certificate was issued and other applicable OIDs?. The APGridPMA and TAGPMA are invited to endorse this new version of the profile, which will enable the Private Key Protection guidelines as agreed during the IGTF All-Hands meeting in Banff (October 2009). The Robot Profile ----------------- As agreed during the IGTF All-Hands meeting, the EUGridPMA would come up with a guideline on 'acceptable robots'. This guideline - contrary to the 1-statement certificate policies - would describe what we, as the IGTF, would accept as a valid entity for certification under the Authentication Profiles. Following our discussions, and having seen the discussion on private key protection in the presence of delegated credentials, bearing in mind the requirements for operational incident response, and considering our warm and fuzzy feeling on trust given human-readable names, a new Guideline on Acceptable Robots was agreed. Key points include: - Naming: The subject distinguished name of a robot MUST unambiguously identify the entity as a robot by including the string 'Robot', followed by a non-alphanumeric, non-whitespace separator, in a commonName component of the subject name. The separator SHOULD be a COLON (':'). The commonName subject DN component(s) of the robot MUST include a humanly-recognisable and meaningful description of the Robot as well as either: o an electronic mail address of a persistent group of people responsible for the robot operations; or o the name of a single natural person responsible for the automated client. - Key Material: The private key pertaining to a robot certificate MUST be stored either on a secure hardware token OR on a local file system on an appropriate computer system to which only those people responsible for the robots operation have access ? and to which no other people have any access, either privileged or unprivileged This computer system where the private key is stored MUST be appropriately secured, be actively monitored for security events, and MUST be located in a secured room where access is controlled and limited to only authorized personnel. - Responsibilities for the subscriber: In case a persistent group of persons is named, this persistent group of responsible people must react appropriately within the certificate revocation grace period to any request for information, and the issuing authority MUST keep the traceability to a single responsible natural person that assumes responsibility for actions undertaken by the robot and for the actions of the all persons in the group of people responsible for the robots operation. Subscribers are responsible for complying with the private key storage protection criteria and for maintaining appropriate access controls and traceability. We invite the other PMAs to read and endorse this text. Based on this Guideline, CP/CPS documents can be changed. This also means that each and every CA that wishes to implement robots MUST have their proposed procedures and safeguards reviewers by their accrediting PMA. The EUGridPMA will assess proposed changes to the CP/CPS of accredited CAs in accordance with these Guidelines on Approved Robots. OGF CAOPS --------- The next 28th OGF meeting will take place in Munich, DE, from March 15-19, 2010. There will be a CAOPS session where the planned document updated will be discussed and concluded. Also, a CRL Profile document may be considered. Authorization Working Party --------------------------- A new scoping of the work of the AuthZ Working Group, coordinated by David Kelsey, was agreed during the meeting. In particular, apart from maintaining its technical focus for the time being on VOMS, the AASP will no longer be 'accredited' by any particular body, but a guideline will be drawn up against which AASPs can assess their implementation and subsequently claim compliance. Relying parties can then either implement post-factum assessment or require pre-auditing of acceptable AASPs by them or a third party. How this interacts with the issuance of 'AA issuing certificates' by the IGTF CAs remains to be thought through. Further discussions will involve also wider consultation with (technical) people and VO representatives. The main focus will be on those AA assertions and infrastructures where the actual signature on the assertion is used in the validation (i.e. the ?EGEE? model, not the OSG model where the actual signature is not used). Distribution format changes in the wake of OpenSSL1 --------------------------------------------------- The rough outline of the new distribution format was agreed as presented, with the following decisions: - For the upcoming (1.33) distribution, the OLD format will be publicly advertised, but the new format will be available - The relying parties (EGEE, LCG and others) will be asked to evaluate the format ans look for any operational issues - The impact of re-loading the same certificates twice needs to be evaluated - it may trigger issues similar to those encountered when the 64-CAs and 85-CA thresholds were reached - Although the probability of getting OpenSSL to revert the change is small, it ought to be attempted. Roger Impey and Jens Jensen will help draft the letter to OpenSSL. If possible, help from the relying parties, OS distributors like Debian, and TERENA should be sought, since this change will impact anyone using trust anchor distributions (also for the TCS TERENA SSL CA etc) It should be investigated if adding a disclaimer to the IGTF distribution would help us in case a relying party tries to 'blame' the IGTF for getting the RP in trouble. Of course our position is that we each RP is fully responsible for its own actions, and that the IGTF ONLY asserts that the CAs in the distribution meet or exceed the guidelines against they were accredited, within the reasonable scope and means of the accrediting PMA. But this normal disclaimer, unless more prominently put, may not have reached the relying parties. The downside it that, once you add a disclaimer, it implies that you do take responsibility for some other things. Advise should be sought (e.g. from some EGI lawyers?) before adding any text to the distribution. The license of TrueCrypt, the Debian README file for their CA bundle, and the apache license, and the TACAR home page all contain reasonable text; a severability clause ought to be added for any disclaimer to be valid in the UK. A disclaimer will not yet appear in 1.33 End-user certificate management tools ------------------------------------- A technical forum (mailing list) will be established for those interested to exchange code, ideas and libraries to facility the creation of end-user certificate management tools The processes and protocols used by the CAs will vary too much to be able to get a single tool to implement everyones work flow OSG is looking for such a tool, and having the code and maybe a common library (Java?) available will help. Peter Gutmanns library in C contains useful primitives but may not be suitable for a platform-independent end-user management tool, which is usually in Java (Web Start). Next meetings ------------ The next meeting will be in Riga, LT, on April 19-21st, 2010, kindly hosted by SigmaNet and the CALG CA. You?re warmly invited to attend in the unique Hanseatic city of Riga! It is highly likely but not yet completely certain that the meeting thereafter will be held on September 20-22nd, 2010. In any case, the location will be Zagreb, HR, hosted by SRCE. Confirmation of the dates will be given this January. Again, I want to thank David OCallaghan, Brian Coghlan and the TCD team for organising a great meeting and I hope to see many of you in Riga! Best Regards, David Groep.