Minutes of the 1st TF-LSD Meeting on September 20, 2000 at SURFnet, Utrecht

Agenda
 
1. Opening, introduction and agenda bashing [PV, PG]
2. Global Indexing Directory System (GIDS) 
2.1 Status of the service [RH]
2.2 Agreements on data provisioning and distribution [KC]
3. Integration of directories and PKIs
3.1. Status of deployment in NRNs [5-10 Minutes each] 4. EuroPKI [ALi] 
5. Certification between NRNs [PV]
6. Schema for PKI [DC]
7.Other directory deployment issues
7.1. DC- Versus X.521-naming
7.2 web2ldap Gateway [MS]
7.3. DEN [PG]
8. Discussion of the draft Terms of Reference for TF-LSD [PG]
9. Any other businesses
10. List of open Actions

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]
Karel Vietsch TERENA [KV]
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):

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:

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:

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:

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):

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:

EuroPKI basic services: Planned next steps: 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:


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:

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: 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 /tech/task-forces/tf-lsd/docs/michael.stroeder.web2ldap_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:

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.