CA coordination meeting 2002.03.05 ---------------------------------- [CA-coordination-20020305-1.txt] Present: Dave Kelsey (RAL) Brian Coghlan (TCD/IE) Milan Sova (CESNET/CZ) Ursula Epting (FZK/DE) Marcel Kunze (FZK/DE) Roberto Cecchini (INFN-FI/IT) Holger Marten (FZK/CrossGrid) Sophie Nicould (CNRS/FR) Jorge Gomes (LIP/PT) Jens Jensen (RAL/GridPP-UK) Rafael Marco (IFCA/ES) Anders Wanaanen (NBI/NorduGrid) Daviel (CER) Lev Shamardin (SINP/RU) Cal Loomis (CNRS) Akos Frohner (CERN) Leon Gommans (UvA) Introduction ------------ No update to notes of previous meeting Round table reports ------------------- Brian: Setup of the GridIreland CA has been done for some time. A port of the existing system to OpenCA has started, but still needs work. More experience on OpenCA will come from RAL, which in in the process of modifying OpenCA to suit the GridPP/UK E-Science needs. The current IE-CA is down and will be replaced by a new one in the near future. The new one is going to be OpenCA-based. Lev: An OID has been assigned to CP/CPS (1.3.6.1.4.1.11809.1.2.1.0.1). No more changes are expected. About 60 certs have been issued. Anders: Issued about 30 certs in NorduGrid using an OpenSSL based CA. Also this CA is going to move to OpenCA; Anders did not yet hit any problems, but on the other hand the changeover did not go very far yet. Host certs have been issued to finnish machines at CERN; this practice should be phased out. The one who assiged the IP name shoudl in the end also give out the host certs. For now, since the machines are Finnish owned, they got a NorduGrid cert. DavidG: There have been on changes in the production CA. For giving certs to students, a separate light-weight CA was established (DutchDemo). Experience with the student is quite bad, many requesting certs multiple times, not responding to emails, and they are generally clueless. Jens: For the E-science CA new namespace has been decided, which is strongly hierarchical. This decision is final and cannot be changed without a *lot* of discussions. It has been implemented on a home-modified version of OpenCA (which costed one FTE in writing new code). The code does not look neat yet, and is in need of a general cleanup before it could be contributed back to the OpenCA distribution. A description of new results to be distributed to the mailing list after the dust settles. The system is now being tested by knowledgable local users. Other users will follow in a couple of weeks. A draft CPS (for users) has been written. User guidelines, RA guidelines, etc still to be established. It should be noted that more open-source CA administration packages exist, besides OpenCA. References will be provided by Roberto on the mailing list. Milan: On Jan 15th, all certs expired. New certs have been issued, with a lifetime of 1 year. On strong requests from the users, the affiliation is also in the new certs (despite pressure from Milan). Because they are working on a WP in EDG where the affiliation was used for an authorisation decision. The CP will be changed shortly to make affiliation optional, as a preparation for later when it will be completely phased-out. Roberto: Nothing new. Going to switch to a proper RA structure, since the current situation is not suitable for TB2 (for TB1 it still kind-of worked). There will be one RA per INFN site. The specifiation is now being written and then go through proper method to change CP and assign the RA's. Sophie: The overview slides presented by Sophie are summarized briefly: For all of the CNRS CA's: * 1000 certs issued +1800 by CNRS-Test before February * 75 RA's in various institutes in France * every week about 30 certs issued for all of CNRS, in the future all 24k personnel of CNRS will get a certificate. For DataGrid-fr: * Sophie is the RA, she asks a local contact in the relevant lab. * 20 units and 5 non-CNRS institutes. * 148 certs at Jan 9, 2002 * 132 valid (70 pers, 62 servers) * 14 revoked * 2 expired * special charcaters (>127) in the subject name cause funny behaviour in openSSL! * Datagrid-fr will act as the catch-all CA. The other institutes signed by Datagrid-fr are: CEA/DAPNIA CS/SI ESA/ESRIN [/C=IT/O=ESA/OU=ESRIN/...] TU Dresden/IKTP (BaBar) [/C=DE/O=TUD/OU=IKTP/...] Univ. Research Assoc (test) [/C=US/O=URA/OU=FERMILAB/...] Innsbruck [/C=AT/O=UIBK/OU=HEPG/...] These namespaces should be in the TB1 RPM's, although Innsbruck is not yet included. The link with Taiwan is not yet established. The Datagrid-fr renewal procedure: * 2 month before expiry user get e-mail whether he wants renewal at all. * If so, an email is sent to original RA to confirm the user's current status and affiliation. * The DN stays the same, but the subscriber will get a new keypair (via browser using a link contained in the e-mail). To do any renewwal in OpenSSL, first set the status field in the "index.txt" file to "E". Jorge: The LIP CA lifetime was one year, and has now expired. The CA keypair has to be changed and new certs will be issued. The proper procedure would be to issue a new CA keypair well before it expires so do not issue certs that have a longer lifetime than the CA root cert itself. So have an overlap of at least one year. The DN of the new CA root cert has to be the same (OpenSSL will use the ".?" convention). [some discussion ensues over miltiple certs for the same identity for extremely long running jobs; discussion will continue later] Daniel: Now issuing 5-10 certs per week, and CERN is getting increasingly concerted with the roll-out of the CA to >1000 users. For identity check locally to CERN, the RA has a look at local account users to see whether there is any activity. For new users there is no real problem, since they have to show up at the User's Office in person anyway. But there is a backlog of several 1000s users who may not be (permanently) at CERN. In the short term, the root cert will expire at end of September. A detailed plan for changeover still needs to be defined. Rafael: By ICFA/ES, 50-100 certs have been issued. A (new) CP/CPS is being drafted. Ursula: draft for CP/CPS written and published on the FZKCA web site. The web site itself is not yet completely finished; working on on-line application procedure. Suggestions are very welcome. The draft CP/CPS (or pointer) will be send to the mailinglist. Any RA's? Currently only one, at FZK, later grouping will be per experiment. Duscission on this in Germany has just started. approx. 10 certs issued. Review of policies and practices and the Matrix ----------------------------------------------- Some clarification and small modifications: * What is now just freqency, will be made into three fields: publication_frequency [unit: days] publication_latency [unit: days] publication_validity [unit: days] * cert_issuance? Now: {personal_contact|email|phone} New: logical expression AND, OR and (). Extend it with "contact_with_superior" "public_directory" Brian is foreseeing problems in scaling up the Feature/Acceptance Matrix. The Matrix will only scale if: * inspection is done by machines not people, accoring to a ruleset * scope is deliberately limited, e.g. to VO's * each VO should run own copy of the script to do the extraction, limited to their set of relevant CA's (although there will be a problem if people start moving between CA's) Feature matrix admin will scale: * each CA manages their own report file on own site * un-blacklist a CA as soon as next remote access to their report file (not yet done in software) * the software automatically adepts to the addition or removal of CA report files. The feature matrix is not (yet?) flexible enough to address all the issues in the report files. The report files should be on third-party neutral site. The reports currently cannot take into account new versions of information provided by the inspected CA's. So if the CP/CPS of CA-A changes, the reports on the old version of CA-A's CP/CPS should be invalidaded and everyone must reread that new CP/CPS of CA-A. To facilitate this, the report files could be split into a feature file (partly extracted from the CA LDAP server and from issued example certs and CRLs), and into a (set of) report files, probably stored on the various evaluating CA sites. This can be accessed remotely and assembled (periodically?). Functionality requirements: * utilization by programs via RGMA/MDS/LDAP * exceptional incuidents by manual inspection * fault-tolerance via replication of (LDAP) services * notification of changes to a CA via: (i) email, (ii) RGMA notification? Summary: * each CA published his feature matrix * automation where ever possible The goal of the matrix should be made a bit more clear: the site admins now see a whole set of different comments and he is not in a position to decide. The final list should be based on a common policy and a standard sets of criteria. There should be group consensus about the classifiation of the ruleset and then the evaluation can be automatic. The Matrix is a excellent first step to classify the comments and draft the ruleset and severity levels. Then there will be one rating per CA and a site admin can set the level or check-patterns and automatically decide which CA's to except. *** Immediate action point *** Everyone MUST fill the Matrix (and READ the CP/CPSs) so we can identify the different options, and the discussion about the rating SHOULD be done on the list as to involve Tony and Mike. Brian will try to implement some of the features (complex one will come later). GGF Working Group (GridCP) -------------------------- The ongoing work in the GridCP group is going more into the direction of a recommendation than a binding CP for all compliant CA's. Also, the strong auditing framework is weakened, largely because of lack of volunteers for autiding. One thing to note: we SHOULD have been there in Toronto, and MUST be there in Edinbourgh in July 2002. Cross Authentication HICB/Intergrid ----------------------------------- DoESG ----- The notes Tony made are on the mailing list. There is "universal" consensus that the DoESG CA should be added as an RPM to the TB1 list. The root cert will be shipped to Anders in a secure way (offline discussion will ensure this). FZK (Holger Marten) ------------------- The EU CrossGrid project is an extension programme for DataGrid, focussed on real-time interactive grid work. Since they base their development partly on the EDG core middleware, they wants to cooperate closely with Datagrid and not build a new grid infrastructure test bed. The FZK-Grid-CA now has a CP/CPS draft at version 0.1. Open questions are: * how to connect to EDG CA's * shall FZK prepare entry in Matrix * Should CrossGrid build its own VO's or use existing ones for the LHC experiments? Every country should have a CA, so there will be about 7 new ones in the combined EDG/XG world. There is not a real forum that does down-to-earth handling of CA's; it should in the end go to GGF, but for now new CA's will likely go to this group. The future might be a bridge-CA for grid test beds in Europe (if the software is reasy for this!), but at least the policy/acceptance criteria have to be defined before you can go to define such a thing, and before the group grows even more. For now, there will be one CA per country, issuing certs for all kind of Grid projects. The cetificate must not convey authorization info, although the scope of the various CA's implicitly relays information about projects and project authorization. Affiliation to a specific project like EDG is defined by being the Guidelines VO (now on marianne). Review of procedures WP6/TB1 ---------------------------- The CA LDAP directories are needed to support the graphical tools for the Authorization tools, but it is not blocking because a commandline tool exists. In general, the number of CA's the implemented the LDAP directory service is extremely low (only three out of 11!). To promote the deployment of directories, Roberto will send the relevant data (schema's etc) to the list and put them in CVS. It is unclear whether the OpenCA LDAP server is sufficient for the EDG purposes. Some CA's have privacy/data protection issues that will prevent them from ever setting up a directory. Catchall solutions ------------------ CNRS sets up a Registration Authority for every site that will be caught by their catch-all CA. The procedures for RA assignments will be made very explicitly in a new CP/CPS of CNRS. Sophie will contact Jean-Luc to make the CP/CPS more explicit. To take on the role of catch-all CA, the signing-policy file for Datagrid-fr will have to change frequently. Therefore, a change in the ca-signing-policy file from CNRS will be automatically accepted by Anders. It must be posted to the list and only if someone has complaints the entry could be removed later. Review of procedures WP6/TB1 ---------------------------- Foremost important point for WP6/TB1: the stability of CA availability and operations "Nice feature" requests from WP6/TB1: * subscription service for CRL's? would reduce exposure for compromised certs. -> Proper solution is OCSP * Registry for recognized CA's (per-site level dependent acceptance of CA's) subscription service of CA modification information (i.e. revocation of CA root??) Next meeting ------------ Next meeting will be in June (before GGF). Location and date TBD.