15th EUGridPMA Meeting Nicosia, Cyprus. Remote participants (not necessarily the whole day): Jules Wolfrat, Roberto Cecchini, Miro, Javi, Daniel Garcia, DFN-CERT, QuoVadis. Day 1 - Monday 26 Jan 2009 1. Introductions and Welcome Includes a roundtable introduction of all participants. Jens - UK stats - 1759 va 2837 host 155 RA staff over 75 RA. Quite a few staff changes. Moving CA to new building. Matt Viljoen moving to being the new CASTOR manager. New staff. Changes happening to UK CA hierarchy. Reimer - German CA - 84 RA - ~600 valid user certs. ~400 server certs. 252 hosted CA with 40K valid certs. Latvia - 700 valid certs 2. Yoshio - APGridPMA Update See slides. IGCA (India) approved on 5 Nov 2008. NGO/Netrust CA temporarily dropped as CRL lifetime is too short. Hong Kong review started in Jan 2009. Video Conf held on 17 Jan. Discussed how to implement sustainable review and external audits. ASGC issued new root cert (now SHA1). 13 accredited CA. 1 under review. Next f2f meeting will be in Taipei in conjuction with ISGC. 3. TAGPMA update - Vinod See slides. F2F in Argentina - Nov 08. Jointly with UNLP Grid Open Day. 2 new members - Brazil (San Paolo state) and Peru. 22 members - 9 IGTF accredited, 3 pending, 3 on the way. Colombia expected to join. Officer elections July 2008. Admin changes to web site and email list. Plan to mirror Nagios CA monitor. Updated SLCS profile V2.1.1 - 15 Jan 09. Includes comments from SWITCH. Looking for EUGridPMA approval this week. Classic profile V4.2 approved in Nov 08. But ongoing discussion: Where is "safe", how separate is "separate"? Updating evaluation spreadsheet. Update to MICS needed to bring language up to date. For next TAGPMA F2F. Several guides being worked on: how to setup CA, CP/CPS template In Portuguese - being used by all Brazilian Univs joining the PKI. Ready to work with Jens on this. Canadian CA will be handed from CANARIE to NRC. Seems good point to move to TAGPMA. Next F2F planned for week of 27 April - joint with Identity Federations workshop. Vinod has a new IGTF interactive map. 4. IGTF Risk Assessment Team - Jim Basney. Shows IGTF RAT wiki page. http://tagpma.es.net/wiki/bin/view/IGTF-RAT/WebHome Reported on recent RAT activities. Dec 2008 issue - Mediterranean basin cable cut - affected CRLs. MD5 hash collision - new attack demonstrated at end of December. RAT conclusions distributed. Still some concerns that CA might still be issuing MD5 end entity certs. Jens reports that UK sysadmin has installed plug-in to warn about MD5 subordinate CAs - This throws up some IGTF intermediate CA. CNRS will change to a complete new hierarchy in a few days. Question of proxy cert and MD5 - Jens reports that Globus concluded that there is minimal risk. David Groep disagrees, but the risk is small. Globus is planning to migrate to SHA1 soon. MD5 is weak and shouldn't be used anywhere. Some IGTF CA certs still use MD5. OpenSSL client vulnerability - (EC)DSA EE keys. RAT thinks unlikely that IGTF CAs certify these certs - but no audit yet. Experience is that risk assessment is technically challenging. Communication between RAT and CAs. email of course. But the online repository of issued certs is very useful. Can this become a requirement? Milan points out privacy issues. Willy: Do public keys and certificates incur privacy issues. Yes... same as phone books. Willy: RPs need risk statement based on *all* IGTF CAs. Agrees that all CAs should publish all certs - but could be restricted to the RAT. Milan: once check has been done, the CA could issue bad cert later. CAs must modify their practice in the future based on the threat. The PMA agrees that the RAT will stick with e-mail for communication and not force publishing. BUT CAs must respond quickly. DavidG notes a correlation - CAs who are slow to respond tend to have a public repository. CAs need to check: small RSA exponents, known weak keys (Debian SSL problem), MD5, (EC)DSA. DavidG notes that some hardware tokens (with PKCS11-tool) use exponent 3 and 5. Some (~30%) CAs report they are checking. The RAT needs to collect a repoitory of such issues and instructions. CA should implement within at most 6 months. Milan would have to check after cert has been signed as process is closed and then revoke. Jim points out that rogue MD5 certs cannot be revoked as serial number can be changed. CA has to stop signing with MD5. CA cannot deal with all middleware variants. IGTF statement should be that we do not issue DSA certs. RP should be responsible for checking their own implementations. Jim stresses that Risk assessment is difficult. He encourages additional members to join - email to Jim. 5. Migration of Root certs and CRLs to SHA-1, and the implementation of SHA-256+ in M/W. (David Groep). No slides. CA should move CA cert and CRL signing to SHA-1. Some specific examples are considered. When will SHA-256 be supported in middleware? Marg (TAGPMA) had done some tests and concluded there are still problems. OpenSSL above version 0.9.7 (f or g) supports SHA-256. IGTF should warn RP and software suppliers. DPK asks why SHA-1 is bad. NIST recommendation - SHA-1 expected to be problematic within next year or so, people should plan to move during 2010. There are research papers on this. PMA wants all RP to support SHA-256 by Jan 2010 and there will be a test CA available to do compliance testing during 2009. There is a new OGF group PGI-WG - they should also be involved. 6. CRL web caching issues - David Groep See slides. Shows timing of CRL downloads - hour of day, seconds from minute start. Sometimes sites are misconfigured - generate much more traffic. Shows the web responses required to allow caching. Must include Last-Modified and Expires dates/times. If leave out "expire" time it depends on the integillence of the web cache If CRL has moved, use 301 Moved Permanently, not 302 response. Best to update URL in distribution. If no last-modified nor expired, then the CRL is not cacheable. DavidG shows the Apache 2.x configuration details. New fetch-crl (v2.7) is better at handling this - stores last modified. Reimer: would be good to randomise the time of request. David G will do this in the script which calls the fetch. Would be good for a small group of CAs to offer backup CRLs for each other. Also script will not complain if the CRL has been successfully download within last 24 hours. Wish list for a successor tool. ------ coffee ------------------- 7. Reimer. New DFN SLCS CA. See slides. Shibboleth-based DFN-AAI. Mike Helm and Kaspar Brand have done CP/CPS review. DFN-AAI started in 2007. 30+ participating IDPs. Additional SLCS-participant agreement between Org and DFN is org wants to provide SLCS. They need to understand issues: persistent attributes, account data update policy etc. Kaspar: what about path length constraint? Don't want to restrict this. Namespace: OU=SLCS is excluded from the Classic CA namespace. CN is eduPersonPrincipalName attribute from IDP (unique persistent). Jens: how is OU=SLCS excluded from Classic CA? DavidG: CA policy prevents this. Jens would like to see this in signing policy file. Milan would like to use the same namespace for all CAs as long as he guarantees that the same person always gets the same name. Jim notes that TAGPMA forced NSCA to use different namespaces. DavidG explains that there is a single root of trust above the individual CA instantiations and therefore using the same namespace is OK - we will come back to this issue. Milan: does the SLCS profile require an e-mail address and if so why? Come back to this too! Yoshio: is the Java code signed? Yes, by one of our code signing certs. Jules: did the GridShib-CA work out of the box? Not exactly. Had to modify software to integrate with existing software but this is not documented. Milan: why is there a separate box for the Pub-SOAP-frontend? Juergen: Doesn't really need to be but this is the same setup we have for other CAs Ursula: do you help the user convert to correct format? The CredentialRetriever uses the Globus libraries to do the necessary magic. DavidG: users may need to register with portals so other formats (pkcs12) would be useful. CP/CPS review - all identified issues have been fixed. Kaspar confirms that all is OK. DavidG: Is the CommonName an appropriate representation of the actual name? It is built like an e-mail address - last name is there but first name not necessarily there. Juergen: DFN will ask whether there is a problem releasing the first name and last name. Or could be Lastname and EPPN. DaveK: We should consult the Sites and VOs - can we accept unique and persistent handles and not actual name. WLCG is not the only RP but Jim notes that WLCG was the community where the requirement for actual names came. Back to discussion on use of same or different namespaces. DavidG: top-level IGTF federation document says that namespaces are managed by a single "authority". This authority can run multiple CAs. Jim points out that the DFN SLCS is a different authority. Authority is the entity we accredit and the new SLCS CA is seeking accreditation. PMA agrees that the current proposal is OK. Back to Milan's desire to share a namespace between different CAs. Proposal: if single name space is managed by one authority by policy and there is a guarantee of persistence and uniqueness. Jim points out that one compromised certificate will now require revocation of all certs with the same subject name (not issuer or serial number). Willy brings up technical issue of Alternative Issuer Name. Reimer will look into this and fix if necessary. Vinod notes that the e-mail address in the EE cert is not needed. --- lunch ---- 8. NetherNordic SLCS/MICS CA - Jan Meijer See slides. Denmark, Finland, Netherlands, Norway, Sweden, includes NDGF. Work originally started in 2007. Aim to give user a cert within 5 minutes and allow scaling up of number of users. Share operational costs - continued skills only needed at one place. Doing combined SLCS & MICS - use specific federation attribute to decide on SLCS or MICS - did user turn up with a passport? Banks and mobile phone operators also do AuthN - maybe we can use? Technical details - Henrik Austad See slides. Confusa: Map federated identities to Grid compatible certs. Fast & secure. Using ePPN, Full Name and e-mail. Jens points out that CERN has two CNs. Could use one with ePPN and one fullname. ARC middleware works with CERN CA. Discussion about location of key-pair generation. Jim: what exactly do you do to distinguish between SLCS and MICS? Photo-ID is required for both. No... face to face is only required in MICS. Jan says they might use one-time SMS for the second factor for MICS. But noted that the phone number needs to be authenticated in IDMS and therefore difficult if user can manage this. SLCS has a reasonable chance to get back to the actual person even if not f2f vetting because of short lifetime. Gives live demo. Consider some questions/issues: Identity vetting within the federation? Either single process for all or define set of criteria that organisations need to follow. They will come up with such a document. Agreed - until we see the document! Designated CRL signer - does it work? Not needed - CA is online anyway. CA chain? Good idea to have offline root to revoke CAs. One combined CA or two. Need two separate CAs to allow RP to install one or other - identity vetting is different. What about another country joining after we are in production? Just start with the IDP requirements. ---- coffee -------- Quovadis - SWITCH PKI - presentation - Stephen Davidson Problems connecting, so start with Alessandro's talk. See slides. Update since Lisbon. QuoVadis - commercial company based in Bermuda. Shows CA Hierarchy. Reimer and Jens have reviewed. Feedback resulted in some changes. Goes through the major points. Jens points out he has not yet completed the review. Swiss community is not that interested in hardware tokens. They will present details to reviewers but will not publish. CP/CPS contains an appendix for Grid specific part. OID for Grid will only change if policy changes affect Grid CA. PMA would like the Grid OID to change when the main document changes. This seems OK. Discussion about the need or not for a contract between QuoVadis and IGTF. DavidG: or relying parties? Now QuoVadis connects by phone. Talks to slides. Wide distribution of roots in browsers. Moves on to Summary of audits and accreditations. Secure Data Centre meets a number of international standards. Moves on to CP/CPS - they are happy they have done the required updates. They plan to attend the next meeting in person. Reimer: are all CAs audited at the same time? Would the Grid CA be covered by the audit? Some audits are specific to some CAs, but aspects of the audit cover the whole infrastructure. WebTrust audit is universal. This is the only audit which would specifically cover the Grid CA, but the general infrastucture benefits from all the other external audits and their own internal audits. Then describes the roots. There are 3 Root CA; RCA2 is SSL and RCA1/3 are more for EE certs. GridCA will sit under RCA1, because of key size. Reimer asks about machine setup (one machine or several)? It is closer to our model A. Do they need to document the environment? Or are the external audits sufficient? PMA would like reviewers to have some more detailed discussions with QuoVadis. PMA is happy if the reviewers are happy. Thanks to QuoVadis for their participation. Alessandro shows timelines. Meeting closes for day at 18:10 15th EUGridPMA Meeting Nicosia, Cyprus. Remote participants (not necessarily the whole day): Miro, Javi Masa, Jules Wolfrat. Day 2 - Tuesday 27 Jan 2009 1. Self-audit report - PK-grid CA Sajjad See slides. Started in Oct 2003. Old root key expired 9 Dec 08. New cert valid until 2017. 4096 bits. New CP-CPS (RFC3647). Approved PMA in Jan 2008. See slides for details of self assessments. They note several B scores. Host certificates MUST contain dnsName in the SubjectAlternativeName (requirement from RFC). Renew/Rekey for more than 5 years: B not D. No need to publish self-audit on web site - but available to PMA. Shows future plans. Jens: has anyone reviewed the audit? No, not yet. Ursula and DavidG volunteer. Vinod points out that WebTrust audit rules are different for government funded bodies. 2. Self-audit report - GridKA - Ursula See slides. Was accredited in 2002. FZK being merged with Univ to KIT. Jens and Milan are reviewers. Range of marks - 37 A's to 6 D's. Shows C and D. Is change to RFC3647 recommended? Jens: this is not required and not a C. Only new CAs should prepare in new format. PMA agrees that reviewers are needed to check move to RFC3647 to confirm that the policies are equivalent (not a full re-accreditation). Does CRL .pem vs .der matter? If mime type (pkcs7) is correct, doesn't matter. DavidG confirms this needs to change. Milan recommends moving to CRL V2 - no known problems now. JimB: required by RFC - important to change. Can I include object signing for everyone? Not recommended. Just for those who request it. Sajjad asks what the PMA recommends for disaster recovery. No current recommendations - depends on risk assessment of likely disasters 3. Self-review Grid-FR - Alice See slides. Classic CA. Acts as catch-all for EGEE (non-HEP) - 10 countries. Self audit not as detailed as previous 2 talks. CNRS and CNRS-Projets uses MD5, but we only accredit Grid-FR. Some CAs expire soon. New PKI: GRID2-FR. DN and EE issuing remain the same. New CP/CPS in RFC3647 being reviewed internally. Will need a PMA review. Want to use robot certs. Need to configure the CRL cache. CA machines will move to Lyon. Will now have an online CA with HSM. 4. CALG Updates - Dana Latvia. Updates to CP/CPS since last review. See slides. Discussions started in Aug 2006. Last presentation in May 2008 - there have been several rounds of comments and changes. Dana reviews last updates. Discussion as to who can request what service names. One way is to require the sys admin who asks for host cert to ask for all service certs. Proof of possession of private key - compare printed public key. DavidG points out that comparing exponent and modulo is enough. Could also use a private PIN. PMA says the current text is OK. CA cert should not be used for any other signing purposes than certs and CRLs. For digital signing should issue an EE certificate. If using a government CA to prove identity - in place of photo ID - then do we need to review their CP/CPS? For Latvia, Post Office Cert is OK. For longer term PMA should consider general use of these external CAs. Domain components encoded as IA5STRING are ok. A few minor changes are still required to the CP/CPS. Should start preparing the distribution information - CA ACCREDITED. --- coffee ---- 5. Federation document DavidG presents the current IGTF Federation Document. Section 3.1 on the assignment of namespaces. Need to better define "authority" DavidG interprets "authority" as the body which runs one or more CAs. TAGPMA interprets authority as the CA. DaveK points out that the AuthZ WG proposes to accredit Attribute Authority Service Providers not the individual AA. JimB suggests the term is "PMA Member". If same DN is issued by more than one CA (belonging to one member) then incident response is more difficult - all the CAs of the member are then suspect. If user credential is compromised, would have to revoke all certificates issued to that person. Jim: the positive sides are - subscribers find it very confusing to have different DNs from different CAs. Willy is concerned that there are persistent (e.g. storage) ramifications of short-lived certificates. DavidG sees advantages for user who starts with SLCS and then at later stage wants to access other service and gets MICS cert - DavidG wants this person to keep same name. DavidG: sharing namespace between CAs should require a top-level policy document on the management of the namespace by the PMA member. Jim: I don't want to give VOMS admin rights to a person authenticated by a SLCS CA. Can configure VOMS to use both user DN and issuing CA. We agree proposed wording changes to Section 3 and 3.1. This should also be discussed at the next TAGPMA and APGridsPMA meetings. Reimer: Do we need to require the existence of the top-level namespace management document? Only for new CAs wishing to use this. Could also be common text in the two CP/CPS documents. 6. SLCS V2.1.1 DavidG shows the changes since V2.1.1 - or tries to but change-tracking is on from V2.0. Vinod says that there really are very few changes, just cleaner language. PMA approves V2.1.1. Jim announces that OSG will drop CA's that don't issue CRLs in Feb 2009. PMA requests OSG to reconsider - stick to 6 months beyond approval date, i.e. 6 March 2009. 7. AuthZ WG update - DaveK See slides. No notes taken by this note taker. Some issues that came up: 1. Should we only address signed attributes or also include database downloads? 2. Lots of discussion on Revocation. What happens when a user has two certs with same DN, one of which is revoked? We should insist that the connection to the AA is properly authenticated, both for end user and database download. 3. Lots of confusion (particularly by the speaker!) on the naming of the AASP. Is this globally unique? If so, how? ------ lunch ------------------ 8. Hungary NIIF CA - self audit - Tamas See slides. No very serious problems were found. Tamas goes through some of the less serious issues. Impossible to test simultaneous revocations. (Q32) Q43- FQDN in SubjectAlternativeName - its a must. RFC requires it. They do plan to reorganise CP/CPS in the RFC3647 format. Emir and Christos have been volunteered to review the audit. 8a. Non-agenda item. DavidG informs that it has come to light that an individual is trying (so far unsuccessfully) to get a certificate. This has been sent to the RAT. DavidG asks how to distribute such information. IGTF-general is too public. Agree to distribute via the registered contact addresses. 9. Jens "Soapbox" talk Reviews - reviewing self-audit report doesn't quite work. Process needs improvement. The reviewer needs to do their own operational review. Should consider automation. Housekeeping - can we standardise more locations (e.g. location of CPS). Suggests better maintenance of review outputs - e.g. who were the reviewers? Or need to keep track of the minor issues. Could use the Template Policy framework to store all comments. Reuse of DNs. What are all those DNs in the logs? e.g. many repeated production jobs submitted by one individual. Some of this would be better with robot certs. But consider reuse of credentials. Could be lots of different types of use. Some Grid users share credentials because of perceived difficulty in getting a cert. To solve this UK will issue lower assurance certs (SLCS) which can be shared. Strengthen security by weakening it! Simpler security is more useable. Using robots would help. But then the need for a hardware token make things difficult. Jim: suggests that relaxing the need for the hardware token would help. DavidG: could use a store like Virtual Smart Card to handle robot cert. Separation of roles important. CAs do not want to see Resource provider logs. Back to pushing for project names in Robots. Milan: how does a CA know that a project exists and who can ask for a robot cert. Jens: we can always ask the funding body. This was discussed at length in latest TAGPMA f2f meeting. Jim reminds that he likes to see a name of a legal entity: person, organisation or dns-name. This remains an open issue. Securitification(!) Can we improve security by sharing more information - log files etc? Following an IGTF update, all sites deploy the new release. But they don't. CRL download requests continue to appear for CA which has long-since expired. Jens has the IP address, but log files are not public so he can't tell them. Or better still contact the higher level Grid organisation. DavidG: can contact via network whois entry - can share with owner of IP address. Request for revocation comes in. The approval process takes time. Eventually the cert is revoked. Time stamp in the CRL is of the actual revocation. Milan: another field in CRL can store time of request (suspected time of compromise). Jens suggests working closer with RPs to improve operational security? Under what circumstances would the CA release information to the OSCT? UK CA cannot release such information - because of policy. Authentication profiles. Do they converge or diverge? Can a classic CA use an automatic database (non-human RA) which meets the needs of the MICS profile. ------- coffee -------------------------------- Back to Jens' soapbox... Beyond AuthN - to encrypt or not? Encryption bad idea: Certs expire, maintain CRL forever. Milan disagrees: once encrypted neither of these matter. But still results in support problems. Therefore not recommended. Jens says OK for encryption of traffic over the wire if immediately decrypted. He forbids long-term encryption, by policy. Beyond AuthN - signing long-lived objects - so cert is important, not just DN. Could set purpose of VOMS certificate in extension to be just signing. This may need to be added to the CP/CPS as an allowed type of certificate. What about object signing? Maybe CP has to say something clearer about object signing. Right now the UK CP just says its optional. Should the CP say that the CA is not making any assertions about quality of the code which is signed (and no liability). Willy points out that this is dangerous as it could suggest that other purposes are supported - CP should just say that all the certificate does is authenticate the person signing the object. Service certs - do we still need them? We should do better tying these down to a list of known and described services if still needed. Issues for next OGF: Template CP/CPS Beating the computer? Documenting deviatons from PKIX And other aspects of RFC3647 Pinning down the practices (re-keying etc) Wildcard DNS Document Grid extensions/mods to OpenCA Willy asks if there is any known deficiency of BouncyCastle key generation. Answer: no. Dinner discussion topics - not minuted! 10. CAOPS-WG Yoshio takes over chair. Auditing Guidelines Document (Yoshio) Went to final call last October, but Christos K initially wanted to make some revisions, but now decided against this. Yoshio will send document to public comment soon. Grid Certificate Profile GFD-C.125 (DavidG) This was released some time ago. David O'C is implementing a compliance-testing suite. Grid Steering Group has suggested the following; test compliance of a number of our CAs make some needed changes and re-submit as a technical recommendation. All agree. Relying Party Defined Namespace Constraints Policy document. (DavidG) Been around since 2005. Defines why we need a signing policy file and a list of requirements for such a policy language. DavidG goes through list of requirements. Reimer asks about negative conditions on branches of the namespace tree (like the need we discussed yesterday to exclude "ou=SLCS". They seem to be missing right now. Add these exclusions. Jens points out he was going to write some examples. He still plans to do this. The date of the requirements poll should also be dropped. Aim for public comment before OGF25. 3 sessions have been requested for CAOPS and IGTF in OGF25. 11. Announcement of next meeting Next EUGridPMA meeting - Zurich - Switch building. Monday - Wednesday 11-13 May 2009 Meeting closed at 17:50 15th EUGridPMA Meeting Nicosia, Cyprus. Remote participants (not necessarily the whole day): Miro, Javi. Day 3 - Wednesday 28 Jan 2009 1. Sharing Common Software DavidG introduces the topic. Collectively there is a lot of knowledge and experience on tools but so far not much sharing. Would be good to collect pointers to useful stuff on the wiki. Contributors raised hands - about 7 people. Do people want to share with IGTF or the world? Some of the tools need to have controlled access. EUGridPMA wiki is chosen. DavidG will distribute a template page and ask people to contribute. 2. Automated Certificate Checks - David O'Callaghan See slides. Tools checks against recommendations of GFD-C.125. Written in Perl and uses OpenSSL - familiar and easy for sys admins. Then shows a live demo. Reimer: do you plan to check signing policy file? Would be good to check. David O'C would like people to try this out and also help write the tests. He presents results on his analysis of current IGTF CA certs. Jens: would also be nice to have a tool to check EE certs. See the EUGridPMA CVS repository for this test suite. (same one as the distribution). Readme file has link to source. Milan would like a switch to set some tests to warning only. Ursula: EGEE OSCT will be very interested in this tool. 3. BalticGrid sel-audit - Hardi See slides. Accredited in Nov 2005. Issued > 1000 certs, >300 valid. 20 RAs across the 3 countries. First looks at B - minor changes required. CP/CPS is in RFC2527. He is considering changing to RFC3647 once the template is ready. C - Major changes required. CRL issue 7 days before expiry, Rekey not Renew - now fixed, operational audits (not all RAs have been audited) D - Must change. Private key pass phrase backup details. CRL needs to be V2. Reviewers of the audit: Emir and DavidG volunteer. DavidG asks how useful the self-audit is? Everyone confirms this is a useful experience. 4. Plans for future meetings, audits etc. DavidG shows the CA member status table. Austrian CA and CESNET CA will both present their new CAs at next meeting and therefore prefer not to audit their old CAs. GridCanada will migrate to TAGPMA. There has been no self-audit or report on this to EUGridPMA. There is a plan for a new CA (or move of the CA?) to a new organisation. We agree that the GridCanada CA should move (in its current state) to TAGPMA. INFN, PolishGrid, SlovakGrid and SIGNET are overdue and should be asked to do self-audit for the next meeting. Spain, Cyprus, Croatia and UK should do an audit during 2009 sometime. Locations of 2010 meetings: Possible offers: Dublin (18-20 Jan 2010 tentative dates), Riga (25-27 May, second choice 17-19 May), Zagreb (Sep) Jan 2011 - Spain, perhaps. --- coffee ------ 5. DavidG introduces a new topic. Globus have asked for guidance re a self-signed root CA and its signing policy file. The CA name must be allowed in the signing policy file so that the CA can sign itself. Before V4.2.1 the CA was accepted without this check. PMA agrees to feedback to Globus - don't do the check if it is a self-signed root. 6. Higher Level CA profile A reasonably up to date version is on the agenda page. DavidG proposes that we review this to then pass on to the other PMAs for approval. Jens (author of the document) takes us through the document. Detailed discussion not minuted. ---------- lunch -------------------------- Back to Higher Level CA document. Jens continues to lead us through the document. Again, discussion not minuted. Updated document, but not completed yet, stored on agenda page. David G says a big thank you to Andreas for the well organised meeting and for the excellent hospitality.