Maja Górecka-Wolniewicz
UCI UMK Toruń
Maja.Wolniewicz@uni.torun.pl

Internetowy protokół LDAP w dużym zakresie bazuje na standardzie X.500 opracowywanym od 1984 r. przez CCITT, a potem przez ITU. Integralną częścią X.500 jest rekomendacja X.509, dotycząca certyfikatów cyfrowych. LDAP początkowo nie był planowany jako wsparcie infrastruktury klucza publicznego (Public Key Infrastructure, PKI) i kryptografii asymetrycznej, jednak bardzo szybko zaczął być wykorzystywany do przechowywania certyfikatów oraz list odwołanych certyfikatów. Rozwiązania przygotowywane na bieżąco przez grupy IETF (m.in. grupy PKIX, LDAPEXT i LDAPBIS) nie zawsze okazywały się w pełni funkcjonalne, dlatego nadal trwa dyskusja nad sposobem umieszczania informacji związanej z infrastrukturą kluczy publicznych w bazie LDAP oraz nad metodami przekazywania tego typu danych.

W dokumencie RFC 1778 po raz pierwszy przedstawiono sposób przechowywania atrybutów związanych z PKI. W punktach od 2.25 do 2.29 opisano kolejno, jaka jest postać atrybutów: userCertificate, caCertificate, authorityRevocationList, certificateRevocationList, crossCertificatePair. Specyfikacja ta dotyczyła protokołu LDAPv2 i jak się okazało zaprojektowane rozwiązanie nie działało, ponieważ LDAP tej wersji domyślnie przed transferem danych przekodowywał wszystkie wartości z postaci BER ASN.1 (wewnętrzne kodowanie) do formatu napisu ASCII. Takie przekodowanie bywa nieodwracalne w odniesieniu do nazw wyróżnionych - wynika to z faktu, że relatywne nazwy wyróżnione (RDN) mogą składać się z różnego typu znaków (np. kod teletex, czy łańcuch uniwersalny). W efekcie, gdy w celu sprawdzenia certyfikatu realizowane jest przywrócenie wartości binarnej ASN.1 na podstawie napisu ASCII możliwe było uzyskanie wielu różnych napisów ASN.1 BER. RFC 2559 - dokument opisujący powiązania PKI z LDAP-em w wersji 2, w p. 8 ustala, że warości atrybutów zawierających certyfikaty lub ich listy muszą być kodowane jako "napisy ósemkowe" (octet string), a wartości certyfikatów muszą być przygotowane zgodnie ze standardem DER. Definiujący protokół LDAPv3 dokument RFC 2251 w p. 4.1.5.1 wprowadza opcję binary, która ma być umieszczana po średniku bezpośrednio za typem atybutu, by ustalić niestandardowy, binarny, a nie znakowy, sposób transferu wartości. Efektem opisanych wyżej zmian było powstanie niekompatybilności w zakresie oprogramowania, ale obecnie już większość serwerów i programów klienckich LDAPv3 prawidłowo obsługuje opcję transferu ;binary. Ta metoda przenoszenia informacji o sposobie transferu wartości atrybutu budziła wiele zastrzeżeń wśród różnych grup zajmujących się tematyką LDAP-a i PKI. Napis umieszczony po średniku za nazwą typu atrybutu spełnia dwie funkcje:

• może określać podtyp atrybutu, np. ou;lang-pl lub
• może wskazywać niedomyślny sposób przesyłania wartości atrybutu.

To podwójne znaczenie może mieć negatywne konsekwencje w przypadku pojawienia się nowych słów kluczowych. Dlatego w najnowszych korektach specyfikacji LDAPv3 (Internet-Draft, LDAP: The Protocol) usunięto omówienie opcji ;binary, natomiast w opisie schematu LDAP dla PKI dodano klauzulę, że rodzimym sposobem kodowania dla atrybutów PKI jest BER ASN.1, a nie ASCII.

David Chadwick w swoim artykule pt. Deficiencies in LDAP when used to support Public Key Infrastructures zawarł bardzo ważne uwagi dotyczące możliwości LDAP-a w zakresie obsługi infrastruktury klucza publicznego. Przedstawił niedociągnięcia protokołu LDAP zarówno w przypadku scentralizowanej usługi LDAP-PKI (jeden serwer LDAP i jedna infrastruktura kluczy publicznych), jak i w sytuacji, gdy mamy do czynienia z rozproszoną usługą obsługującą kilka infrastruktur PKI.

Jednym z istotnych problemów w scentralizowanej usłudze PKI korzystającej z LDAP-a jest sposób wyszukiwania właściwego certyfikatu lub listy unieważnionych certyfikatów. W najprostszym rozwiązaniu w każdym wpisie użytkownika jest przechowywany jeden certyfikat, a w każdym wpisie związanym z dystrybucją list unieważnionych certyfikatów - jedna lista unieważnionych certyfikatów. W takiej sytuacji pojawia się oczywisty problem - skąd użytkownik ma wiedzieć, w jakim wpisie jest dany certyfikat? Klient musi móc określić kryterium filtrowania, tak by serwer LDAP był w stanie przekazać mu właściwy wpis (np. wyszukanie poprzez podanie imienia i nazwiska osoby, której certyfikat jest nam potrzebny, czy e-maila tej osoby). Niestety, dotychczas zestandaryzowane w LDAP-ie reguły dopasowania nie obejmują ani certyfikatów, ani list unieważnionych certyfikatów.

Doraźnie próbuje się rozwiązać ten problem poprzez umieszczanie we wpisach oprócz atrybutu userCertificate dodatkowych atrybutów o wartościach wywodzących się z wartości pól certyfikatu, np. atrybut mail przenosi e-mail zawarty w certyfikacie, atrybut serialNumber - numer seryjny. Takie podejście jest nadzwyczaj kłopotliwe, wymaga ogromnej dbałości podczas synchronizacji zasobów, a poza tym, nie ma możliwości, by jeden użytkownik miał kilka certyfikatów. Dodatkowym problemem jest kwestia bezpieczeństwa - umieszczamy we wpisie, w niezależnych atrybutach komponenty certyfikatu, które nie sią chronione i nie są poświadczone podpisem cyfrowym.
Internet-Draft pt. An LDAPv3 Schema for X.509 Certificates wychodzi naprzeciw opisanym ograniczeniom, zostanie on omówiony w punkcie 5.

Grupa IETF PKIX opublikowała wszechstronne, ale jednocześnie bardziej skomplikowane rozwiązanie - opracowano zasady dopasowywania wartości certyfikatów i list unieważnionych certyfikatów. Internet-Draft pt. Returning Matched Values with LDAPv3, opisuje jak protokół LDAPv3 można wykorzystać do przekazywania z serwera podzbioru wartości atrybutów wpisu, zgodnie z zadanym filtrem wyszukania według wartości. Jest to szczególnie przydatne, jeśli jakiś atrybut wpisu typowo przechowuje wiele wartości, a użytkownik (klient LDAP) zazwyczaj chce wyselekcjonować jedną, konkretną wartość. Przedstawione w tym dokumencie podejście wymaga niestety również zmian w zakresie oprogramowania klienckiego LDAP, gdyż programy użytkowe muszą również wspierać nowe reguły dopasowania oraz doboru wartości.

Odrębny problem stanowi obsługa wielu certyfikatów przypisanych jednemu użytkownikowi, czyli umieszczonych w jednym wpisie bazy LDAP. Rozwój infrastruktur klucza publicznego oraz zróżnicowana natura certyfikatów spowodowały, że coraz częściej użytkownicy korzystają jednocześnie z kilku certyfikatów. Jeden certyfikat służy do poświadczania dokumentów podpisem cyfrowym, inny do obsługi zaszyfrowanej poczty elektronicznej, jeszcze inny jest używany do transakcji elektronicznych. Oczywistym miejscem przechowywania tych certyfikatów jest wpis użytkownika, do którego należą. Nie ma jednak metody, by pobierać z bazy LDAP jeden certyfikat (tj. jedną wartość atrybutu userCertificate), gdy występuje ich kilka. Zawsze w takiej sytuacji klient otrzymuje wszystkie wartości atrybutu i tylko klient mógłby wyselekcjonować właściwą wartość, ale wiąże się to z koniecznością wbudowania w programy użytkownika skomplikowanych reguł analizy certyfikatów w celu wyszukania potrzebnej wartości. Jeśli serwer LDAP realizowałby opisane wcześniej, zasady dopasowywania wartości atrybutów, zwracałby tylko wartości wymagane przez użytkownika, ale niestety brakuje implementacji tego podejścia.
Doraźnie administratorzy infrastruktur kluczy publicznych radzą sobie z problemem wielu certyfikatów należących do jednego użytkownika dwojako:

• tworzą nowe typy atrybutów dla poszczególnych rodzajów certyfikatów, np. smimeEncCert (dla certyfikatu szyfrującego), smimeNRcert (dla certyfikatu do podpisów cyfrowych) - każdy z takich atrybutów jest jednowartościowy, lub
• dopasowują strukturę drzewa danych LDAP do aplikacji PKI, np.:
  • nie zmieniając samej postaci drzewa danych umieszczają dodatkowe wpisy dotyczące danego użytkownika (mogą być to wpisy podporządkowane głównemu wpisowi użytkownika, lub wpisy umieszczane na tym samym poziomie co wpis główny; wpisy mają zazwyczaj nazwy identyfikujące typ certyfikatu, który zawierają);
  • dla każdej aplikacji PKI powstaje oddzielne poddrzewo danych, w którym każdy użytkownik ma swoje wpisy z certyfikatami.

Kolejne problemy w zakresie obsługi PKI przez system LDAP powstają, gdy chcemy współpracować z wieloma infrastrukturami kluczy publicznych rozproszonymi na wielu serwerach LDAP. Takie rozproszone środowisko pracy implikuje nowe wymagania:

• musi być możliwe udostępnianie wiedzy o lokalizacji innych serwerów LDAP oraz należy zdefiniować sposób współpracy serwerów - w usłudze X.500 stosowano specjalne atrybuty przenoszące informacje o adresach serwerów, ang. knowledge references, prace dotyczące wprowadzenia podobnych rozwiązań w LDAP-ie trwają;
• serwery powinny umieć przekazywać między sobą zlecenia klienta, tak by klient nie musiał kontaktować się samodzielnie z poszczególnymi serwerami i śledzić postęp realizacji zlecenia (LDAPv3 stosuje odesłania adresowe, ang. referrals, które są niewystarczające do transparentnej obsługi klienta, optymalnym rozwiązaniem byłoby łańcuchowanie zleceń w imieniu klienta do kolejnych serwerów, ang. chaining i przekazywanie klientowi odpowiedzi, a nie oedesłania adresowego);
• serwery powinny umieć realizować rozproszone uwierzytelnianie, aby klient nie musiał przechowywać w każdym serwerze swoich danych do uwierzytelniania.

Grupa IETF PKIX opracowała rozszerzenia certyfikatów umożliwiające umieszczanie informacji o lokalizacji serwera LDAP obsługującego daną infrastrukturę klucza publicznego w ramach samego certyfikatu. Po pierwsze wprowadzono pole CRL Distribution Points - punkty dystrybucji list unieważnionych certyfikatów, dzięki któremu klient pobierający dany certyfikat wie, gdzie szukać takiej listy, by sprawdzić ważność certyfikatu. Ponadto, podporządkowane centra certyfikacji (ang. Certification Authorities, CAs) mogą w wystawianych przez siebie certyfikatach dołączać listę nadrzędnych centrów certyfikacji oraz ich URL-e LDAP - ta informacja jest przechowywana w dodatkowym polu Authority Information Access. W przypadku pośredniej certyfikacji, certyfikat może zawierać w polu Subject Information Access lokalizację poświadczonego centrum certyfikacji certyfikatu, wartość tego pola jest również reprezentowana przez URL LDAP.
Niestety omówione rozszerzenia certyfikatów nie są powszechnie implementowane.

Dokument RFC 2559 opisuje protokół dedykowany do współpracy usługi LDAP ze środowiskiem PKI, przedstawia wymagania związane z tworzeniem i zarządzaniem repozytorium kluczy publicznych. W p. 8 omówiono niestandardowe kodowanie wartości atrybutów przenoszących certyfikaty wersji 3. Na przykład atrybut userCertificate musi zawierać certyfikat w formacie DER, taka wartość jest przenoszona w zleceniach jako octet string. W RFC 2587 został przedstawiony schemat wspierający PKI w środowisku LDAPv2, zdefiniowano atrybuty oraz klasy obiektów używane przez serwery LDAP funkcjonujące jako bazy danych PKI. Rozróżniono kilka typów obiektów przechowywanych w repozytoriach LDAP dla potrzeb PKI.

Użytkownicy
Często zdarza się, że wpis dotyczący użytkownika już istnieje w bazie LDAP i jest jedynie potrzebne dopisanie do niego informacji specyficznej dla PKI. Do wpisu może zostać dodana dodatkowa klasa obiektu pkiUser, by zaznaczyć związek danego użytkownika z infrastrukturą klucza publicznego oraz by umożliwić umieszczenie atrybutu userCertificate. Zgodnie z RFC 2798 atrybut userCertificate może również zostać przypisany wpisowi należącemu do klasy inetOrgPerson. Klasa ta dopuszcza dwa inne atrybuty przenoszące dane PKI: userSMIMECertificate (certyfikat poczty elektronicznej S/MIME) oraz userPKCS12 (PKCS 12 to format do wymiany informacji identyfikującej osobę).

Centra certyfikacji
Centra certyfikacji mogą mieć, tak samo jak użytkownicy, swoje wpisy w bazie LDAP jako zwykłe jednostki organizacyjne (organization lub organizationalUnit). Do reprezentowania centrów certyfikacji można użyć klasy obiektów pkiCA zdefiniowanej w RFC 2587. Ta dodatkowa klasa zezwala na stosowanie atrybutów:

• cACertificate - do przechowywania certyfikatów typu self-signed oraz certyfikatów wystawionych danemu centrum przez inne centrum certyfikacji w tej samej domenie funkcjonowania;
• crossCertificatePair - zawiera elementy, które przechowują wszystkie certyfikaty, poza self-signed, wystawione danemu CA oraz opcjonalne elementy zawierające certyfikaty wystawione przez to CA innym centrom;
• certificateRevocationList - zawiera listę certyfikatów, które zostały uznane za nieważne;
• authorityRevocationList - zawiera listę certyfikatów, które zostały wcześniej wystawione innym centrom certyfikacji, a obecnie są nieważne.

Miejsca dystrybucji list unieważnionych certyfikatów
Listy odwołanych certyfikatów (Certificate Revocation Lists, CRLs) to sposób dystrybucji informacji o skompromitowanych certyfikatach. Jeśli centrum certyfikacji chce zdefiniować specjalny obiekt pełniący funkcję punktu dystrybucji CRL-i, to służy do tego strukturalna klasa obiektów cRLDistributionPoint. Wpis należący do tej klasy musi zawierać atrybut cn z nazwą obiektu, a opcjonalnymi atrybutami są: certificateRevocationList, authorityRevocationList (omówione w poprzednim punkcie) oraz deltaRevocationList - przeznaczony dla przyrostowych list odwołanych certyfikatów.

Miejsca dystrybucji przyrostowych list unieważnionych certyfikatów
Przyrostowe listy odwołanych certyfikatów (Delta CRLs) to mechanizm opcjonalny. Jeśli istnieją w bazie LDAP obiekty reprezentujące punkty dystrybucji Delta CRLs, to zaleca się używanie klasy obiektów deltaCRL, która jest klasą pomocniczą i umożliwia dodawanie atrybutu deltaRevocationList.

Internet-Draft An LDAPv3 Schema for X.509 Certificates zawiera definicję nowych klas strukturanych, służących do przechowywania certyfikatów użytkowników i centrów certyfikacji (CAs). Podstawowym celem nowego schematu jest takie zapamiętywanie kluczowych pól certyfikatów, by ułatwić pobieranie potrzebnych certyfikatów wobec niedostatków funkcjonalności LDAP-a, opisanych w p. 3. Przedstawione w tym dokumencie rozwiązanie działa poprawnie w przypadku, gdy z danym wpisem jest związanych wiele certyfikatów.
Autorzy omawianej rekomendacji definiują dwie strukturalne klasy obiektów: x509userCertificate oraz x509caCertificate, dedykowane do przechowywania wpisów dotyczących odpowiednio użytkowników i centrów certyfikacji. Każdy certyfikat ma być przechowywany w oddzielnym wpisie, zlokalizowanym np. poniżej wpisu dotyczącego użytkownika czy CA. Ponieważ zapewne istnieje sporo aplikacji bazujących na tym, że certyfikat jest zapamiętany we wpisie obiektu, do którego należy, dlatego zaleca się, by przejściowo duplikować informację dotyczącą certyfikatu i utrzymywać ją zarówno we wpisie obiektu właściciela oraz w samodzielnym wpisie, zgodnie z ustaleniami w prezentowanym dokumencie. Umożliwi to gładką migrację do docelowej postaci repozytorium PKI. Te pola certyfikatów, które są potrzebne do jego identyfikacji i te, które są często używane w celu wyszukania właściwego certyfikatu są dodatkowo zapamiętane jako atrybuty wpisu. Proponowany projekt bazuje na istniejącej składni (syntax), dzięki czemu nie jest potrzebne definiowanie zasad dopasowywania wartości (matching rules) i aplikacje mogą wyszukiwać certyfikaty za pomocą prostych filtrów LDAP.

W p. 2 opisu nowego schematu porównano proponowane rozwiązanie z mechanizmem opisanym w innym, wspominanym już, dokumencie Internet-Draft, Returning Matched Values with LDAPv3, umożliwiającym przekazywanie klientowi podzbioru wartości atrybutu, zgodnie z przekazanym w zleceniu filtrem.
Główną zaletą tej osttniej metody jest nie ingerowanie w dotychczasową postać danych.
Również stosowanie dodatkowych obiektów typu x509certificate ma swoje plusy:

• nie są potrzebne żadne dodatkowe reguły dopasowania;
• w filtrze wyszukania można użyć dowolnego pola certyfikatu;
• zdecydowanie łatwiejsze jest usunięcie certyfikatu z drzewa danych (nie trzeba podawać w tym celu całego certyfikatu);
• przeszukania nie wymagające rozszerzonej kontroli specyficzne dla uzyskania podzbioru wartości atrybutów są realizowane szybciej;
• nie jest potrzebna modyfikacja oprogramowania serwera.

W p. 4.4 dokumentu An LDAPv3 Schema for X.509 Certificates została zdefiniowana abstrakcyjna klasa obiektów x509PKC, która obejmuje podstawowe pola każdego certyfikatu. Jest to klasa bazowa dwóch kolejnych klas strukturalnych: x509userCertificate - dla wpisów przechowujących certyfikaty użytkowników oraz x509caCertificate - dla wpisów przechowujących certyfikaty centrów certyfikacji. Określono też zewnętrzną klasę obiektów x509certificateHolder, pomyślaną dla wpisów przechowujących lokalizację wpisu typu x509certificate. W p. 4.1 omawianego dokumenty można znaleźć pełną definicję atrybutów dla obowiązkowych pól certyfikatu, a w p. 4.2 atrybuty dla wybranych rozszerzeń, w tym np. dla punktów dystrybucji certyfikatów. W p. 4.3 przedstawiono dodatkowe atrybuty, np. atrybut x509caCert do przechowywania kompletnego certyfikatu centrum certyfikacji, x509userCert do przechowywania kompletnego certyfikatu użytkownika.

Jeśli schemat opisany jest używany do przechowywania certyfikatów w bazie LDAP zawierającej wpisy dotyczące jednostek organizacyjnych oraz osób, to certyfikat należący do danego obiektu (osoby czy jednostki) powinien być umieszczany we wpisie bezpośrednio podporządkowanym wpisowi danej osoby lub jednostki. Wpisy te, dla zagwarantowania unikalności nazw wyróżnionych, muszą używać jako relatywnych nazw wyróżnionych (Relative Distinguished Name, RDN) dwóch atrybutów: X509issuer (wystawca certyfikatu) oraz x509serialNumber. Jeśli LDAP korzysta z implementacji, która nie akceptuje wielowartościowych RDN-ów, to dopuszcza się używanie atrybutu x509issuerSerial jako RDN-u wpisu. Gdy mamy do czynienia z bazą katalogową dedykowaną PKI, czyli taką, w której nie ma żadnej innej informacji, to rekomenduje się następującą strukturę drzewa danych: wpisy z certyfikatami sa przechowywane bezpośrednio poniżej wpisu centrum certyfikacji, przez które dany certyfikat został wystawiony, a wpisy powinny być nazywane za pomocą atrybutu x509serialNumber.

Zaletą rozwiązania polegającego na umieszczaniu poszczególnych pól certyfikatu w odrębnych atrybutach jest stosunkowo łatwe dostosowanie oprogramowania. Zgodnie z artykułami Modifying LDAP to Support X.509-basedPKIs oraz Detailed Design of an LDAP X.509 Parsing Server podstawową rolę w tym zakresie ma odgrywać X.509 Certificate Parsing Server (XPS). XPS ma spełniać funkcję serwera pośredniego pomiędzy klientem LDAP a typowym serwerem LDAP (np. serwer slapd w projekcie OpenLDAP). Jego zadaniem będzie przejęcie od poleceń Add lub Modify (wywoływanych w administracyjnych programach klienckich) atrybutów będących certyfikatami lub listami unieważnionych certyfikatów i utworzenie na ich podstawie nowych wpisów certyfikatu lub CRL-i. Tego typu serwer można implementować dwojako - poprzez wydzielenie drugiego serwera XPS lub przez zanurzenie jego kodu w oprogramowaniu podstawowego serwera. Zaletą jest skupienie wszystkich modyfikacji programowych po stronie serwera i możliwość precyzyjnego wyodrębnienia kodu XPS. Klient LDAP nie wymaga żadnych zmian, potrzebna jest jedynie jego konfiguracja z nowymi typami atrybutów.

Tradycyjny schemat przeznaczony do przechowywania w bazie LDAP danych PKI ma spore niedociągnięcia. Podejście przedstawione w dokumencie Internet-Draft dotyczącym nowego schematu dla certyfikatów X.509 ma ogromne zalety i daje możliwość efektywnego wyszukiwania certyfikatów. Gdy tylko stanie się dostępne oprogramowanie OpenLDAP implementujące XPS-a, korzystane z omówionego rozwiązania powinno być preferowane.