Neues Konzept für einen DFN-weiten Zertifikatsserver

Transkript

1 Neues Konzept für einen DFN-weiten Zertifikatsserver Peter Gietz DAASI International GmbH 1 Einleitung Seit 1994 wurden vom BMBF finanzierte DFN-Forschungsprojekte zu Verzeichnisdiensten an der Universität Tübingen durchgeführt. In den ersten dieser Projekte stand der Aufbau und Betrieb eines verzeichnisses für die deutsche Forschung 1 im Vordergrund. 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 Lightweight Directory Access Protocol (LDAP), welches mittlerweile in der Version 3 vorliegt [RFC3377], eine immer größere Bedeutung. Ein wichtiges Thema, welches in den letzten beiden Projektphasen angegangen wurde, war es, vorhandene LDAP-Speichermodelle für die Veröffentlichung von Zertifikaten, wie sie für die auf asymmetrische Verschlüsselungsverfahren basierende sogenannten Public Key Infrastructure (PKI) auftreten, zu evaluieren, sowie bei Bedarf ein neues optimiertes Modell zu erstellen. Die DAASI International GmbH wurde als Spin-Off der Universität Tübingen gegründet um als Nochfolgeinstitution der DFN-Projekte zu fungieren. Das letzte zweijährige Projekt 3 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 öffentlichen und einem privaten Schlüssel. Dadurch, dass die beiden Schlüssel in einem mathematischen Zusammenhang stehen, der private Schlüssel aber ab einer gewissen Schlüssellä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 Zertifikat wird von einer Certification Authority (CA) genannten vertrauenswürdigen Instanz (einer sog. Third Trusted Party), erstellt. Hierbei bestätigt die CA die zu einem öffentlichen Schlüssel gehörigen Identität mittels einer digitalen Signatur, nachdem die Identität z.b. über einen Personalausweis verifiziert wurde. 1 AMBIX-D (Aufnahme von Mail-Benutzern in das X.500 Directory), siehe dfn.de/. 2 Vgl. wo auch die Projektergebnisse veröffentlicht wurden. 3 Ausbau und Weiterbetrieb eines Directory Kompetenzzentrums

2 460 Peter Gietz Eine entscheidende Voraussetzung für die effiziente Anwendbarkeit einer auf das RSA- Verfahren beruhende PKI ist die Verfügbarkeit der öffentlichen Schlüssel der teilnehmenden Benutzer. Speziell bei der -Kommunikation sind die Benutzer darauf angewiesen sei es, um dem Kommunikationspartner eine verschlüsselte Nachricht zu schicken, oder um eine signierte 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, Verschlüsselbarkeit der Client-Server-Kommunikation, sichere Authentifizierungsmechanismen, die Verteilbarkeit der Daten auf verschiedene Server, sowie stabile Zugriffskontrollund Replikationsmechanismen. Eine kurze allgemeine Einführung in LDAP bietet z.b. [Gietz 2002a]. Nahezu alle -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 Informationen 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 -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 -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 Feld keyusage den Wert digitalsignature hat. 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 erheblichen Performance-Problemen führen. Zwar bieten die Autoren eine Lösung für dieses

3 Neues Konzept für einen DFN-weiten Zertifikatsserver 461 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 Control 4 vorgeschlagen, das es dem Server erlaubt, nur bestimmte Werte eines Attributes zurückzuliefern. In Verbindung mit speziellen Vergleichsoperatoren (sogenannte Matching-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 Index die einzelnen Felder dieser Struktur indizieren. Erste Implementierungserfahrungen in einem TERENA Projekt 5 haben gezeigt, wie schwierig eine solche Implementierung ist. Diese Erfahrungen haben in jenem Projekt dazu geführt, auf die hier vorgeschlagene Lösung zurückzugreifen 6. Das dadurch bedingte völlig neue Design der Software ist in [Sahalayev] dokumentiert. 4 Vorschlag einer einfacheren Lösung Als einfache, leicht implementierbare Alternative 7 hierzu wird in [Gietz 2003] vorgeschlagen, alle Zertifikate aus einem Eintrag zu entfernen und stattdessen als eigenständige Einträ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önnen. 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 Flexibilität in Bezug auf die Strukturierung des LDAP-Datenbaums (DIT). Man kann die Zer- 4 LDAP Controll ist eine der Erweiterungsmechanismen für LDAP, womit eine neue LDAP-Operation (Request und Response) im Protokoll definiert werden kann. 5 Adding Certificate Retrieval to OpenLDAP, vgl. OpenLDAP4PKIproposal.rtf 6 Vgl. das Protokoll über ein Project Review Meeting unter Doc/Review pdf 7 Die ursprüngliche Idee zu diesem Vorschlag entstammt [Greenblatt], ein längst verfallener Internet Draft, der allerdings wesentlich weniger Attribute vorschlägt.

4 462 Peter Gietz tifikate sowohl unterhalb eines Personeneintrags vorhalten, wie er in einem Personenverzeichnis (White Pages Dienst) vorkommt, als auch in einem reinen Zertifikatsverzeichnis ablegen. Für beide Alternativen wurden Namensregeln spezifiziert, wobei beim Zertifikatsverzeichnis, 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 Zertifikate verschiedener CAs enthält, wird der RDN mittels CA-Name (IssuerDN) und Seriennummer gebildet. Da die Verzeichnisdienstimplementierung von Microsoft den LDAPv3- Standard nicht vollständig unterstützt und solche aus mehren Attributen zusammengesetzten 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 Zertifikatsverzeichnis gespeichertem Zertifikat auf einen Personeneintrag in einem getrennten Personenverzeichnis verweisen zu können. Auch der umgekehrte Verweis vom Personenverzeichnis 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 notwendig. 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 hochskalierbares 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 zentralen 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 Grundidee 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].

5 Neues Konzept für einen DFN-weiten Zertifikatsserver 463 Abbildung 1: Architektur eines CIP basierten Index Systems 5 PKI/LDAP Projekt in Baden Württemberg Im Rahmen eines Baden-Württembergischen Landesprojekts 8 werden die hier vorgestellten Technologien in einer landesweiten PKI realisiert. Projektpartner sind die Universitä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-Authorisierung, 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 verschiedene Verzeichnisdienstimplementierungen, wie OpenLDAP, Novell edirectory oder Microsoft Active Directory (AD) aufbauen, integrieren lassen. Voraussetzung ist lediglich die Unterstützung des LDAPv3-Protokolls. 8 Projekt: Landesweite PKI auf Basis von indizierten Verzeichnisdiensten mit standardisierten LDAP Zugriffsmechanismen, Beginn: August 2003.

6 464 Peter Gietz Abbildung 2: Architektur des PKI-LDAP-Projekts Der zentrale Indexserver indiziert sowohl die Zertifikate, die in lokalen Zertifikatsverzeichnissen gespeichert sind, als auch die des zentralen Zertifikatsverzeichnisses, welches für diejenigen CAs betrieben wird, welche nicht selber einen solchen Verzeichnisdienst betreiben 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 implementiert werden sollte. Die Bedeutung organisationsübergreifender Authentifizierungsund darauf aufbauende Authorisierungsverfahren, die es z.b. einem Studenten der Hochschule 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-

7 Neues Konzept für einen DFN-weiten Zertifikatsserver 465 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 Attributzertifikats-Infrastruktur (Priviledge Management Infrastructure, PMI) mit Spezial-Authorisierungen 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. Jedenfalls 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 anzugehen. 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 Certification Policy, die gemeinsame Zertifizierungsinfrastruktur, die dadurch hergestellt wurde, 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 koordinierter Verzeichnisdienst. Hier können die Ergebnisse der DFN-Verzeichnisdienstprojekte, insbesondere das hier vorgestellte Datenschema und die darauf beruhende Testimplementierung, sowie die zukünftigen Erfahrungen aus dem PKI/LDAP-Projekt einfließen. Der mittlerweile aus drei Internet-Drafts [Chadwick 2003a] und b, [Gietz 2003] bestehende 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 gelangen 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 mittlerweile zwei unabhängige Implementierungen, für den Alternativvorschlag lediglich eine. Die Zukunft wird zeigen, welche der beiden Technologien von den Implementierungsherstellern besser angenommen wird. Es ist nicht auszuschließen, dass sich der hier vorgestellte Vorschlag letztendlich wegen der einfacheren Implementierbarkeit durchsetzt. Literatur [Chadwick 2002a] [Chadwick 2002b] [Chadwick 2003a] [Chadwick 2003b] 9 Vgl. 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, D., Mullan, S.: Returning Matched, Values with LDAPv3, Internet Draft (work in progress), June 2002, <draft-ietf-ldapext-matchedval-06.txt>. 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, D. W., Sahalayev, M. V.: Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates, Internet Draft (work in progress), February 2003, <draft-ietf-pkix-ldap-ac-schema-00.txt>.

8 466 Peter Gietz [DAASI] [Ford] [Gietz 2002a] [Gietz 2003] [Greenblatt] [Gutmann] [Legg] [RFC2559] [RFC2560] [RFC2651] [RFC3039] [RFC3280] [RFC3281] [RFC3377] [Rivest] [Sahalayev] [Tuecke] DAASI International: Abschlussbericht für das Projekt Ausbau und Weiterbetrieb eines Directory Kompetenzzentrums (Auftragsnummer TK 602 SD 117) am Zentrum für Datenverarbeitung der Universität Tübingen durchgeführt von der DAASI International GmbH, April Ford, Warwick: XML Key Management Specification (XKMS), W3C Note 30, March 2001, 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 Gietz, Peter, Klasen, Norbert: An LDAPv3 Schema for X.509 Certificates, Internet Draft (work in progress), June 2003, <draft-klasen-ldapx509certificateschema-03.txt>. Greenblatt, B.: LDAP Object Class for Holding Certificate Information. Internet Draft (expired), Februar Gutmann, Peter: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP, Internet Draft (work in progress), March 2003, <draft-ietf-pkix-certstore-http-05.txt>. Legg, S.: LDAP & X.500 Component Matching Rules, Internet Draft (work in progress), October 2002, <draft-legg-ldapext-component-matching-09.txt>. Boeyen, S., Howes, T., Richard, P.: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2., RFC 2559, April Myers, M., et al., X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP, RFC 2560, June Allen, J., Mealling, M.: The Architecture of the Common Indexing Protocol (CIP), RFC 2651, August Santesson, S., Polk, W., Barzin, P., Nystrom, M.: Internet X.509 Public Key Infrastructure Qualified Certificate Profile, RFC 3039, January Housley, R., Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April Farrel, S., Housley, R., An Internet Attribute Certificate Profile for Authorization, RFC 3281, April Hodges, J., Morgan, R., Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377, September Rivest, Ronald L., Shamir, Adi, Adleman, Leonard: On Digital Signatures and Public Key Cryptosystems, MIT Laboratory for Computer Science Technical Memorandum 82, April Sahalayev, M., Chadwick, D.: Detailed Design of an LDAP X.509 Parsing Server, Februray 2003, Detailed\_Designv1-5.pdf. Tuecke, Steve, et al.: Internet X.509 Public Key Infrastructure Proxy Certificate Profile, Internet Draft (work in progress), May 2003, < draft-ietf-pkixproxy-06>.