[CA-coordination-20020627 revision 0 (initial version) DG/20020708.2] 6th EDG CACG meeting 2002.06.27 ------------------------------- Present: Dave Kelsey (RAL) Brian Coghlan (TCD/IE) Jens Jensen (RAL/GridPP-UK) Milan Sova (CESNET/CZ) Anders Wanaanen (NBI/NorduGrid) David Groep (NIKHEF/DutchGrid) Tony Genovese (DoE) Mike Helm (DoE) Rafael Marco (IFCA/ES) Emanuele Leonardi (CERN, via VRVS) Sophie Nicould (CNRS/FR, via phone) Ursula Epting (FZK/DE) Jan Astalo\'s (Slovakia, astalos.vi@sarba.sk) Pawel Wolniewicz (Poland, pawelw@man.poznan.pl) Christos Kanellopoulos (Greece, skanct@physics.auth.gr) [First session, Thursday June 27, 14.30] Introduction ------------ Several new CAs are joining the CACG that are originating in the CrossGrid programme. CrossGrid is an EU project, coordinated by the Poznan HPC Centre in Poland, with partners from several other EU states and associated states. Information is available from <http://www.eu-crossgrid.org/>. The original idea behind CrossGrid was an "extended EU DataGrid", focussed on interactive applications. New applications are meteorology, flow calculations and biomedical imaging. CrossGrid will share a common test bed (and at least common middleware) with EDG. Besides the application WPs, there is a Middleware- and a test bed WP. For the first year, the test bed will be exactly the same as the EU DataGrid test bed, in the future newly developed middleware might needs its own test bed. We welcome the newly established CAs, but it does point to the long-term scaling problems accompanying the changeover from test beds to producion linked to both CrossGrid and, e.g., the LCG (LHC Computing Grid Project). Should this group keep growing or should a new entity be established. This item will be discussed under "scaling to production" agenda point and the relation to GGF. [Sophie leaves the conference call due to lack of audio] [The CERN VRVS connection is now permanently at 0 fps and no audio] Notes from previous meeting --------------------------- Action points emanating from the previous meeting: * on OpenCA: the dust only recently settled. Now Jens has the presentation, that will be shown later on in this meeting. Brian also has some slides regarding OpenCA. * on other open-source products besides OpenCA: several alternatives are available. In particular, Cristos will send info on "CSP", Jens on <www.pyca.de> and Mike will send info on other products. * on the expiration of long-lasting credentials while the job runs: Globus currently looks only at the subject name, so there is no apparent problem. However problems might emerge when a new proxy is needed, e.g., to send data home at the end of a job. We have not yet seen this problem on the current test beds, but there are in deed tools used that need re-authentication at the end of the job. At the moment these always relies on the *old* proxy. There is no way to get back to the user to get a proxy based on the newly issues key pair. Some confusion still exists on renewing CA root certificates, especially how to implement the use of new keys for a certificate with the same DN. Mike will contact the Von Welsh and Doug Engert about possible solutions and guidance. * Ursula has sent out the information. * On the Matrix: It is noted that there is still some non-compliance with the stated target. * On GGF attendance: some CA managers will be present in Edinburgh. * The CA directory configuration and examples are not yet in the CVS repository. It is on Roberto's action list. * on the CNRS catch-all CA. Sophie to contact Jean-Luc Archimbaud about updating CP/CPS to act as catch-all. Since Sophie just left the conference due to a dead phone line, the status is unclear and the action is left pending. Round-table ----------- David (NIKHEF): Since the CA has been in operation for more than one year now, the number of renewal requests in increasing. The renewals are based on home-grown scripts that generate re-keyed requests encapsulated in S/MIME messages. The result is better than what is produced by grid-cert-renew from the standard Globus Toolkit: this created a mangled subjectDN that needs a hacked version of the openssl "ca" command to go with it. The scripts are available for those interested on the Dutchgrid CA site <http://certificate.nikhef.nl/rekey.html> and the server side on <http://certificate.nikhef.nl/info/careq_renewal.sh>. Tony (DoESGs): Well established now. The ~10 DoE sites are being extended with new RA's in NSF and Engineering Grid projects. The potential subscriber community is ~20k users, but the ramp-up to this maximum is slow. A name change to the root and subscribers is due for purely political reasons. The old one will be phased out over a long period of time. Anders (Nordugrid): The NorduGrid CA just celebrated its first birthday. The re-issuing has now started, with many subscribers using the Globus-provided grid-cert-renew script (with the associated problems). The system has been moved to a secure location. New services get "service certs", and the issuance of host certs has now ceased. The CP/CPS will be with us shortly. Ursula (FZK & GermanGrid): Issued 29 certs till now. A new OID has been assigned to CPS. Highlights of the changes: - FZK has changed name of the CA to GermanGrid: "/O=FZKgrid/..." -> "/O=GermanGrid/..." - this namespace changed for political reasons. All EDG CAs are now being accepted in FZK, but for some reason the DoESG is not there yet. Milan (CESNET): Setup of an All-Academic CZ national CA is being postponed, whilst looking for new organizational form. This has no effect on the Grid CA. Jens (UKHEP): The new UK E-Science CA will be deployed soon, old certs will expire gracefully. Legal requirements needs RA to be appointed officially by a letter from the responsible from the physical institution. The RA procedure involves lots of politics. The physical security of the CA system is being enhanced by putting the entire system into a cage (not implemented yet). New keys will be generated when this security is in place. Namespace has changed slightly: the DN now identifies the RA that authenticated for the user. This is there for bookkeeping reasons only, and it is explicitly forbidden to use this component for authorization. (the DoESGs CA explicitly does not include this, because even when formally forbidden, such a field would surely be used for authorization by someone). As for the CP/CPS a draft exists, but presently contains mostly guidance for the RAs. Last checks for compliance with the Data Protection Act still need to be done. Christos (Greece): The CA in its birth phase will be called "HellasGrid CA". The structure will be embedded in a national CA infrastructure, with a root of which HellasGrid will be a direct subordinate. The server is in secure location, disconnected from the net. No certificates have been issued yet, but 60-100 are foreseen spread over three institutes. It will probably increase over time. A previous CA operated by the group had issued 300 certs. A draft CP/CPS is ready and is proposed for inclusion in the Matrix. A web site is there, a directory is soon to come. HellasGrid will act as a national Grid CA for Greece. Rafael (ICFA): The CP/CPS was updated to reflect that the RA changed jobs and went to CERN. With new requests coming in from all over Spain, more RAs are being set up. Also, new requests have come for Spanish-owned machines in Wisconsin. If they are truly Spanish-owner machines, they can come to ICFA. Otherwise, it might be worthwhile to send them to DoE. The people involved may not even know that the DoESG CA exists! If they are US owned systems, they should go to DoE. Similar problems appeared earlier with Nordugrid machines at CERN. The problem will be persistent, although the only proper solution would be for the DNS admin to issue the certs. In the relevant committees, the responsibility is being pushed around between PKIX, DNS, SSL, etc. working groups. A recent push within the PKIX IETF wg has been to put the FQDN not in the subject name but in the SubjectAltName. The subject name could then be an "arbitrary" string. This has been tried at LBNL, but results were not promising. Especially commercial software is not able to cope with this cert structure. The Globus "host/FQDN" notation is in itself incompatible with many commercial applications like Netscape, and also with the default verification routines in OpenSSL/Apache/OpenLDAP. Specifically, "ldap/FQDN" did not work in OpenLDAP, unless the FQDN was also in the SubjectAltName. OpenLDAP2 is now RFC compliant: checks the cert name against the name used by the caller (i.e. when issued with FQDN does not work with "localhost"). Recommended practice is to first check for the "correct" hostname in the SubjectAltName, and only then try the subjectDN CN component. CESNET puts for all host certs the FQDN in the SubjectAltName. This is STRONGLY RECOMMENDED for all CA's. It is also useful since it's required for IPSEC on OpenBSD. For user certs, CESNET puts the email there, but other CAs (at least UKHEP) has privacy issues concerning e-mail addresses. As a side note: Globus seems to be case insensitive, but all underlying code IS case sensitive. Pawel (Poznan): A CA system has been set up in secure room. This CA will serve the Polish grid research institutes (currently 5), for which RAs have been set up in all five cities. Till now only one certificate has been issued. An early draft of the CP/CPS exists (currently on paper only). On CrossGrid: A CrossGrid Information page is available on the web at: <http://grid.ifca.unican.es/crossgrid/wp4/ca/>. The CAs in CrossGrid are a part of WP4/TestBeds. The link to this page will be put on the EDG "marianne" site. It is noted that the is no CA coverage in Italy for CrossGrid. This is not considered to be a problem, since the only Italian partner in CrossGrid is DataMAT for dissemination. A Cyprian CA is not yet in place. Before inclusion and approval by the EDG CACG as "equivalent CA", the CP/CPS of the new CAs will be pre-screened by a subcommittee consisting of Brian, George and Rafael. A presentation on CrossGrid from their Krakow conference is shown. It can be retrieved from the main CrossGrid web site at: <http://www.eu-crossgrid.org/>. Jan (Slovakia II SAS CA): CA is on a dedicated server, non networked, based on OpenSSL. The draft CPS is based on the LIP version; comments are welcomed. To date no certs have been issued to any of the three organisations that are part of Grid-related projects. Brian (TCD): The "old" CA is still up and running, but since november 2001 no new certs have been issued. All the effort has gone into setting up a new OpenCA-based CA, for which the 31-day trial has started on June 10th. The new system is much more elegant then the previous setup, and much easier for the RAs to use. Mid July this CA will be switched into full production, and a new CPS will be issued since the namespace has changed. The RA name is coded in the DN here as well. There are no directory services yet, but certs are publicly available or listable on the web. CERN(by proxy): For the new CA issuing long-lasting certificates, the CERN "team leaders" will be acting as RAs. This new CA should have started already in May but is not yet operational. How the RAs will do the authentication is not yet sufficiently detailed. The technical part (typing "ca_approve" on system with AFS) is there. The CA singing system will remain off-line. As alternatives to the "standard" CA, CERN is investigating the use of automated CA's linked to their Kerberos KDC. It would be issuing Short-Term certificates based on Kerberos identities. This research is part of the LCG project. More information on the CERN CA is in a presentation, which will be sent to the list. More CAs are now joining the EDG CACG, and it may be nice to monitor the progress on a "management" level by producing graphs of issued user certs, host certs, renewals and revocations. An example is already in the presentation on the DoESGs CA. The graph binwidth should be approx. quarterly and collated before each meeting. The graphs will first be distributed to the group before they get wider publicity. Update on minimum requirements and procedures --------------------------------------------- (1) Lifetime of the CA root cert In the US, subscribers are asking for very-long-lived certificates (in the order of four years and more), since they are not particularly happy with having to do renewals. This has related implications for the root certs. Since root changeover is even harder, DoESGs CA prefers a long (>30yrs) lifetime of the root cert, and then devolve the actual signing to subordinate CAs with a shorter life time. Within the CACG, earlier discussions focussed on the relation between lifetime and the number of bits. Although a recent publication claims to have brought down the time to crack keys, it is yet unclear whether the statement are really applicable to "large" keys (>=1024 bits). But a relationship between keysize and crackability does exist, and we should prepare for new technologies (both faster systems and new algorithms) to emerge in the coming years. In practive, the keysize cannot grow much larger, since most commercial hardware key storage devices cannot handle 4096 bits and above, setting the keylength to 4096 limits your vendor choice to just one supplier. Also, most Netscape 4.x browsers cannot handle user certs with a key length >1024 bits, although Mozilla can. In the end, the main security risk is with the subscriber and his care in handling the private key. We have no control over the user handling their keys, e.g., whether they use null-pass phrases etc. The initial response from DoESGs CA to long-lived (>1 year) user certs was therefore negative. Because people do not stay in a position for a very long time, change jobs etc. and machines get decommissioned periodically. Revocation is still a weak system and is not able to cope with rapid changes. In the end, no-one takes the responsibility to oversee the termination of certificate validity. On the other hand, NASA IPG and the Alliance CA issue 4-year end-entity certs. Under the current minimum requirements the EDG CACG would not allow this. However, it does bring down cost. For the DoeSGs, issuing one cert costs about $1000 in manpower, machines, training, etc. Even if an infinite number of certs is issued, the cost would still be $5 to be paid to IPlanet CMS. For new, with only a few certs issued, a cert costs $10,000! In the end the basic reasons for changing the end-entity cert life time are: * user requests: DoESG subscribers want to change it to 2 years * less work for the CA staff and reduced cost Lifetime of the end-entity certs and the CA cert lifetime are linked. With longer end-entity life times, you will have to renew your root CA certs quite frequently. This may at some time wreck havoc on the Grid, especially when many root certs expire at or around the same time (the same problem that VeriSign had on Dec 31st, 1999). Although EDG seems better organised than many of the US grids, the problem might one day pop up. In the end, it is the responsibility of the site administrators as relying party to "trust" the CAs they install. Within the EDG Test Bed, Anders implements the consensus of this forum as policy. Since we are only concerned with asserting a "reasonable identity" bond between a certificate and an end-entity, our issued certs are not to be used as the sole basis for an authorization decision. This is also a pretty good reason to opt for a "flat" name space in the certificate subject name. Taking into account all of the above arguments, we decide to leave the wording in the minimum requirements, being "... lifetime of personal or host certificates must be no longer than one year", unchanged. Other alternatives, in particular changing "must" to "should" are not rejected out-right, but are not deemed necessary. In the end a user with a long-lived cert can be banned at an individual site, according to that site's policy. (2) Renewal The current version of the minimum requirements has no section on renewal. In particular, it is unclear whether in the renewal or re-keying process the end-entity should be re-authenticated, i.e., should the subscriber go to the RA again. Different CAs (and organisations) now use different mechanisms and standard. In DoE, this process is distributed to the individual labs; at CERN, one needs the signature of the Team Leader again (although is includes also authorization). A "renewal" section is therefore needed to be added to the minimum requirements document. This item should be discussed on the mailing list. The new version of the minimum requirements document will be called "... for test bed 2". Input regarding the evaluation of the current policies should come from site managers and security officers. (3) Network security of the CA signing machine In the minimum requirements it explicitly stated that de CA signing machine must not be connected to any network. The reason being that, if the CA key is caught, the malicious party can issue certificates with a new key pair but with the same subject and thus gain access to all the resources to which the original subscribers have access. The DoESGs CA uses a Hardware Storage Module (HSM), where - the private key cannot be extracted from the hardware module - the break-in needs to happen whilst the CA activation data are present inside the CA software. If you get access to the system you can still re-generate certificates, but, you have to break both the on-line machine and the CMS IPlanet software containing the activation data, before you can access the HSM. In particular, a brute force attack to take the key from the CA does not work. Moreover, it is earlier to crack the RA systems: all the protections on the HW storage module will not be able to protect against this. Thus, your administrative roles are sufficiently harmful already. By use of a HSM, the private key of the CA is sufficiently well secured that it is no longer the weakest link in the signing process. It thus fulfills the intentions expressed by the minimum requirements document. In the new version of the min. req., the wording will be changed so as to allow this particular grade of HSMs: they should be compliant to the FIPS-140 standard at Level 3 or above. Only then is the CA machine allowed to be on-line, when suitably protected. The exact phrase to be used when referring to FIPS-140 Level 3 will be sent by Mike. We leave the option open that acceptability of an on-line CA machine can be decided on a case-by-case basis by the CACG. If we do so, the wording in the minimum requirements may become "acceptable method". Significant worries about such a phrase are expressed by several members. [Next day, starting at 9:15] (4) Registration Authorities and Authentication The current requirement for authentication by RAs is by some "rigorous means". It is unclear what these means should be, especially in the wake of a large user community. The scaling of the RA process, with potential subscribers appearing in-person before an RA is cumbersome for distributed communities like CERN and iVDGL (many users scattered over many campuses). The CACG will insist on an exact description of the practices of a CA in its CP/CPS. The methods used may differ between the CAs, but the CP/CPS should give sufficient detail to judge whether the methods are adequate and equivalent. The wording in the minimum requirements will remain the same. The new proposal for the CERN "long-lasting" CA is to use the exsiting Team Leader hierarchy to act as a RA system. All potential subscribers to the CERN CA have authenticated at least once in-person to the Users Office. On renewal, the default is to show u at the Users Office as well, although dispensation may be given. For renewal, the Team Leader has to re-affirm the identity of the (CERN) user and sign for his/her affiliation. A primary concern may the the "ease" of getting identity certs. Like in the issuance of passports, getting/stealing a passport is relatively easy, but making a good forgery is much more complicated. All malicious efforts therefore goes to getting official papers issued to "false" entities. Finally, the absolutely weakest link is the end-entity itself: however strong the authentication and strong the signing process, there is now way to enforce good pass phrases by users. In the end, the whole process should be "reasonable", so we keep the wording as-is: "... acceptable procedure for confirming....". Further discussion on RA authentication procedures for a "Test Bed 2 version" of the minimum requirements should be done via the mailing list before the end of the summer. The DoEGrids Public Key Infrastructure (by Tony) ------------------------------------------------- (see the DoEGRids web site at <http://www.doegrids.org/>) The scope of the DoEGrids CA has expanded to include sites part of iVDGL (an NSF project) and Earth Sciences. The community now consists of PPDG, FusionGrid, PNNL, ORNL, ANL, NERSC, DoESG, LBL, iVDGL and soon EarthScienceGrid. The main impetus still comes from the PPDG project. The DoEGrids CA is operated by ESnet under funding by DoE. Because of the extended scope, the name of the CA (and the root certificate) has changed to reflect this broadening. A 15-member PMA has been established. October 15th is the official launch date of the new CA. By June 20th, 2002, 258 certs have been issued (101 users, 100 hosts), 5 requests are pending and 29 have been revoked. A proper RA operator should have a turn-around time of max. 1 week. The revocations are largely due to errors in the namespace that have not been trapped by the RAs. It is hard to prevent such errors, since the use of name constraints breaks much software including OpenSSL. It is close to unusable. [an interesting discussion on firewalling and network topology of the CA signing systems has been suppressed] GGF CP Working Group -------------------- Version 6 of the GridCP is finally finished, with the document changed to a guidelines text for Grid CAs. The working group has closed down. A new CA-OPs (CA Operations) Working Group is in the process of being established. This new working group will focus on PMAs, cross-domain trust, CRL management and certificate profiles. The new draft in GGF on PMAs is now out, taking the EDG CACG as an example of a working PMA. The BoF for the new working group is scheduled in GGF5 in Edinburgh. Everyone is invited to send outlines, a slide with issues, etc to be discussed in the BoF. CA Matrix and Automatic Evaluation (by Brian) --------------------------------------------- A few changed are proposed to the submission templates used to fill the feature matrix. A group "publishing" has been added that incorporates the "frequency" and "max_latency" data of certs and CRLs. The unit for these variables is "days". Other changes are still to be discussed. Planed is the extension of the problem/rating/issue scheme with a "grade": a factor that defines the "badness" of a particular issue. Since many minor issues might constitute a big issue, the "grading" of issues, like "0.4 x Major", allows to express that many not-so-bad issues within one category taken together can accumulate to a big issue *AT THAT LEVEL*. Accumulation of minor issues can not lead to a major issue. For now the accumulation will be a linear sum. Automatic extraction of a "rating" from a CP/CPS is difficult but work has started on this. The focus is on a common standard to define a CA. To do automatic grading, the CACG should define a rule set that will evualuate the feature matrix (later maybe also other criteria) and assign a weight@class grading. Individual CAs can than make their own extensions to the ruleset when they want to give "advise" to the national user community. Currently, the automatic grading based on the feature matrix "half-works". A simple rule set syntax can be evaluated. The content of the final rule set (which would reflect the minimum requirements) should be discussed in the CACG, preferably on the mailing list. Brian will send out a mail with the working of the rule set and initiate the discussion. A presentation of this work for GGF is very appropriate: it is the necessary foundation for a future Bridge-CA for Grid. The presentation should preferably be given by Brian, if he is going to GGF5. Otherwise, it may be postponed to GGF6 (October). What should go where in the CP/CPS is generally unclear. This makes an automatic comparison based on the exact CP/CPS difficult. A good guidelines document is the "PAG" standard published by the ABA (American Bar Association). Although full of legalese, it is quite useful. It can be found at <http://www.abanet.org/scitech/ec/isc/pag/pag.html> The document explains, section by section, the "proper" interpretation of RFC257 (the new RFC has a similar structure, just some omissions have been corrected). It can be used to self-audit your own CP to see whether the proper stuff is in the proper sections. OpenCA, modifications and operation (by Jens) --------------------------------------------- See the slides at <http://ca.grid-support.ac.uk/user-documentation/prague.ppt> and the working system on <http://ca.grid-support.ac.uk/> The work at RAL was based on OpenCA version 0.8, but has been heavily modified. Problems were encountered in the area of browser support, where different key-generation commands were needed for Netscape 4.7 and MSIE. Mozilla has yet another set of peculiarities, and Opera support is largely lacking although key generation should work. The database format used by OpenCA 0.8 is BerkeleyDB, whereas v0.9 uses mySQL. A demo of the RAL-version is available at <http://ca.grid-support.ac.uk/> Brian has also worked on OpenCA for TCD. Fewer changes have been made to the OpenCA core, but the service selection web page was re-written, making use of the OpenCA CGI scripts in the background. Cross-trust establishment for FZK/GermanGrid CA ----------------------------------------------- A draft CP/CPS for the FZK Grid (version 0.1) was distributed to the mailing some months ago but did not trigger many comments. A new version (0.2) dated June 2002 is now available. At present only one "remote" RA is operational (in GSI,Darmstadt). In the future this number is expected to increase as more institutions in Germany join Grid projects. To reflect the national scope of the FZK CA, the certificates signed are in the namespace "/C=DE/O=GermanGrid", although the name of the CA roor cert is "/C=DE/O=FZK-Grid/...". It is unclear whether the "/C=DE/" top level is still managed in Germany. The CPS is unanimously accepted and the FZK CA is therefore an CACG approved CA. The RPM containing the root cert, CRL reference and the signing policy will be created by Anders and distributed to the EDG test bed sites as part of release 1.2. Cross-trust for new CrossGrid CAs --------------------------------- Within the CrossGrid test bed CA working group (within CrossGrid WP4) there will first be an internal check of the CP/CPSs. If this CrossGrid group (Brian, Rafael en George) approves a CPS, a discussion on the mailing list and a presentation in the EDG CACG will follow. The discussion and the presentation will be input for the acceptance decision. After approval a new CA will be put in the Matrix. Personal contact between the CACG and the prospective CA manager is deemed to be essential. For the new CrossGrid CAs (Greece, Slovakia and Poland), presentation will be given at the next CACG meeting. The Greek and Polish CAs will be ready for operation at the end of July, the Slovakian CA will follow in September. In the meantime, the new CP/CPSs should be distributed on the mailing list, and after three weeks of discussion these three CAs can be "provisionally" accepted (and the RPMs put in the EDG package repository). On the next meeting, there should be a formal presentation before a final decision is taken. Since no EDG release is planned till September, the new RPMs will have to be pushed to the sites "by hand". The users of CrossGrid are dependent on the acceptance of the new CAs in the CrossGrid test bed, and since that test bed will be largely shared by EDG and CrossGrid, implicitly also on the EDG test bed. Christos will therefore make an instant presentation already at this meeting. CA Publishing Directories ------------------------- It is unclear what the requirements on a CA operator are with respect to publishing the certs and related information in a public repository. All the information is there in the mail exchanges on the list during the last few weeks, but it should be put together in a document so that new projects can easily find the info. There is the opportunity to make a general document and put it to GGF. Mike and Roberto should create a draft for this document, in the format of a couple-of-page operations guide. This document should contain the specific schema, the name forms to be used and the tree organization. And there should be some info about who needs the directory, and specifically about the Authorization VO tools. The HellasGrid CA (by Christos) ------------------------------- The HellasGrid CA is managed by the PHYSNET team at the dept. of Physics, Aristotle University of Tessaloniki. The CA signing system is in a controlled environment on a dedicated server that is not attached to any network. The 2048-bit private key is kept in a safe, protected by a suitable passphrase. The HellasGrid CA cert itself is signed by the PHYSNET ROOT CA. Lifetime of the Grid CA is 3 years, of the PhysNET root CA 5 years. CRLs are issued according to the minimum requirements, Audit records are archived for 10 years. Authentication of end users: Everyone has to come in person to the CA, which is still reasonable given that Christos travels regularly between both Athens and Tessaloniki, the two sites that actually use the HellasGrid CA. In the future a new RA will probably be established in Athens. The authentication policy, being a bit cumbersome in the long run, is likely to change within a year. A pointer to the CP/CPS is on the CrossGrid web page (see above). The OID is 1.3.6.1.4.1.13089.2.1.1.1.3 The HellasGrid CA cert is particularly "feature rich" with lots of extensions. It is Christos experience that this is extremely useful: users can use this info to find the proper information back. On the other hand, Roberto has always favoured less info, since the exact information is likely to change more frequently that the lifetime of the cert. It is clear that GGF is the proper forum to discuss such matters. Brian will send a overview of possible extensions to the list for reference. CRLs and CRL "validity" ----------------------- Problems with the CRL publishing by DoESGs earlier this year was mainly due to a communications mismatch: lack of clear documentation on the use and on what the community needs to get things running. The use of the CRLs is required in EDG TB1. To facilitate the retrieval of new CRLs, this there is a tool distributed as part of EDG TB1 that does "wget". Since many of us come from a Globus background the most obvious thing was a URL with a PEM formatted CRL, since that's the format used by Globus. Also, Globus uses particular conventions to interpret the CRL. The nextUpdate field is interpreted as "valid until". This is a mis-interpretation of the X.509 standard: if the ITU had intended "validity", the field would have been called "validity"! Mike and Tony opened a bug with Globus on this issue. CRLs were introduced in the Globus Toolkit about 5 years ago in request of a different party for formal reasons. In reality, Globus currently does not really care about CRLs. But EDG does care, and requires CRLs for use with Globus. It is clear for these and other discussions that a *single* document is needed that details all the EDG requirements. It should include required publishing info, file formats and a brief statement of its intended use. Anders volunteered to write this document. Next Meeting ------------ It is generally felt that the current meeting is slightly too short, since we never finish the agenda. To increase efficiency, the next meeting should probably be a bit longer (1.5 days), starting at 1 PM on the first day. The exact date/time will be discussed on the mailing list, the proposed meeting place is CERN. The meeting must be held before October 15th. Other nice dates: * 5th EDG Conference, first week of September, Budapest (not a particularly suitable location for a CACG meeting :-) * October 2002: GGF6 in Chicago. Action List of the 6th CACG meeting ----------------------------------- 6.1 OpenCA alternatives by: Christos, Jens, Mike On other open-source products besides OpenCA: several alternatives are available. In particular: a) Christos will send more information on "CSP" b) Jens will send info on <www.pyca.de> c) Mike will send info on other packages 6.2 Renewing certificates with same DN but different key in OpenSSL by: Mike Some confusion still exists on renewing CA root certificates, especially how to implement the use of new keys for a certificate with the same DN. Mike will contact the Von Welsh and Doug Engert about possible solutions and guidance. 6.3 CA directory configuration to be put in CVS by: Roberto The CA directory configuration and examples are not yet in the CVS repository. It is on Roberto's action list. 6.4 Update of the CNRS CP/CPS regarding catch-all by: Sophie Sophie is to contact Jean-Luc Archimbaud about updating CP/CPS to act as catch-all. 6.5 CP/CPS of NorduGrid by: Anders The CP/CPS for NorduGrid will be distributed by June 30th 2002. 6.6 SubjectAltName convention for host and service certs by: all It is strongly recommended that all CAs put the FQDN in the SubjectAltName extension for all host and service certs. 6.7 Link to CrossGrid CA web page to be put on "marianne.in2p3.fr" by: Sophie A CrossGrid Information page is available on the web at: <http://grid.ifca.unican.es/crossgrid/wp4/ca/>. The link to this page will be put on the EDG "marianne" site. 6.8 Pre-screening of new CrossGrid CA CP/CPSs by: Brian, George and Rafael New CP/CPSs from the CrossGrid CAs are to be pre-evaluated by this subcommittee before approval during the 7th CACGmeeting. 6.9 Presention on the new CERN CA by: someone from CERN More information on the CERN CA is in a presentation, which will be sent to the mailing list. 6.10 CA scaling graphs by: Dave and all Quarterly data summary (issued user certs, hosts certs, renewals, revocations) to be made and collated for each meeting. DaveK will send the request of to the list. 6.11 Renewal section in the minimum requirements by: all A "renewal" section is therefore needed to be added to the minimum requirements document. This item should be discussed on the mailing list. 6.12 Use of HSMs allows a CA signing machine to be on-line by: Mike The extact phrase to be used in the new version of the Minimum Requirements about on-line CA machines regarding the FIPS-140 standard at Level 3 will be sent by Mike. 6.13 Authentication procedures by RAs by: all Further discussion on RA authentication procedures for a "Test Bed 2 version" of the minimum requirements should be done via the mailing list before the end of the summer. 6.14 Discussion on the basic ruleset for the automatic evaluation by: all The content of the ruleset to be used for automatic evaluation of CAs in the CACG should be discussed on the mailing list. 6.15 Explanation of the ruleset syntax used for the automatic evaluation by: Brian Brian will send out a mail with the working of the ruleset and (thus) initiate the discussion. 6.16 FZK "GermanGrid" CA RPM to be created and put in Release 1.2 by: Anders Status: DONE The RPM containing the root cert, CRL reference and the signing policy will be created by Anders and distributed to the EDG testbed sites as part of release 1.2. 6.17a New CrossGrid CAs by: Christos, Pawel, Jan Send the draft CP/CPSs to the mailing list 6.17b by: all Discuss the CP/CPSs within three weeks on the mailing list 6.18 Create CrossGrid CA RPMS by: Anders If a new CrossGrid CA is accepted after discussion, create the RPM and put it in the EDG repository. 6.19 CA publishing directory documentation by: Roberto, Mike This document should contain the specific schema, the nameforms to be used and the tree organization. And there should be some info about who needs the directory, and specifically about the Authorization VO tools. In the format of a couple-of-page operations guide. 6.20 List of possible X.509v3 extensions to be sent to the list by: Brian Brian will send a overview of possible extensions to the list for reference. 6.21 Single-source document detailing the requirements for new CAs by: Anders Anders will write this document for EDG. It will detail what is required to include a new CA, and what the CRL is used for. 6.22 Date for next meeting by: all Discuss new date on the mailing list. It should happen before October 15th.