Minutes of the DataGrid CA coordination meeting CERN, Tue 2001.06.05 ------------------------------------------------------------------------------ Present: Jean Luc Archimbaud Roberto Cecchini Brian Coghlan Jorge Gomes David Groep Dave Kelsey Pietro Martucci Andrew Sansum Mika Silander Milan Sova Round table reports and status ------------------------------ CERN: new CA setup on separate machine, issues 2 user certs till now CP/CPS coming soon [either <15 june of > 15 july] cross checks have been done with INFN Milano only, experienced no problems. Additional testing expected when the Globus cert from Erik van Herwijnen (LHCb) expires this month. Plan: add a web-based key generation facility, perusing the experience of others INFN: regular management only, issues 800 certs, of which 80% grid-related. Also has approx. 20 CRLS, of which ~2 due to compromise, rest due to loss of key of passphrase. NIKHEF: mainly management. Performed some testing with modification of key extensions in CA certs without invalidating already signed subscriber certs. See http://certificate.nikhef.nl/ CESnet: CP and CPS ready. Some open questions are: - is there a namespace prescription? No, the "/O=Grid/*" is prescribed by WP6 for the Information Services only (GIS) - extensions? Roberto has some hints for extensions: * basicConstraints should be set appropriately (CA:TRUE or FALSE) and MUST be critical * keyUsage, SHOULD be critical, but is not usually set as such dataEncipherment flag is suspected not be needed for encrypted communication. The new Globus CA cert (currently in CVS) will have some extensions added but using old key pair (issues certs remain valid). See the Globus Security and Java (sic) mailing lists for details from Doug Engert. CNRS: CNRS has a tree of CA's, with DataGrid-fr beging a tier-2 CA signed by CNRS-Projects which is signed by CNRS. The Datagrid-fr CA will sign anyone who is proposed by the two RA's (Sophie Nicoud and Francois Etienne). Jean-Luc will not do additional checking. UKHEP: the new CA has a key valid till october 2001. Signed 25-30 certs, no CRL yet. UKHEP grid is currently migrating all the gatekeepers to use UKHEP certificates. The new CA starting in october will be more sophisticated and have a real CP/CPS. LIP: now uses a new CA key with more bits. Mika Silander (WorkPackage 2 representative): WP2 has been testing the gsi-enabling of various applications. Main observation is that the use of the GSI is extremely sensitive to seemingly minor details. General concerns is the scalability of the authorization issues (gridmapfile, etc.) References: http://www.hep.grid.ac.uk/gridmapdir/ GGF and Terena news ------------------- The GGF security-wg is currently trying to establish a minimum set of requirements for the CP/CPS in the grid context. Drafts can be obtained from their web page at http://www.gridcp.es.net/ TerenaPKI (http://www.terena.nl/projects/pki/) EuroPKI is not making everyone happy, since it allows for only one level of certification. In general, CAs want to issue a range of certficiations, each with a different level of identity assertions, something that EuroPKI does not allow for. A general issue i fthe use of non-grid specific CA's. Finnish government will be operating a national CA issueing smartcards to the population- at-large. Does DataGrid trust these certs for use on the grid? With the large number of CA's there is a scaling problem. Policy-level hierarchies are proposed but not to be persued. In the GGF, there is a standardisation effort to classify policies into four trust levels. It is considered important that we keep in good contact with this effort (e.g. at EuroGlobus/Lecce). CA CP and CPS review, general statements ---------------------------------------- Regarding Jean-Lucs question on who is entitled to certification by a CA, the general consesus is that its not a relavant issue. Certificates issued by the national CA confirm identity and are not to be used for autorization purposes. That's for the gridmapfile. All CPS's are to be publicly available, since we will not do any on-site auditing. We find no reason to restrict access to the CPS anyway. Do you need to re-issue all user certs if the policy changes? You can change the CP/CPS without reissueing the user certs, provided that: - you keep all versions of the CP/CPS available (online) - you put a pointer to the CP/CPS effective at time of signing in the issued user certs (e.g. a revision number in the nsComment field) - and change the OID of the CP/CPS in case of significant changes (if a OID has been assigned) We strongly discourage post-dating of certificates, i.e., the notValidBefore date should be equal to the date of issue. CP/CPS checks ------------- From the checking of the CESnet CP/CPS and the CNRS Datagrid-fr CA, we can abstract the following general remarks and recommendations: - renewal of user certificates using the old private key IS NOT allowed. - although CRL v2 is generally recommened in PKI literature, Netscape does not except them, so it might be useful to issue CRLv1 (for Globus it is not a problem) - we iterate that the CA MUST NOT generate a keypair for an end-entity - new CP/CPSs should follow the RFC 2527 format, but - CP and CPS should preferably be combined in one (1) document - the CA key should not be used by an automat, and the CP/CPS should be careful not to suggest such a practice - it is noted that Netscapwe encryption is generally considered weak - the CA machine MUST be disconnected from any network On X.509v3 extensions in user certs: - SubjectAltName SHOULD contain the e-mail address of the user - KeyUsage MUST be critical - nsRevocationURL is a link to an online check returning "0" or "1", it is *not* a pointer to a CRL! - nsCaPolicyURL is nice to have Requirements on CP and CPS -------------------------- In addition to our old minimal requirements list, we add explicitly that: - Every CA should have a CP and CPS - both user and host certs are valid for one (1) year and MUST have a key length of at least 1024 bits. - CA validity SHOULD be no longer than 5 years if the keylength is 2048 bits - CRL lifetime MUST be at least 7 days and MUST NOT be longer than 30 days - CRLs MUST be reissued at least 7 days before expiration, even if no additional revocations have occured - certificated SHOULD NOT be post-dated - the CP and CPS MUST be uniquely identified and the identifier SHOULD be in the issued user certificate. - the use of Object Identifiers (OID) is recommened, but another appropriate means of identifying the CP/CPS is allowed. The new list of minimal requirements will be put up on the WP6 web page. The Future of CA's, CP's and CPSes ---------------------------------- - The LIP CP/CPS will be rewritten soon - UKHEP will start writing a CP/CPS for the *new* CA that will operate from october 2001 onwards. It will be available at the end of July - NIKHEF will not start reformatting its CP/CPS according to RFC2527 unless there is a definite request from some CA operator - the TCD CA will take the INFN one as a starting point, expected within two weeks - CERN's CP/CPS will be ready either before june 15th or after july 15th New CP/CPSs will be checked at least against our minimal requirements set. A sub-group (Roberto, DaveK and DavidG) will verify compliance of the few upcoming CP/CPSs, but are not prepared to evaluate hunderds. Exact criteria exceeding the minimal requirements set are *not* clear. At least we will also require: - only one user per certificate, so NO shared certs. If you want account charing, the grid-mapfile should be used. We note that that sharing a key is a key compromise that should result in immediate revocation! - host certs should correspond to one single network entity. You need this anyway to establish a trust relation with the host based on reverse name mapping. It is re-asserted that there will be *no* on-site auditing! Administrative issues --------------------- - there will be a ca mailing list, which can also be used for emergency incident reporting - WP6 will be providing an integrated Globus install kit, that will include the current list of CA's. This setup corrently poses some problems: * some certs are not correct or up-to-date [being corrected] * the CNRS datagrid-fr CA has a cond_subjects list that is too broad ("/*"). This poses problems is trust relationships and is discouraged by Doug Engert *** We add to minimal requirements for a CA: *** a ca should sign a limited subject namespace that will *** not clash with other namespaces - tests are to be performed between all sited and CERN. Contact Pietro with DN and CERN-account name to get a mapping on the CERN testbed. This will implicitly excercise all CA combinations. - David will add a random sleep time to the GetCerts package script, update the package with the latest CA certs (3x CNRS) and the hierarchy and then mail the script to Sophie to be included in the WP6 stuff. Next meeting ------------ *** WATCH THE MAILING LIST for the final date and LOCATION. Unless announced otherwise on the mailing list, the next meeting will preliminary be on Tue, September 11 at CERN from 9am to 5pm. *** WATCH THE MAILING LIST for the final date and LOCATION. Documents attached ------------------ the new minimal list of requirements will be sent to you by DaveK.