Minutes of the 2nd EUGridPMA Meeting Brussels, September 23+24 2004 September 24th, 1500 hrs by: Jens Jensen ------------------------ *** Switch CA discussed: who generates the key (cf soapbox). If CA generates the key, the CA MUST describe how it is managed in the CP/CPS. Either keys are escrowed or the CA must describe how it gets rid of it. Verisign does this. Also, latest versions of OpenCA can generate keys on the server side. Switch lets user download the PKCS#12. Switch does not allow users to generate proxies. Are there more liabilities for the CA when users use certs to generate proxies? Perhaps it helps that proxies are now blessed by IETF. Will need to revisit Switch at next meeting. Windows 2000 Active Directory also generates certificates for users. *** Reasons for CA generating keys: smartcards, browser support, password hygiene, control over certificates and usage. Such a CA can regenerate certificates from CSRs. Come up with minimal requirements corresponding to this use case. Mike, Tony, Jens, Rolf volunteer. Dane volunteers to be a critical observer. [note: I had written Milan but my memory says Dane.] Independently, find out what are best current practices. Known example: FNAL's CP/CPS. What are the commonalities. Avoid technological details. Do we distinguish between CAs generating long-lived and short-lived keys? Different classes: SIPS and other proxy generators, Active credential stores, key generating CAs. *** Date and place of next meeting: 1.5 days too short. Marseille is warmer than Tallinn in January. Wed~26~Jan--Fri~28~Jan, starting 1400. 2.5 days (lots of coffee needed). Expect 3 meetings/year. So next^2 meeting will be tentatively end of May, 26--27 2005, in Tallinn. *** Naming issues. Anders reported problems when generating RPMs: Some CAs didn't have signing-policy files. Some CAs didn't specify in CP/CPS which namespace they sign. For example, catch-all can sign *any* namespace, so if catch-all is compromised, every resource that trusts catch-all is vulnerable. Anders suggests to take out catch-all from the next release. CNRS will set up a new CA with a restricted namespace, will still act as catch-all for EGEE, etc. It needs to be approved by CNRS (and by the PMA). For DoEGrids CA, catch-all is just another RA. DoEGrids uses DCs to prevent namespace overlap. Timescale for replacing the /* catch-all: 1 year from now... Questions: - How many certificates are currently caught-all. - Can RPs help find the certs and identity which can now be replaced by national CA certs. - Can we generate a post-hoc signing-policy file for the /* catch-all. For China, question how many new institutes will be joining? Need to document remote registration procedure. Problem is that these things don't have a common root at the moment (/C=CN and /C=TW - exercise for the reader). /C=CN/O= is considered ok. ASGCCA suggests also signing for nearby countries. Globally, the three PMAs should also coordinate so that _their_ namespaces don't overlap. Let's see if APGridPMA can sort out the details. *** Question about mirroring. Tony suggests mirroring the EU Grid PMA web site. Anders suggests signing rpms with a pgp key; then projects can distribute them, and the PMA would not be a single point of failure for fetching certs. *** What is the relation between projects and PMAs, and to VDT in particular. VDT funded by iVDGL which is NSF-funded and may represent lots of RPs; should they be represented in PMAs? *** Mike mentions a RADIUS infrastructure to support OTP. Leads to problems with collaborative environments like Grids, so a SIPS type solution required. Go to website and have a look at slides. Eduroam is similar Terena-sponsored project. [web site is http://www.doegrids.org/CA/; scroll down to papers & presentations] [Eduroam: http://www.eduroam.nl/en/index.shtml] *** What is the relation between projects and PMAs, and to VDT in particular. VDT funded by iVDGL which is NSF-funded and may represent lots of RPs; should they be represented in PMAs? *** Another Terena effort, sponsored by SurfNet, to set up a European server (and service) CA. There will be a presentation at the next meeting. [http://www.surfnet.nl/en/]