Peter Gietz DAASI International GmbH
1 Einleitung
Seit 1994 wurden vom BMBF finanzierte DFN-Forschungsprojekte zu Verzeichnisdiens- ten an der Universität Tübingen durchgeführt. In den ersten dieser Projekte stand der Aufbau und Betrieb eines Emailverzeichnisses für die deutsche Forschung1 im Vorder- grund. Zum Aufrechterhalt dieser Dienste kamen in den Folgeprojekten weitere Aufgaben hinzu, wie z.B. der Aufbau des Verzeichnisdienst-Kompetenzzentrums „DFN Directory Services“2. Neben dem ITU/ISO-Standard X.500 bekamen Implementierungen des Light- weight Directory Access Protocol (LDAP), welches mittlerweile in der Version 3 vorliegt [RFC3377], eine immer größere Bedeutung. Ein wichtiges Thema, welches in den letz- ten beiden Projektphasen angegangen wurde, war es, vorhandene LDAP-Speichermodelle für die Veröffentlichung von Zertifikaten, wie sie für die auf asymmetrische Verschlüs- selungsverfahren basierende sogenannten Public Key Infrastructure (PKI) auftreten, zu evaluieren, sowie bei Bedarf ein neues optimiertes Modell zu erstellen. Die DAASI Inter- national GmbH wurde als Spin-Off der Universität Tübingen gegründet um als Nochfol- geinstitution der DFN-Projekte zu fungieren. Das letzte zweijährige Projekt3 wurde von der DAASI International durchgeführt und in [DAASI] dokumentiert. In diesem Aufsatz werden die PKI-bezogenen Ergebnisse dieses letzten Projekts vorgestellt.
2 LDAP und PKI
Das zuerst 1977 in [Rivest] vorgestellte asymmetrische Verschlüsselungsverfahren (nach den Authoren RSA genannt) baut auf einem Schlüsselpaar auf, bestehend aus einem öf- fentlichen und einem privaten Schlüssel. Dadurch, dass die beiden Schlüssel in einem ma- thematischen Zusammenhang stehen, der private Schlüssel aber ab einer gewissen Schlüs- sellänge nicht mittels des öffentlichen Schlüssel erschlossen werden kann, können mit dem privaten Schlüssel erstellte sogenannte digitale Signaturen mit dem öffentlichen Schlüssel verifiziert werden. Gleichzeitig kann man mit dem öffentlichen Schlüssel einen Text so verschlüsseln, dass er nur mit dem privaten Schlüssel entschlüsselt werden kann. Ein Zer- tifikat wird von einer Certification Authority (CA) genannten vertrauenswürdigen Instanz (einer sog. Third Trusted Party), erstellt. Hierbei bestätigt die CA die zu einem öffentli- chen Schlüssel gehörigen Identität mittels einer digitalen Signatur, nachdem die Identität z.B. über einen Personalausweis verifiziert wurde.
1AMBIX-D (Aufnahme von Mail-Benutzern in das X.500 Directory), siehehttp://ambix2002.directory.
dfn.de/.
2Vgl.http://www.directory.dfn.de/, wo auch die Projektergebnisse veröffentlicht wurden.
3„Ausbau und Weiterbetrieb eines Directory Kompetenzzentrums“ 1.2.2001-31.1.2003.
Eine entscheidende Voraussetzung für die effiziente Anwendbarkeit einer auf das RSA- Verfahren beruhende PKI ist die Verfügbarkeit der öffentlichen Schlüssel der teilnehmen- den Benutzer. Speziell bei der Email-Kommunikation sind die Benutzer darauf angewie- sen – sei es, um dem Kommunikationspartner eine verschlüsselte Nachricht zu schicken, oder um eine signierte Email zu verifizieren. Obwohl bereits Alternativtechnologien wie XML [Ford] oder HTTP [Gutmann] vorgeschlagen wurden, gilt LDAP im Augenblick als die geeigneteste Technologie zur Veröffentlichung von Zertifikaten und ist als einzige der Alternativen bereits im produktiven Einsatz. Vorteile von LDAP sind hierbei das offene objektorientierte Datenmodell, das integrierte TCP/IP-basierte Netzwerkprotokoll, Ver- schlüsselbarkeit der Client-Server-Kommunikation, sichere Authentifizierungsmechanis- men, die Verteilbarkeit der Daten auf verschiedene Server, sowie stabile Zugriffskontroll- und Replikationsmechanismen. Eine kurze allgemeine Einführung in LDAP bietet z.B.
[Gietz 2002a].
Nahezu alle Email-Programme unterstützen mittlerweile LDAP als Zugriffsprotokoll auf zentral verwaltete Adressbücher. Ein Teil der Programme bietet in diesem Zusammenhang auch die Möglichkeit, X.509 Zertifikate abzufragen, wobei der veraltete LDAPv2 Standard [RFC2559] verwendet wird. Eine Schema-Spezifikation für LDAPv3 ist auf dem Wege [Chadwick 2002a], welche aber das Problem multipler Zertifikate einer Person, wie hier zu zeigen sein wird, nur ungenügend löst. Der im Projekt erarbeitete Gegenvorschlag ermöglicht ohne großen Implementierungsaufwand ein zentrales Verzeichnis für Public- Key-Zertifikate, wobei auch multiple Zertifikate eines Teilnehmers ressourcenschonend unterstützt werden. Hierzu wurde ein LDAP Schema [Gietz 2003] definiert, in dem jedes Zertifikat als eigenständiger Eintrag im Verzeichnis gespeichert wird. Neben dem binären Zertifikat selber werden die wichtigsten Information über ein Zertifikat als normale LDAP- Attribute bereitgestellt, um so den Applikationen die Möglichkeit zu geben, bestimmte Zertifikate durch einfache LDAP-Filter auswählen zu können.
3 Zertifikate im Verzeichnis, die bisherigen Lösungen
Bei einem Zertifikat handelt es sich um eine geschachtelte Datenstruktur, die Informatio- nen zu Halter und Aussteller des Zertifikats enthält und durch einen verschlüsselten Hash dieser Informationen gesichert wird. Zertifikate werden bisher nur als BLOBs (Binary Large Object) im Verzeichnis abgelegt.
In [Chadwick 2002a] wird ein solches LDAP(v3) Schema zur Speicherung von X.509 Zertifikaten spezifiziert. In beliebigen LDAP-Einträgen (sinnvollerweise Personeneinträ- ge mit Informationen zu Name und E-Mail-Adresse) wird mittels der Hilfsobjektklasse pkiUser das Attribut userCertificate hinzugefügt, mittels dessen man ein oder mehrere Zertifikate in Binärform ablegen kann. So kann ein Client z.B. nach der E-Mail-Adresse suchen, und dann die in dem gefundenen Eintrag gespeicherten Zertifikate downloaden.
Ein Problem besteht nun aber darin, bei mehreren Zertifikaten das richtige zu finden, also z.B. dasjenige, welches im FeldkeyUsageden WertdigitalSignaturehat. Der Client muss die binäre Struktur jedes der gelieferten Zertifikate analysieren, um das vom Benutzer gesuchte Zertifikat zu finden. Dies kann bei vielen Zertifikaten einer Person zu erheb- lichen Performance-Problemen führen. Zwar bieten die Autoren eine Lösung für dieses
Problem an [Chadwick 2002b], sie ist aber sehr schwierig zu implementieren und wird, wenn überhaupt, erst in Jahren zur Verfügung stehen. Als Lösung wird dort ein LDAP Control4 vorgeschlagen, das es dem Server erlaubt, nur bestimmte Werte eines Attribu- tes zurückzuliefern. In Verbindung mit speziellen Vergleichsoperatoren (sogenannte Mat- ching-Rules) für Zertifikate, die in generischer Form in [Legg] spezifiziert sind und in [Chadwick 2002a] Anwendung finden, ist es möglich, ein bestimmtes Zertifikat aus der Reihe der in einem Eintrag gespeicherten Zertifikate auszuwählen. Der Hauptvorteil dieses Ansatzes ist, dass keine Änderungen in der hierarchischen Baumstruktur (DIT, Directory Information Tree) des Verzeichnisses notwendig werden. Jedoch müssen alle beteiligten Anwendungen, also Clients und Server, erheblich modifiziert werden, um einen Nutzen aus diesem Ansatz ziehen zu können. Beide Seiten müssen die ASN.1-Struktur, durch die das Zertifikat-Format definiert ist, verstehen, und der Server muss in seinem internen In- dex die einzelnen Felder dieser Struktur indizieren. Erste Implementierungserfahrungen in einem TERENA Projekt5 haben gezeigt, wie schwierig eine solche Implementierung ist. Diese Erfahrungen haben in jenem Projekt dazu geführt, auf die hier vorgeschlagene Lösung zurückzugreifen6. Das dadurch bedingte völlig neue Design der Software ist in [Sahalayev] dokumentiert.
4 Vorschlag einer einfacheren Lösung
Als einfache, leicht implementierbare Alternative7hierzu wird in [Gietz 2003] vorgeschla- gen, alle Zertifikate aus einem Eintrag zu entfernen und stattdessen als eigenständige Ein- träge unterhalb des ursprünglichen Eintrags anzulegen. Mit einem spezifizierten LDAP- Schema werden die wichtigsten in [RFC3280] beschriebenen Zertifikatsfelder als LDAP- Attribute definiert, deren Inhalte für jeden Client leicht suchbar vorgehalten werden kön- nen. Mit solchen Attributen angereichert – man kann hier auch von Metadaten sprechen (Daten über das Zertifikat) – werden die Zertifikate gespeichert. Für eine Übergangszeit ist es auch möglich, die Zertifikate noch zusätzlich im ursprünglichen Eintrag zu belassen, so dass die Migration zu dem hier vorgeschlagenen LDAP Schema erleichtert wird. Jedoch muss in diesem Fall besonders auf die Integrität der redundant vorhandenen Informationen geachtet werden. Inkonsistenzen zwischen der binären Darstellung des Zertifikats und den daraus extrahierten eigenständigen Attributen sind jedoch nicht zu befürchten, wenn die Metadaten automatisch aus dem Zertifikat extrahiert werden. Eine Software, welche diese Extraktion durchführt und die entsprechenden LDAP-Einträge erzeugt, wurde im eingangs erwähnten DFN-Projekt erstellt.
Die Lösung, jedes Zertifikat in einem eigenen LDAP-Eintrag vorzuhalten, bietet große Fle- xibilität in Bezug auf die Strukturierung des LDAP-Datenbaums (DIT). Man kann die Zer-
4LDAP Controll ist eine der Erweiterungsmechanismen für LDAP, womit eine neue LDAP-Opera- tion (Request und Response) im Protokoll definiert werden kann.
5„Adding Certificate Retrieval to OpenLDAP“, vgl.http://www.terena.nl/tech/task-forces/tf-lsd/projects/
OpenLDAP4PKIproposal.rtf
6Vgl. das Protokoll über ein Project Review Meeting unterhttp://www.terena.nl/tech/projects/OpenLDAP/
Doc/Review26-11-02.pdf
7Die ursprüngliche Idee zu diesem Vorschlag entstammt [Greenblatt], ein längst verfallener Inter- net Draft, der allerdings wesentlich weniger Attribute vorschlägt.
tifikate sowohl unterhalb eines Personeneintrags vorhalten, wie er in einem Personenver- zeichnis (White Pages Dienst) vorkommt, als auch in einem reinen Zertifikatsverzeichnis ablegen. Für beide Alternativen wurden Namensregeln spezifiziert, wobei beim Zertifikats- verzeichnis, in dem nur die von einer CA ausgestellten Zertifikate vorgehalten werden, die Serien-Nummer des Zertifikats als eindeutiger Name (Relativ Distinguished Name, RDN) ausreicht. Bei der Speicherung in einem Personenverzeichnis, welches potentiell Zertifi- kate verschiedener CAs enthält, wird der RDN mittels CA-Name (IssuerDN) und Serien- nummer gebildet. Da die Verzeichnisdienstimplementierung von Microsoft den LDAPv3- Standard nicht vollständig unterstützt und solche aus mehren Attributen zusammengesetz- ten RDNs (multi valued RDNs) nicht zulässt, wurde zusätzlich eine Namensregel definiert, bei der diese beiden Informationen in einem issuerSerial genannten Attribut gespeichert werden können.
Schließlich wurden bestimmte Attribute definiert, um von einem in einem reinen Zerti- fikatsverzeichnis gespeichertem Zertifikat auf einen Personeneintrag in einem getrennten Personenverzeichnis verweisen zu können. Auch der umgekehrte Verweis vom Personen- verzeichnis auf das Zertifikatsverzeichnis wurde spezifiziert.
Aus dieser Art der Speicherung ergeben sich verschiedene Vorteile. Die Implementierung der oben erwähnten zusätzlichen Matching Rules in Clients und Server ist nicht notwen- dig. Vielmehr kann jedes Attribut eines Zertifikats-Eintrags in einfachen LDAP-Filtern benutzt werden. Auch Informationen, die nicht im ursprünglichen Zertifikat vorhanden sind, etwa der Wiederrufsstatus, können prinzipiell in einem Suchfilter benutzt werden.
Schließlich eignet sich dieser Metadaten-Ansatz dazu, in ein verteiltes und hochskalier- bares indexbasiertes Zertifikats-Informationssystem integriert zu werden, wie es etwa mit dem Common Indexing Protocol (CIP) [RFC2651] realisiert werden kann (Vgl. Abb. 1).
Es geht hierbei darum, Informationen, die auf beliebig vielen Daten-Servern vorgehalten werden, über ein zentrales Informationssystem zur Verfügung zu stellen. In diesem zen- tralen Index müssen nur die Metadaten-Attribute in Form von sogenannten Tagged Index Objects (TIO) gesammelt und vorgehalten werden. Ein LDAP-Client kann dann einem an diesen Indexobjekt-Server angeschlossenen LDAP-Server seine Anfrage stellen und wird von diesem mit einem Verweis (einem sogenannten LDAP-referral)bedient, wodurch der Client in die Lage versetzt wird, seine Anfrage nochmals, jetzt an den Server zu stellen, welcher die Antwort vorhält.
Neben dem Metadatenmodell für Identitätszertifikate wurde auf der gleichen Grundi- dee basierende Datenmodelle auch für sogenannte Certificate Revocation Lists (CRLs), in denen Information zum Wiederruf von Zertifikaten vorgehalten werden, definiert [Chadwick 2003a], sowie für Attributzertifikate [Chadwick 2003b], mit denen man einem durch das Identitätszertifikat authentifizierbaren Benutzer zusätzliche Eigenschaften, wie z.B. Authorisierungsinformation zuordnen kann.
Aufbauend auf einen LDAP-Zertifikatsserver, der sowohl Identitätszertifikate, als auch CRLs abbildet, können zusätzliche Dienste aufgebaut werden, wie z.B. ein Dienst zur Abfrage der Gültigkeit eines Zertifikats auf Basis des Online Certificate Status Protocol (OCSP) [RFC2560].
Abbildung 1:Architektur eines CIP basierten Index Systems
5 PKI/LDAP Projekt in Baden Württemberg
Im Rahmen eines Baden-Württembergischen Landesprojekts8werden die hier vorgestell- ten Technologien in einer landesweiten PKI realisiert. Projektpartner sind die Universi- täten Freiburg, Heidelberg, Hohenheim, Karlsruhe, Konstanz, Mannheim, Stuttgart, Ulm und Tübingen, sowie DAASI International GmbH. Zum Arbeitsprogramm gehören u.a.:
• Evaluierung bestehender CAs und Verzeichnisdienste an Hochschulen in Baden- Württemberg
• Aufbau zentraler Serverdienste
• Unterstützung und Koordinierung der dezentralen Verzeichnisdienste
• Realisierung von auf PKI beruhenden Mehrwertdiensten (S/MIME, SSL, Web-Autho- risierung, User-Interfaces)
Folgende zentrale Dienste werden aufgebaut:
• Zentrales Zertifikatsverzeichnis für an die Projektinfrastruktur angeschlossene CAs, die keinen eigenen Verzeichnisdienst betreiben
• Index-Server, der Informationen der von an die Projektinfrastruktur angeschlossenen Verzeichnisdiensten
• Referenzserver auf Open-Source-Basis für teilnehmende CAs
Die in Abb. 2 dargestellte Architektur zeigt, dass sich Zertifikatsverzeichnisse, die auf ver- schiedene Verzeichnisdienstimplementierungen, wie OpenLDAP, Novell eDirectory oder Microsoft Active Directory (AD) aufbauen, integrieren lassen. Voraussetzung ist lediglich die Unterstützung des LDAPv3-Protokolls.
8Projekt: „Landesweite PKI auf Basis von indizierten Verzeichnisdiensten mit standardisierten LDAP Zugriffsmechanismen“, Beginn: August 2003.
Abbildung 2:Architektur des PKI-LDAP-Projekts
Der zentrale Indexserver indiziert sowohl die Zertifikate, die in lokalen Zertifikatsverzeich- nissen gespeichert sind, als auch die des zentralen Zertifikatsverzeichnisses, welches für diejenigen CAs betrieben wird, welche nicht selber einen solchen Verzeichnisdienst be- treiben wollen. Die von solchen CAs (in der Abbildung CA 4) ausgestellten Zertifikate werden über einen gesicherten Weg an den zentralen Dienst übertragen. Alle anderen Zertifikate werden von einem Crawler aus den lokalen Verzeichnissen gesammelt. Die zentralen Dienste stellen Schnittstellen über HTTP, OCSP sowie LDAP zur Verfügung.
6 Ausblick: DFN-weite PKI?
Spätestens nach einem erfolgreichen Abschluss des Landesprojekts, wenn sich also der hier vorgestellte Ansatz im Produktiveinsatz bewährt hat, wird sich die Frage stellen, ob nicht auch in einem größeren Rahmen eine auf dieser Technologie beruhende PKI im- plementiert werden sollte. Die Bedeutung organisationsübergreifender Authentifizierungs- und darauf aufbauende Authorisierungsverfahren, die es z.B. einem Studenten der Hoch- schule A ermöglichen, auf Ressourcen der Hochschule B zuzugreifen, wird im deutschen Forschungsumfeld zunehmend erkannt. Eine DFN-weite PKI könnte als Voraussetzung für solche Verfahren dienen.
Für organisationsübergreifende Authorisierung lassen sich Regeln (Policy) aufstellen, die jedem, der ein Zertifikat einer beliebigen Hochschule eines unter einer solchen Policy ste-
henden Verbundes besitzt, an einer anderen Hochschule dieses Verbunds das Recht gibt, dort Ressourcen zu nutzen. Wesentlich detaillierter könnten Berechtigungen spezifiziert werden, wenn eine PKI als Grundlage einer auf [RFC3281] beruhenden Attributzertifi- kats-Infrastruktur (Priviledge Management Infrastructure, PMI) mit Spezial-Authorisie- rungen genutzt würde. Schließlich kann eine PKI als Grundlage für Proxy-Zertifikate [Tuecke] dienen, wie sie zur Authorisierung im Grid-Computing verwendet werden. Je- denfalls könnten sich bundesweit Synergie-Effekte ergeben und ein großer Schritt hin zum gesamtdeutschen Forschungsraum geleistet werden. In Zeiten, in denen bereits von einem europäischen Forschungsraum gesprochen wird, ist es unumgänglich, solche Schritte an- zugehen.
Durch die langjährigen Aktivitäten der DFN-PCA (heute innerhalb der DFN-Cert GmbH)9 sind bereits etliche Voraussetzungen für eine bundesweite Forschungs-PKI geschaffen worden. Besonders hervorzuheben sind hier die von allen Hochschul-CAs beachtete Cer- tification Policy, die gemeinsame Zertifizierungsinfrastruktur, die dadurch hergestellt wur- de, dass die CA-Schlüssel von der Policy CA (DFN-PCA) zertifiziert wurden, sowie der von der DFN-PCA geleistete CA-Support. Der einzig fehlende Bestandteil ist ein koordi- nierter Verzeichnisdienst. Hier können die Ergebnisse der DFN-Verzeichnisdienstprojekte, insbesondere das hier vorgestellte Datenschema und die darauf beruhende Testimplemen- tierung, sowie die zukünftigen Erfahrungen aus dem PKI/LDAP-Projekt einfließen.
Der mittlerweile aus drei Internet-Drafts [Chadwick 2003a] und b, [Gietz 2003] bestehen- de Vorschlag wurde intensiv in der IETF Arbeitsgruppe pkix diskutiert. Obwohl man in der IETF sehr bemüht ist, für eine Anwendung jeweils nur einen Vorschlag zu RFC-Status ge- langen zu lassen, wurde in diesem Fall beschlossen, sowohl diesen Vorschlag, als auch den komplexeren, auf Compound Matching Rules beruhenden Vorschlag [Chadwick 2002a]
und b, [Legg] als RFC zu veröffentlichen (wobei jedoch nur letzterer in der Kategorie Standards Track veröffentlicht wird). Für den hier vorgestellten Vorschlag gibt mittlerwei- le zwei unabhängige Implementierungen, für den Alternativvorschlag lediglich eine. Die Zukunft wird zeigen, welche der beiden Technologien von den Implementierungsherstel- lern besser angenommen wird. Es ist nicht auszuschließen, dass sich der hier vorgestellte Vorschlag letztendlich wegen der einfacheren Implementierbarkeit durchsetzt.
Literatur
[Chadwick 2002a] Chadwick, D. and S. Legg: „Internet X.509 Public Key Infrastructure – LDAP Schema and Syntaxes for PKIs“, Internet Draft (work in progress), June 2002,
<draft-ietf-pkix-ldap-pki-schema-00.txt>.
[Chadwick 2002b] Chadwick, D., Mullan, S.: Returning Matched, Values with LDAPv3, Internet Draft (work in progress), June 2002, <draft-ietf-ldapext-matchedval-06.txt>.
[Chadwick 2003a] Chadwick, D. W., Sahalayev, M. V.: Internet X.509 Public Key Infrastructure LDAP schema for X.509 CRLs, Internet Draft (work in progress), June 2003,
< draft-ietf-pkix-ldap-crl-schema-01.txt>.
[Chadwick 2003b] Chadwick, D. W., Sahalayev, M. V.: Internet X.509 Public Key Infrastruc- ture LDAP Schema for X.509 Attribute Certificates, Internet Draft (work in progress), February 2003, <draft-ietf-pkix-ldap-ac-schema-00.txt>.
9Vgl.http://www.dfn-pca.de/.
[DAASI] DAASI International: Abschlussbericht für das Projekt Ausbau und Weiter- betrieb eines Directory Kompetenzzentrums (Auftragsnummer TK 602 – SD 117) am Zentrum für Datenverarbeitung der Universität Tübingen durchge- führt von der DAASI International GmbH, April 2003.
[Ford] Ford, Warwick: XML Key Management Specification (XKMS), W3C Note 30, March 2001,http://www.w3.org/TR/2001/NOTE-xkms-20010330/.
[Gietz 2002a] Gietz, Peter: Verzeichnisdienste für Hochschulen auf Open Source Grundlage.
In: v. Knop, Jan, Bode, Friedrich: Tagungsband über die Informations- und Verzeichnisdienste in Hochschulen, Düsseldorf 2002.
[Gietz 2003] Gietz, Peter, Klasen, Norbert: An LDAPv3 Schema for X.509 Certificates, In- ternet Draft (work in progress) , June 2003, <draft-klasen-ldapx509certificate- schema-03.txt>.
[Greenblatt] Greenblatt, B.: LDAP Object Class for Holding Certificate Information. Inter- net Draft (expired), Februar 2000.
[Gutmann] Gutmann, Peter: Internet X.509 Public Key Infrastructure Operational Proto- cols: Certificate Store Access via HTTP, Internet Draft (work in progress), March 2003, <draft-ietf-pkix-certstore-http-05.txt>.
[Legg] Legg, S.: LDAP & X.500 Component Matching Rules, Internet Draft (work in progress), October 2002, <draft-legg-ldapext-component-matching-09.txt>.
[RFC2559] Boeyen, S., Howes, T., Richard, P.: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2., RFC 2559, April 1999.
[RFC2560] Myers, M., et al., X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, RFC 2560, June 1999.
[RFC2651] Allen, J., Mealling, M.: The Architecture of the Common Indexing Protocol (CIP), RFC 2651, August 1999.
[RFC3039] Santesson, S., Polk, W., Barzin, P., Nystrom, M.: Internet X.509 Public Key Infrastructure Qualified Certificate Profile, RFC 3039, January 2001.
[RFC3280] Housley, R., Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key Infra- structure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April 2002.
[RFC3281] Farrel, S., Housley, R., An Internet Attribute Certificate Profile for Authori- zation, RFC 3281, April 2002.
[RFC3377] Hodges, J., Morgan, R., Lightweight Directory Access Protocol (v3): Techni- cal Specification, RFC 3377, September 2002.
[Rivest] Rivest, Ronald L., Shamir, Adi, Adleman, Leonard: On Digital Signatures and Public Key Cryptosystems, MIT Laboratory for Computer Science Technical Memorandum 82, April 1977.
[Sahalayev] Sahalayev, M., Chadwick, D.: Detailed Design of an LDAP X.509 Parsing Ser- ver, Februray 2003, http://www.terena.nl/tech/projects/OpenLDAP/Doc/
Detailed\_Designv1-5.pdf.
[Tuecke] Tuecke, Steve, et al.: Internet X.509 Public Key Infrastructure Proxy Certifi- cate Profile, Internet Draft (work in progress), May 2003, < draft-ietf-pkix- proxy-06>.
