CA coordination meeting 2001.12.06 Present: Lev Shamardin (Moscow) Pietro Martuzzi (CERN) Roberto Cecchini (INFN) Markus Schulz (CERN) Anders Waananen (BNI) Milan Sova (CESnet) Mike Helm (DoE) Tony Genovese (DoE) Jorge Gomes (LIP) David Groep (NIKHEF) Dave Kelsey (RAL) Ursula Epting (Karlsruhe) Johann Enzmann (Karlsruhe) Apologies have been received from Sophie, Andrew and Brian. Miscellaneous ------------- Status of the testbed: GDMP, where a "quasi-user" certificate for GDMP ended up on the web, and security incident handling were put on the agenda for tomorrow. Scaling problems: Requests start to arrive from places like Taiwan (possibly LHC related?) and South Africa. Details have been requested by Dave from these parties. The scaling issue is imminent. This forum can currently establish trust for TB1, but later this will get into problems. The scope of the EDG is kind of fuzzy, and there will likely not be a clear demarcation of the user community for grid. Also, the anmount of information we get from DataTAG and CrossGrid is rather nimimal. The WP6 CA coordination group is currently the ad-hoc forum for coordination, mainly for testbed-1, but it is recognized that GGF should usurp this role. New CA certs and updates: The Spanish CA updated its cert not too long ago: the hash is the same but the keypair is new. Anders points out that the ".0" extension can be used to support multiple certs from tha same CA. A similar problem will occur when a new CA comes in, which is also on the agenda. [we are joined by Ursula Epting and Johann Enzmann] Internal coordination: Our web site will be established and populated immediately following this meeting. Worldwide CA coverage: Currently, the CERN CP/CPS states "employees" as the audience for the CERN CA. As soon as the testbed opens up to the experiments, the number of requests to CERN will explode (now it is approx. three per week). Then, current practice will fail: personally contacting every requester will take too much time. Having these users get certificates from their "home" institution will not alleviate the problem: many people at CERN are "shared" (co-paid) by both their home institution and CERN, and therefore have a choice which CA to contact. Also for host certificates ambiguities exist, but there is a case for having certs issued by CERN, since a machine at CERN is in some way "controlled" by CERN administration. Several of the EDG CP/CPSs do allow signing of "foreign" FQDN's, e.g., NorduGrid can issue host certs for machines bought by institutes in the Nordic countries, even when located at CERN and inside the "cern.ch" domain. Host and service certificates: Mike points out that in most EDG CP/CPSs host certs can be obtained by any user, once that user has acquired a cert. This in contrast to, e.g., Verisign, that requires proof of a hierarchical chain that establishes a definiate relation between "you" and the one who is administatively responsible for that system. In the Grid context, this may not be that critical, since any user can run Grid services on a host (on a non-priviledged port). In this case, it is unclear what should happen when the relevant user certificate is revoked. It may not be the task of the CA to ensure that an issued certificate can actually be used on a machine: this will also require the appropriate priviledges on the machine itself. In that case, you would always issue a cert, unless the "real" owner complained, in which case the cert could be revoked. Also, the administrator of the machine will have the power to remove any offending certs. The Verisign approach requires too much manpower to check the relevant priviledges. Maybe in the (far) future, additional naming constraints (EACLs) may check alternate names and enforce further constraints. Next problem will then be "service" instead of "host" certificates: services can be run by anybody. It should be added to the minimum requirements that a user should preferably have administrative right for that machine, but this is not enforceable. Names may start colliding when you issue service certs to more then one person for the same service. OpenSSL will reject this and most of the current CP's require unique subject names, but there is not inherent technical reason. To prevent name clashes, the DoE CA effectively has a "flat" space, with a random number added to the conventional subject name. Round table reports ------------------- - NIKHEF: new CP/CPS - LIP: not may certs issued. Since last meeting an LDAP server has been established (URL should be sent to Anders). Minor fixes on CPS. Matrix filled, but still to be distributed. - CESNET: nothing new. Went through all the CP/CPSs and sent the results to Brian. Lots of work done. - NorduGrid: several certs issued, but very busy with TB1. Lots of revocation of host certs, now all service certs of the name form /. - CERN: issued several certs and revoked one. Not aware of changes. Some namespace cleanup is needed. Pietro: more and more requests coming, and the handling problem is becoming more pressing. Lev's solution of a lot of RA's and a semi-automated CA seems a very attrictive solution. There is now no manpower at CERN. The CNRS web-based software will become available, this may be a solution: it makes life for the requesters simpler, but not for the admin! Pietro is now getting requests from the US and even from South Africa. The policy now is: if someone has a CERN computer account, he can get a cert. - INFN: New version of CP/CPS. Main change is OID, and better compliance to RFC. In feature matrix the old CP/CPS has been used. - Russia: lots of changes. Key is now off-line, 6 RA's, OID requested (still waiting). HTTP repository only, LDAP coming later. Namespace change foreseen (not in EACL) and switch to production mode. - UKHEP: OpenCA has been investigated. Some problems encountered, but generally works well. Next meeting possibly a presentation. Plan to have new CA by beginning of next year (on OpenCA). Then also a new CP/CPS available. Naming will probably change then. No complaints about the CA RPM's. Anders is happy :-) EDG WP6 testbed --------------- On December 11, there will be a new set of overview talks to WP6 and to the applications. On Dec 10, the software will (should) be ready. Delays were primarily caused by Globus 2. Now, the Information System from GT2.0 is not supported by the WP1 logging system. Globus itself is reasonably stable (RPM release 21). All Globus config now centralised (EDG config version 0.13 is current). Have a look at the sites "marianne" and "datagrid". Sites who want grid-cert-request to work, should also have a "local" RPM, with a prefix config. EDG WP7 security coordination group ----------------------------------- Within the EDG project, three groups are dealing with security or related items: - this CA group for authentication and trust issues - the Authorization group lead by Roberto Cecchini - the WP7 security coordination group, the de-facto successor of the security group, for meeting the WP7 deliverables regarding security. The first deliverable in PM15 will be the reuiqrements document (gathered partly from existing documents. This work will go public soon (January). By PM23 a "security architecture" is planned. Presentation FZKarlsruhe ------------------------ FZK is currently going through a reorganization, after which FZK will have a dedicated Grid Services and Grid Research department, part of the "Virtual Computer Centre Karlsruhe". FZK is participating in Babar as a Tier-B site (32 CPU's running Linux and 2 TByte local storage). Next week it hopes to be selected as the main German LHC analysis site ("Tier-1"). The CA operated by FZK will have a namespace structured as: Namespace= /O=FZK-Grid/ou=HIK/CN= CA subject= /C=DE/O=FZK-Grid/CN=FZK-Grid-CA This CA is currently in a pilot phase, with the exact scope of the CA to be determined later, depending on the number of project where FZK will be involved in. This is potentially a large community. If the FZK is to be the German Tier-1 centre for LHC, then this CA will be the authoritative CA for Germany. ESnet PKI and directory ----------------------- The project web site is available from . It is a component of the DoE Science Grid and will be the CA serving the DoE user community (this includes those researched working on a DoE contact as well, so approximately 10k certificates). The expected outcome of the project is information on namespaces (resources and PKI), a resource meta-directory service, and support for a CA and subordinate CA's. The Globus GSI assumes that subject names are globally unique. To facilitate this, the ESnet CA will be rooted at "dc=doesciencegrid,dc=org". This will do away with the "/O=*/" naming scheme currently in widespread use. The namespace will be "flat", and is formatted as "cn=michelhelm8ac2892,ou=people,dc=doesciencegrid,dc=org" and likewise for host subject names. This will prevent conflicts with relevant standardization bodies like ANSI. Also, there is a commitment to maintain the DNS, whereas maintenance of X.500 is not guaranteed. In addition to the DoE EDnet CA, there will be other CA's in the USA, like the one from NMI (NSF Middleware Inititive) and Internet2. In those cases, these will be supported either through repositories or by cross signing (although not currently supported by Globus or OpenSSL). It is essential to establish what "identity" means, so that mutual trust can be established, also for users in EDG that want to use DoE resources. The DoE CA is based on Iplanet CMS, although licensing costs are associated with it. It's required for political reasons, so may not stay for ever. It supports distributed RA's, as seen in the picture in Mike's presentation. The CA will then issue the certs automatically. But the number of RA's should somehow be limited (upto 20?). The ESnet CA has a very aggressive schedule. Mid january everything should be up and running in pre-production. At that point changes will become even harder. Open Questions -------------- Some open questions: - list of subject names from CA's and samples of issued certificates - CA signing cert repository (secure uploads?) - Repository of public certs (directory) - came out of AuthZ group - Authorization directory (possible model for US) - Value of identity (what does it mean, what about MSPassport or rudimentary identities, cost effectiveness of authentication) ] ESnet has been driven by the VO's, so the only thing the VO ] can attest to is the liason to the VO, not a link back to the ] official affiliation. - OCSP Identity in the current pilot projects has traditionally not had a significant meaning. Every resource provider eventually does the checking again. The local resource owner should retain control and thus has to take full responsibility. But then, he does not want the burdon that goes with it. The current naming of host or service certificates is a `Kerberosism'. The "/naming" does not fit the original PKIX model; it is reminescent of the "/Email=addr" part of the subject name, that is currently a disallowed practice by the PKIX group. Steve Kent said the naming should correspond to something that could be found in a directory. So, transferring this to the service, this should have been a next component in the subject name. As far as product are concerned, most of the EDG CA's are using OpenSSL with some scripts, or OpenCA. ESnet uses Iplanet, but the company may go bankrupt (and every cert issued costs $6!). Nobody is using Microsoft CA at this moment, but it is free. The software should not matter, since the format is standardized: for certificates X.509v3, for CRL's version 1. In TB1, CRL's are pulled from the public repositories periodically. There might be incompatiblities using either full or differential CRL's. [NEXT DAY] GGF Policy working group ------------------------ An overview of the GGF CP draft is given by Tony. GGF started with CP, since many organization were starting, all with slightly different CP's. The idea was to define a standard CP, with every organization adding his own CPS as an appendix to this. Some key items: - the four levels were taken from the US Federal Bridge CA CP. - "Responsibles": * Certificate levels: Randy Butler, * PKI Arch: Tony and Mike, * Cert profile by Von Welch and Mary Thompson, * PMA issues by Peter Gietz, * auditing by Bob Cowles. - Final release is now hopefully in Feb 2002, still need input on almost all areas, get WG consensus, try it out a bit and then get GGF consensus. - New points: AUPs (Ian Foster trying to push it in the GridCP group, but a BOF in Toronto should be scheduled). - Open areas: * WG wants support for multiple levels (proposal: 4 levels , modelled after Fed Bridge). * the proposed trust models may require a GGF CA. * open accessible GGF repository seems to be the most popular model in the WG today. It need to be run by a contractual (third) party. * naming: tendency to flat namespace (the idea of structured names, that was sponsored by MaryT, seems to be on its return, nowadays). Akenti may have some use for structured names; it is probably useful for an authorization scheme. * PMA (arbitration etc.): should this be a volunteer effort? I.e. like a voluntary fire brigade, headed by the director for the security area in GGF. If needed, the SA director can call together a new working group, which will be the PMA. * Auditing: leaning towards peer review. Still looking whether commercial options would be viable. Like the American Bar Association who interpreted RFC 2527 in a 300 page document (ref will be on the GridCP website). Discussion on GridCP Draft -------------------------- The GridCPv5 has some internal inconsistencies with regard to private key generation by the CA (texts from EuroPKI and FedBridge CA got mixed). Preferably, keypair generation is not with the CA, but some legislation may require smartcards or key escrow for legal validity. This is hard to circumvent. Defining levels still is a challenge. A discussion evolved around two distinct levels: RUDIMENTARY For data integrity only (no identity checks) especially suitable for host/service certs for data integrity, since the private key is not protected anyway BASIC some (light-weight) reasonable identity check ties a "string" to an individual institute in the name is a problem, since affiliation is not always clear, and making a real assertion is not properly possible (who can actually speak for a Lab?) Making distinctions in the name, e.g., specifying which RA's mediated the request, seems not useful, since if you no dot trust one RA, than you should not trust the CA in the first place. So either trust none or all. But having the institute in the name actually makes it more clear to recognise people. But then you will have to revoke certs when people move. A flat name space seems to be "winning" in the WG discussions; the checking burden is then on the resource owners: they should check the ID. It is similar to a GridPassport, with a name, a key and an ID number only. The basic difference between Basic and Rudimentary will be that a Basic check will leave a log entry, and the RA should be able to re-identify their subjects any time. Roberto: Resource owner should preferably have to deal with only one authentication document, so that the user does not have to come along with three documents. But then, some VO organization like an experiment will probably do that anyway. Now for a three-level model: Is a three level arch needed to add an institute name to the descriptive string? Similar to: 1. No check, random string 2. Check name, person is who they say they are 3. (2) and organization affiliation has been verified With regard to verification, levels 2 and 3 are similar. So, if the name has an organization in it, then $EXTRA_CHECKS also apply. Having the name in the cert only for authorization reasons is beaten to death on the GridCP maling list. There is no technical reason to have the institute in the name for the EDG tools. There are also no real reasons to have it there, except for readability purposes. You could also use it to limit the set of certs issued by the CA using the CA signing policy files, to get around the design flaw in Globus that the issuer name is not in the grid-mapfile, and the fact that restricted cross signing was never properly started in OpenSSL. The current practice for authoritzation is that the VO manager will add people, possibly based on the certificate information, add it the the directory. Sites then generate their mapfile and check that they signed to AUP (i.e. the sites will do this last check). So, an institute name may be used by the VO manager to do this verification, but it should not be required. An example for a VO definition and RA functionality can be found on . Currently it is not envisaged that the name of the sponsoring RA will be in the cert. The UKGridPP CA, on the contratry, is considering this, to make a certificate better understandable. But it's dangerous, for a site admin, to trust on the naming in the certificate to make authorization decisions (like implementing resitriction to organizations or VO's in the ca-signing-policy file), especially in highly-revolving environments (like those for students). The appendix to the CP/CPS will define the RA functionality and the way the RA operates. If the sponsoring RA is not "visible" in the cert, than there can essentially only be one type of RA appendix, otherwise the relying party cannot distinghuish different policies and practices. (in the example on the web page, one should therefore replace "PPDG VO" with "VO". The document is currently in draft.) The CA directory may have subtrees per RA, and these subbranches can then managed by the RA's (i.e. something like a back-reference to the VO directory). A per-CA prefix needs to be there (not just "/CN=...", if only to be able to put them in a directory without having just only one huge one. Also, this decision should be a local CA issue, it cannot be decided centrally, and there is no need for a central choice. You can't, anyway, since many CA's serve a community larger that Grid. Authentication in DoE CA using the PPDG RA ------------------------------------------ - section A.4.3, is it sufficient? Some confusion exists about the terms PPDG RA staff, PPDG POC. It is: POC: a site contact or principle investigator. PPDG RA: one per VO and his delegates. (in point 8: POC should probably read "PPDG RA") proof of possession of the private key is not clear; the subscriber should go to the RA in person. During that conversion, the subscriber should tell the decrypted content of the challenge send beforehand to him to prove his possession. There should be a personal, trusted conversation in which the integrity of the request is asserted. But then, use of many intermediate steps (CA -> RA -> site contact -> subscriber) lessens this trust. All EDG CAs require either face-to-face or known voice recognition for certification. That is probably stronger than most current US authorizations (for getting an account at a site), where the assumption is that a man in the middle cannot simultaneously intercept all means of communication used in the process (e.g. both e-mail, surface mail and phone conversions with a third authorizing party). Some kind of conversation (phone or personal) where the originality of the request is in some way tested (key fingerprint?) is sufficient. We should minimize the risk for a man-in-the-middle attack, but it need not be absolutely zero. Much software does not show the fingerprint of the request easily. Minimum requirements: now also require to check the integrity of the request during the communications with the requestor. -> the drafts seems acceptable, a revision will come, but for the time being it's OK. Key privacy ----------- We have become aware of some workpackages that are publishing private keys, in violation with the CP from the issuing CA's. Our response will be to immediately revoke this certificate! This message, as well as the relevant sections of the AUP and the respective CP/CPS's and Minimum Requirements will be brought to the full attention of all partners in the meeting next Tuesday. A incident mailing list, to which all relying parties are subscribed should be used to promptly distribute such information to the relying sites. Matrix ------ How does a CA get out of the blacklist, i.e. after a new CP has been issued? There is no method for this yet, so maybe a timestamp should be associated with the evaluation. Some functionality like Bugzilla would be useful, so when the admin changes the CP, the evaluator will get a mail etc.etc. Bugzilla on the other hand is overkill, since CP's will be fairly static later on. It's still a lot of work, so it may be hard to have everyone check everyone else before the Paris workshop, but it still seems worthwhile. One solution would be to have three reviewers per CP, but then the local site admins will be more likely to trust a local, national authority then some random other CA from our group. Milan (CESnet) checked all CP's, but mainly the lack of a method to prove possession of private key and absence of a CP alltogether cuases a lot of "0" to show up. Feature Matrix -------------- Readibility whould be better if we reverse the columns. Some problem still is that people seem to need deadlines to actually get something done. I.e. the UK CP must be there soon! Everything MUST be done before the Paris workshop and all CA's MUST have a CP before February 1st. In the feature matrix, a "normative" column may be used to compare your CA against as a kind of self evaluation, and per item assign a "severity" that directly goes into the acceptance evaluation. We will try to draw up a set, geared towards the DoE community, that will be discussed on the list. Brian will be involved in this. Draw up recommended values and assign severity when recommended and actual do not match. Tony is willing to act as a backup. The deadline for this is January 15th. We try it now! Colum or item should be severity if not Inspecting_CA reference - name= present - alias= country= country_ID= CP_and_CPS: RFC2527_compliant= true minor OID_identifier= must be there unresolved(*) OID_in_cert= must be there unresolved CA_web_server: URL= must be there severe publishes_CA_cert= must be there unresolved publishes_user_certs= must be there severe publishes_CRL= true severe publishes_CP= true severe cert_publication_freq= ?? CRL_publication_freq= specified restricted_access= must be public major? CA_LDAP_server: must be there major URL= publishes_CA_cert= publishes_user_certs= yes major publishes_CRL= publishes_CP= URL to web??? seems useless cert_publication_freq= CRL_publication_freq= restricted_access= RA: email= recommend that there is an RA, - secure_comms_to_CA= must be true severe separate_from_CA= no recommended cert_issuance: identity_check= must be true severe CA_obtains_proof_of_key_posses.. phone, voice, personal, ... subject_keys_generated_by_CA= must be false unresolved confidential_user_info: no recommendation CA_retains= local legislation CRLs: lifetime= 30 days max. lifetime_after_revocation= revocation_checkable_online= status_checkable_online= compliance_auditing: frequency= ? auditor= ? cert_signing_host: controlled_physical_access= must be true severe offline= must be true unresolved CA_private_keys: generation= informational ?? storage= removable or write protected backed_up= activation= certs: CA_key_size= must be>=1024 unresolved CA_key_lifetime= keylength and lifetime correlated ... minimum_subject_key_size= maximum_subject_key_lifetime= Rest is to be discussed on the mailing list. The Feature and Acceptance matrix should be filled in at the latest by Paris, but a first shot for the Feature Matrix SHOULD be in by January 15th. The Acceptance Matrix MUST be filled in by mid February, before GGF4, to be in time for Paris (6-8 March). Authorization roles using proxies --------------------------------- Anders tried a new scheme, where a role is put in your proxy "..../CN=Pietje Puk/D=atlas-mcprod/CN=proxy", and you can add this rolename in your gridmapfile. Initial tests tonight seem to indicate this works nicely. To be continued in TestBed 1 Next meeting ------------ will be in Paris, on monday 4 and tuesday 5th during the parallel sessions of the EDG Conference. The same week there will be the Terena PKIcoord and LDAP working group meeting, so we will be try to avoid overlap.