Minutes of the 1st TF-LSD Meeting on September 20, 2000 at SURFnet, Utrecht Agenda 1. Opening, introduction and 5. Certification between NRNs agenda bashing [PV, PG] [PV] 2. Global Indexing Directory 6. Schema for PKI [DC] System (GIDS) 7.Other directory deployment 2.1 Status of the service issues [RH] 7.1. DC- Versus X.521-naming 2.2 Agreements on data provisioning and distribution 7.2 web2ldap Gateway [MS] [KC] 7.3. DEN [PG] 3. Integration of directories 8. Discussion of the draft and PKIs Terms of Reference for TF-LSD 3.1. Status of deployment in [PG] NRNs [5-10 Minutes each] 9. Any other businesses 10. List of open Actions * SURFnet [PV] * DFN [PG] * other NRNs 4. EuroPKI [ALi] TF-LSD Attendees Lists Janus Liebregts SURFnet [JL] Ton Verschuren SURFnet [TV] Henny Bekker SURFnet [HB] Anders Lund UNINETT [ALu] Stig Venaas UNINETT [SV] Roland Hedberg Catalogix [RH] David Chadwick Univ. of Salford [DC] Willy Janssen Univ. of Nijmegen [WJ] David Crochemore RENATER [DC] Hans de Vries TU Delft [HV] Luuk Oostenbrink SURFnet [LO] Yuri Demchenko TERENA [YD] Michael Stroeder [MS] Konstantin Chuguev DANTE [KC] Antonio Lioy Politecnico di Torino [ALi] Peter Valkenburg SURFnet [PV] Peter Gietz DFN Directory Services [PG] 1. Opening, introduction and agenda bashing The meeting was attended by 17 delegates representing 13 organisations/networks from 8 countries. During discussion of the agenda it was agreed that the agenda is very tight and in case of limited time some items, e.g. 5, 7.1, 7.3, may be skipped. Other proposed items about DIRECT project dissemination and using LDAP for metadata access were left for next meeting. Regarding some obvious interception between PKI and Directory related issues, it was agreed to limit all activities of TF-LSD only to directory related issues in PKI. 2. Global Indexing Directory System (GIDS) 2.1. Status of the service GIDS has now a pilot implementation online at http://gids.catalogix.se/gids.html. Presently the following National Research Networks are participating: DFN/Germany, SUNET/Sweden, SURFnet/Netherlands, SWITCH/Switzerland, UNINETT/Norway. GIDS is connected to participating directories and collects index information from these directories on Name, Organisation, E-mail, Locality. As a result of this it can search for people using one or all of these parameters. It returns a list of LDAP servers where the requested information/person can be found. GIDS connects to these servers (requests information) directly and receives a list of persons matching the query. Information is displayed in format received from end/authoritative LDAP server and may vary from one server to another. GIDS functionality and implementation were discussed. One of the mentioned issues was the collection of organization in person entries because not all Directories use/store the organization name in the entry except in the DN. It was proposed to use Data model with inheritance, however it was mentioned that there are not many implementations of LDAP with such an inheritance feature. Another issue in using/indexing organization name is the correct spelling of the name when some non-ASCII letters in national language are used. Common suggestion regarding existing incompatibility between information content and format was to use gateways. No solution that requires to change content in national/organizational directories will work. Another suggestion was to contribute to the development of the OpenLDAP project. Some ways to contribute to the project should be found in the frame of TERENA TF-LSD activity. Participation in/sponsoring OpenLDAP development will allow to provide European universities and TERENA community with open source tools for building a European wide LDAP service. Further development of the GIDS was discussed. It was mentioned that GIDS is not open source product. The most challenging issue in directory indexing is the privacy. Actually, to run a production service for providing information about persons we need to receive permit/written consent from the person(s). It even gets more complicated because different privacy legislation exist in different countries and thus cross-border access to directories/personal data adds more problems. European privacy legislation forbids to export personal data to countries without proper privacy legislation. The straightforward solution by filtering domain names is not complete because of the wide use of generic non country specific domains in many countries (e.g., Sweden use almost equally three domains - .se, .com and .nu). Another solution may be to use whois[??] and reverse domain resolution by IP-addresses with help of the RIPE database. Roland also mentioned that distribution of IndexObjects via GIDS should be restricted to organisations. The directory indexing itself needs to use/have access authentication chaining, this function is not available in LDAP It was decided to work out some document on GIDS deployment issues regarding privacy and make it one of TF-LSD’s deliverable. Action LSD-0-1. Work out document on privacy issues related to GIDS deployment and include it into TF-LSD deliverables (RH, PG) Action LSD-0-2. DC to find out how to contribute to development of the OpenLDAP Project to use it for the deployment of European wide LDAP/GIDS Service. 2.2. Agreements on data provisioning and distribution a) DANTE LDAP Service: LDAP cached referrals Konstantin presented two DANTE proposals. The first one was on LDAP cached referrals (http://www.dante.net/np/presentation2.html) which aims to reduce the number or referrals and speed up information retrieval. The scope of the project are International and national LDAP servers containing mostly referrals, base and one level search request only. It can be seen as both mapping of the DANTE/NameFLOW new architecture from X.500 to LDAP area and continuation of the DIRECT project, as metioned by Peter Valkenburg. The second proposal was on TIO Interchange. The service is at the very beginning/initial stage, it can collect and distribute data about LDAP servers. Demo and additional information are available at http://www.dante.net/np/presentation1.html. The project is open to all NRENs willing to participate in LDAP TIO chaining. However, currently only British TIO has been collected. The Robot/Crawler is based on Messaging Direct LDAP server and is capable of collecting LDIF files from participating Directories, Roland’s LDIF parser is used for data processing. There are three ways of submitting TIO to the project (http://www.dante.net/np/tio.html): * HTTP POST via HTML form * Via E-mail * Passive way in which DANTE LDAP crawler collects LDIF file from participating directory. It was advised to setup expiration time for TIO information. Another recommendation was to setup an interface and to exchange TIO information between DANTE and GIDS. Peter Valkenburg also expressed his expectation to hear from DANTE about a special (project) proposal how to register, collect and redistribute TIOs with privacy. Action LSD-0-3. DANTE to prepare a special (project) proposal how to register, collect and redistribute TIOs with privacy. b) round of expression of commitment to data provisioning and distribution with GIDS Currently GIDS cooperates with DFN/Germany, SUNET/Sweden, SURFnet/Netherlands, SWITCH/Switzerland, UNINETT/Norway. UK also expressed intention to cooperate. Many different (LDAP) crawlers are used which produce LDIF files. Problem may appear in converting TIO to LDIF which currently is solved by GIDS (parser). Currently different harvesting methods are used: * Netherlands universities use DESIRE/DIRECT crawler which will need further development; * Sweden and Norway don’t used crawlers; Summarising the discussion Peter Gietz proposed to draw up standard agreement on crawler policy. Current practice is based on personal access agreement. First step foreseen here may be starting TIO exchange between NameFlow members who are willing to participate. Finally, there was some discussion about creating distributed GIDS service. Sooner or later issues with distributed infrastructure will arise because of existing DB productivity limitation (which currently quite acceptable for the limited number of participating Directory Services. The following steps should be done: * Catalogix/RH needs to solve copyright problems and packaging * Next problems will cope with different TIO, access protocol, etc. used in different countries. * Particular solution for the distributed LDAP/GIDS service is seen in implementing Connectionless LDAP Action LSD-0-4. PG, TH, DANTE to draft standard agreement on crawler policy and discuss it in TF-LSD. 3. Integration of directories and PKIs 3.1. Status of deployment in NRNs a) SURFnet Peter Valkenburg presented information about PKI deployment in SURFnet/NL. SURFnet sees PKI&LDAP as a key component of network middleware. Practically, LDAP/Directory has wider use in network middleware than just certificate access/revocation. SURFnet (at different organisations and for different services) use different certificates and CAs. SURFnet CA hierarchy provides certificates for: * IMAP mail read * SMIME mail * Extension for IPSec tunnels is planned * Regarding use of Cisco Systems' Simple Certificate Enrollment Protocol (SCEP) no decision has been made yet SURFnet is interested in contributing to development of the OpenCA. Questioned about use of OpenSSL CA, Peter V. explained that its implementation needs a lot of scripting. Regarding use of PGP it was explained that PGP has very flat (one level) hierarchy for building web of trust which can cause productivity/throughput problems. Currently more that 1.5 million PGP keys have been issued and question about creating distributed PGP is open now. b) DFN Peter Gietz presented information about PKI deployment in DFN/DE. PKI webpage http://www.cert.dfn.de/dfnpca/ provides access to different CAs c) other NRNs Anders Lund of UNINETT made a remark about PKI in Norway (http://www.uninett.no/pca/index-e.html) David Crochemore of RENATER informed that RENATER doesn’t have PKI/CA yet but has intention to establish National PKI soon. 4. EuroPKI Antonio Lioy gave a presentation about the current status of EuroPKI project/service (http://www.terena.nl/task-forces/tf-lsd/docs/antonio.lioy.EuroPKI.ppt). His goal for coming here is to discuss cooperation between newly established EuroPKI targeting European community and other initiatives in Europe to built interoperable solution. EuroPKI Top Level Certification Authority (http://www.europki.org/ca/root/en_index.html) was established as follow-on or spinoff from EU funded projects ICE-TEL (http://www.darmstadt.gmd.de/ice-tel/) and ICE-CAR (http://ice-car.darmstadt.gmd.de/). EuroPKI has hierarchical structure and serves as RootCA. Currently trust is realized only inside this hierarchy, no cross-certification is available. They don’t expect appearance of more than 20 CAs in Europe in tne next 1-2 years. EuropPKI would like to have its Certificate Policy (the structure of which is according to RFC 2527): * With as low restrictions as possible to allow all participating CAs with low level policies to join (because the policy of CAs under a root can not be weaker than the policy of the root/top CA) * to be acceptable for most practical networking applications. Certificate Practice Statement (CPS) requirements: personal identification of the subject (e.g., separate IP-address), secure management of CA, periodic publication of CRL. Currently supported applications: * Web (SSL/TLS, signed applets) * SSL-based applications (telnet, FTP, SMTP, POP, IMAP) * E-mail with SMIME * IPSec (via Cisco SCEP) * Secure DNS - as a prospective service EuroPKI basic services: * Certificates publication with CRLs (Certificate Revocation List) for applications and webserver for humans. * Certificate revocation with CRL and OCSP (Online Certificate Status Protocol). * Data validation with e.g. time-stamping with TSP. Planned next steps: * Building PKI for Italian Research network GARR (currently issued approx. 1 mln. certificates) * Contributing to European Digital Signature Law * CDSA for secure middleware * Automatic policy negotiation The following discussion covered questions/problems: 1) CAs beneath the root may implement stronger policy (e.g., physical presence, checking ID, etc.) than the root. Note: Future European Digital Signature Law will define how to identify yourself 2) CPS should specify liability of the CA service in case of Certificate misuse Note: Notwithstanding that currently EuroPKI doesn’t charge money (and supposedly doesn’t have basis for formal liability), later on after moving to charged service this questions will obviously pop-up. Even in current status of EuroPKI service liability should be clearly stated. It was mentioned that it might be useful to look at the Domain Registration dispute resolution practice as implemented in Registrars business. Action LSD-0-5. Advise EuroPKI to define clearly liability of the CA service in case of Certificate misuse and make it available on webserver. 3) Mike Stroeder commented on possible ways of promoting service by including CA in popular browsers (Netscape and MS), giving his observation of mis-use and dis-orientation of non-advanced users. Summarising discussion Peter Gietz pointed on next development in this area that can be recommended by the meeting: * to clarify the issues of liability and trust * to restrict TF-LSD to the directory service for PKI. Policy discussions and other non LDAP related issues should be discussed elsewhere, may be in yet another TERENA Task Force. 5. Certification between NRNs This item was skipped due to limitation of time. 6. Schema for PKI David Chadwick gave presentation on current status and prospective of LDAP usage for storing, searching and retrieving Certificates for PKI. It is available at http://www.terena.nl/task-forces/tf-lsd/docs/david.chadwick.LDAP-PKI-IDs.ppt He explained problems of using LDAP for PKI: * Cannot search for particular certificates or CRLs * Cannot retrieve particular certificates or CRLs Current solutions are like hacks, but correct way of using LDAP for PKI needs some extensions and developments which are submitted as Internet-Drafts to IETF: * For Searching – to use the LDAPv3 Schema (draft-pkix-ldap-schema-01.txt) * For Retrieving – to use the Matched Values LDAPv3 extension (draft-ldapext-matchedval-03.txt) * Overall – to use the LDAPv3 Profile for PKI (draft-pkix-ldap-v3-03.txt) David informed that he designed few test Certificate objects which are available on the web for testing. The followingdiscussion demonstrated common interest in this development and it was decided to undertake/organize testing different clients how do they work with the test Certificates. Action LSD-0-6. DC to make proposal about testing different clients how do they work with the test Certificates. 7. Other directory deployment issues 7.1. DC- Versus X.521-naming 7.3. DEN Items 7.1 and 7.3 were skipped. 7.2. web2ldap Gateway Michael Stroeder gave a presentation about his web-to-LDAP gateway (demo version - http://www.web2ldap.de/demo.html) which is available at http://www.terena.nl/task-forces/tf-lsd/docs/michael.stroeder.web2ldap_presentation_TF-LSD.ppt. web2ldap is a simple search and download tool for certificates stored on LDAP server. It can be stand-alone or work as CGI on webserver on Windows or UNIX machine. web2ldap allows many output formats: LDIF, vCard, DSML). It tries also to handle different standards of storing certificates in LDAP directory. As a limitation of this tool, Michael mentioned that the python-ldap module used is built on OpenLDAP 1.2.x libs and thus is limited to LDAPv2 only. Another limitation is due to the statelessness of HTTP. Next developments will includeweb session management capabilities, extension to LDAPv3, a better integration of DSML and others. At the end Michael made a demonstration (searching for root DSE). As an example, David Chadwick asked to retrieve his smartcard certificate which was received correctly. It was proposed to look on possibility to develop plugin for GIDS based on web2ldap. Action LSD-0-7. MS and RH to look on possibility to develop plugin for GIDS based on web2ldap. 8. Discussion of the draft Terms of Reference for TF-LSD It had been agreed that current activity on coordination LDAP Services deployment would continue as a TERENA Task Force. This required the adoption of Terms of Reference to obtain a common understanding of the TF objectives and working methods and to agree on some deliverables and milestones. First draft of the Terms of Reference had been circulated in the tf-lsd mailing list and received some comments; more detailed discussion was at the meeting. Specific remarks were: * Recommendation to extend list of TF’s aims with item about support of and contribution to OpenLDAP development * Give more realistic timetables for some deliverables and milestones Peter Gietz will circulate revised draft for discussion on the mailing list. This discussion should lead to consensus by the end of October. Peter Gietz was elected as a chair of the Task Force. Action LSD-0-8. PG to circulate revised draft of ToR for discussion on the mailing list. This discussion should lead to consensus by the end of October. 9. Any other businesses Next meeting of TF-LSD will be some time in January-February, date and time to be discussed in the list. 10. List of open Actions: Action LSD-0-1. Work out document on privacy issues related to GIDS deployment and include it into TF-LSD deliverables (RH, PG) Action LSD-0-2. DC to find out how to contribute to development of the OpenLDAP Project to use it for the deployment of European wide LDAP/GIDS Service. Action LSD-0-3. DANTE to prepare a special (project) proposal how to register, collect and redistribute TIOs with privacy. Action LSD-0-4. PG, TH, DANTE to draft standard agreement on crawler policy and discuss it in TF-LSD. Action LSD-0-5. Advise EuroPKI to define clearly liability of the CA service in case of Certificate misuse and make it available on webserver. Action LSD-0-6. DC to make proposal about testing different clients how do they work with the test Certificates. Action LSD-0-7. MS and RH to look on possibility to develop plugin for GIDS based on web2ldap. Action LSD-0-8. PG to circulate revised draft of ToR for discussion on the mailing list. This discussion should lead to consensus by the end of October. Action LSD-0-9. TERENA to organise next meeting of TF-LSD some time in January-February 2001. Action LSD-0-10. PG, YD to include skipped items 5, 7.1, 7.3 and new proposed items on DIRECT project dissemination and using LDAP for metadata access into agenda for the next meeting.