Zasady certyfikacji

W celu wzajemnego zaufania i wzajemnej certyfikacji urzędy certyfikacji w dwóch domenach muszą działać zgodnie z podobnymi zasadami. Użytkownicy w dwóch domenach powinni mieć możliwość akceptowania lub odrzucania certyfikatów ze swoich domen na podstawie wymagań bezpieczeństwa aplikacji oraz zasad, zgodnie z którymi certyfikaty zostały wydane. W celu określenia podobieństwa lub równoważności polityk obu domen, CP powinien być napisany przy użyciu standardu IETF RFC-2527. CP jest reprezentowany za pomocą OID w certyfikacie. Aby upewnić się, że oprogramowanie użytkownika akceptuje i odrzuca certyfikaty na podstawie wymagań aplikacji i CP, produkty PKI powinny być wybierane i konfigurowane w taki sposób, aby urząd certyfikacji odpowiednio potwierdzał zasady certyfikatów, mapowanie zasad i rozszerzenia ograniczeń zasad. Oprogramowanie użytkownika obsługujące PKI musi przetwarzać te rozszerzenia odpowiednio iw pełni zgodnie z wymaganiami reguł weryfikacji ścieżki certyfikatu X.509

Format certyfikatu i listy unieważnionych certyfikatów

Strony komunikujące się muszą współdzielić lub muszą być w stanie zrozumieć nawzajem swoje certyfikaty i formaty listy CRL. Najczęstszym sposobem osiągnięcia tego jest użycie wspólnego standardu, takiego jak X.509. Wiele razy było to niewystarczające ze względu na niejednoznaczność standardu i powiązanych schematów kodowania, chociaż z biegiem czasu błędy te zostały naprawione. Obecnie głównym powodem, dla którego certyfikaty i listy CRL wydawane przez jeden produkt mogą nie być rozumiane przez inny, jest to, że jeden lub oba nie są zgodne z normą lub jeden produkt nie realizuje wszystkich cech normy stosowanej przez inny produkt. Strony komunikujące się muszą uzyskać certyfikaty i listy CRL wydane przez różne urzędy certyfikacji w swoich domenach. Te certyfikaty i listy CRL można uzyskać z repozytorium, takiego jak serwer X.500 i Lightweight Directory Access Protocol (LDAP). Alternatywnie, certyfikaty i listy CRL mogą być przenoszone jako część protokołu komunikacyjnego między stronami, na przykład zgodnie z definicją w S/MIME (Secure/Multipurpose Internet Mail Extension) w wersji 3. Repozytoria X.500 i LDAP są oparte na hierarchii bazy danych. Każdy węzeł w hierarchicznej strukturze drzewa należy do klasy obiektów. Klasa obiektu węzła określa atrybuty, które są przechowywane dla tego węzła. Przykładami atrybutów są stanowisko, numer telefonu, numer faksu i tym podobne. Certyfikaty i listy CRL są również atrybutami. X.500 i LDAP zdefiniowały standardowy schemat dla certyfikatów PKI i list CRL. W przypadku certyfikatów te atrybuty to userCertificate, cACertificate i crossCertificatePair. Certyfikaty jednostki końcowej powinny być przechowywane w atrybucie userCertificate. Wszystkie certyfikaty CA powinny być przechowywane w elemencie forward atrybutu crossCertificatePair podmiotu CA. Ponadto wszystkie certyfikaty wydane urzędom certyfikacji w tej samej domenie powinny być przechowywane w atrybucie cACertificate podmiotu CA. Różne listy odwołania powinny być przechowywane w atrybutach cRL, aRL i deltaCRL wystawiającego urzędu certyfikacji, stosownie do przypadku. Jeśli certyfikaty i listy CRL nie są przechowywane w tych ustandaryzowanych atrybutach, oprogramowanie strony zależnej może nie być w stanie uzyskać tych obiektów. Ponadto produkty katalogowe X.500 nadal mogą nie zawsze współpracować ze względu na dodatkową złożoność standardu X.500 i różnice między produktami. Wdrażając katalogi X.500 i łącząc produkty katalogowe X.500 od różnych dostawców, realizatorzy powinni mieć czas na współdziałanie produktów i katalogów.

Ścieżka zaufania

Strony komunikujące się muszą być w stanie utworzyć ścieżki zaufania od swoich kotwic zaufania do swoich subskrybentów. Można to osiągnąć za pomocą wielu kotwic zaufania, certyfikacji krzyżowej i innych opisanych wcześniej modeli zaufania.

Algorytmy kryptograficzne.

Strony komunikujące się muszą wdrożyć stosowane przez siebie algorytmy kryptograficzne, takie jak hashowanie, podpisy cyfrowe, szyfrowanie kluczy i szyfrowanie danych. Ponadto strony powinny mieć możliwość komunikowania się ze sobą algorytmów, których używają. W certyfikatach X.509 i CRL informacje te mogą być zawarte w samych obiektach, podobnie jak w polu algorytmu. W certyfikatach X.509 dla przekazywanych informacji algorytmy, takie jak podpis cyfrowy i algorytm szyfrowania klucza, mogą być przenoszone w certyfikacie podmiotu końcowego. Algorytm mieszający i algorytm szyfrowania danych mogą stanowić część dorozumianej umowy między stronami lub mogą być przenoszone wraz z przekazywanymi informacjami. Informacje można również uzyskać z obsługiwanego atrybutu algorytmów wpisu katalogu X.500 użytkownika, chociaż ta opcja nie jest powszechnie stosowana. Chociaż oczekiwane algorytmy klucza publicznego używane przez CA do tworzenia certyfikatu muszą być rozpoznawalne przez odbiorcę (w celu zrozumienia zawartości certyfikatu), ważne jest, aby certyfikat nie zawierał żadnych asercji co do algorytmów symetrycznych, które mogą być użyte. Certyfikat powinien być niezależny od aplikacji i nie nakładać żadnych reguł na aplikacje, gdy nie jest to konieczne. We wszystkich tych sytuacjach algorytm jest identyfikowany za pomocą identyfikatorów obiektów. Różne organizacje mogą zarejestrować ten sam algorytm pod swoim łukiem OID. Dlatego ważne jest, aby albo te dwie domeny używały tego samego OID dla algorytmów, albo aby ich oprogramowanie interpretowało wiele OID jako ten sam algorytm. Z tego powodu proliferacja OID dla algorytmów nie jest zalecana. Warianty tego samego algorytmu podstawowego dodatkowo pogłębiają problemy z interoperacyjnością algorytmów. Na przykład, subtelne dopełnienie i inne różnice istnieją między definicjami algorytmu RSA w Standardach Kryptografii Klucza Publicznego (PKCS) i w komitecie X9 Amerykańskiego Narodowego Instytutu Standardów (ANSI). Podobnie algorytm Diffie-Hellmana ma różne tryby i różne sposoby redukcji obliczonego klucza tajnego do rozmiaru klucza symetrycznego (tj. sposoby zmniejszania kluczy sesji). Każda z tych różnic w algorytmach musi być udokumentowana za pomocą różnych OID, aby OID wywołał odpowiednią implementację. Ważne jest, aby rozszerzenia były wybierane ostrożnie. Te dotyczące algorytmów często mają znaczenie w kontekście konkretnej aplikacji. Jak wspomniano wcześniej, dobrym przykładem rozszerzenia, którego nie należy umieszczać w certyfikacie, jest rozszerzenie SMIME Capabilities, ponieważ nie określa ono minimalnych oczekiwań, a zamiast tego może ograniczać długość klucza symetrycznego, którego mogą używać aplikacje. Takie rozszerzenia specyficzne dla aplikacji należy unikać w certyfikatach użytkownika/subskrybenta. Algorytmy i długości kluczy używane przez elementy klucza publicznego (asymetryczne) są określone w wartościach pola, takich jak Informacje o kluczu publicznym podmiotu.

Interoperacyjność infrastruktury klucza publicznego

Złożoność technologii, standardów i produktów technologii PKI z jednej domeny do drugiej iz jednego produktu do drugiego czasami stwarza problemy z interoperacyjnością. Jednak bez interoperacyjności międzydomenowej nie może istnieć zaufanie globalne, a jedynie zaufanie indywidualne. Czynniki te odgrywają kluczową rolę w zapewnieniu interoperacyjności PKI:

* Ścieżka zaufania

* Algorytmy kryptograficzne

*Formaty certyfikatów i listy CRL

* Rozpowszechnianie certyfikatów i list CRL

* Zasady dotyczące certyfikatów

* Nazwy

Certyfikacja krzyżowa

W najprostszej formie certyfikacja krzyżowa składa się z dwóch urzędów certyfikacji, które certyfikują się wzajemnie, wydając sobie nawzajem certyfikat. Certyfikaty mogą być przechowywane w określonych atrybutach wpisu do katalogu w certyfikacie; przykłady obejmują parę atrybutów cross-certificate lub certyfikat CA. Z certyfikacją krzyżową wiążą się dwa praktyczne problemy. Jeden zajmuje się produktami handlowymi. Jeśli te dwie domeny korzystają z różnych produktów, ich urzędy certyfikacji mogą nie być w stanie wymieniać informacji w celu przeprowadzenia certyfikacji krzyżowej, a ich katalogi mogą nie być w stanie połączyć w łańcuch, aby umożliwić stronom ufającym pobieranie certyfikatów.

Drugi problem jest operacyjny. Przed certyfikacją innego urzędu certyfikacji, urząd certyfikacji wystawiający certyfikat musi upewnić się, że przedmiotowy urząd certyfikacji działa zgodnie z akceptowanymi mechanizmami kontroli, określonymi w CP. Wystawiający urząd certyfikacji potwierdza odpowiedni CP w rozszerzeniu „polityki certyfikatów” certyfikatu X.509 w wersji 3 przedmiotowego urzędu certyfikacji. W praktyce oba CA przeprowadzają wzajemne poświadczenie wzajemnej certyfikacji po dokonaniu wzajemnego przeglądu swoich CP i po upewnieniu się, że CP można uznać za równoważne. Nie oznacza to, że wszystkie kontrole bezpieczeństwa i obowiązki są identyczne, ale muszą oferować w przybliżeniu podobne poziomy zaufania i zobowiązań oraz podobną odpowiedzialność i ulgę finansową. Gdy dwa urzędy certyfikacji przeprowadzają wzajemne certyfikację krzyżową, zaufanie na ogół dotyczy ograniczonego zestawu zasad poprzez potwierdzenia w rozszerzeniach „zasad certyfikatów”, a zaufanie jest tylko dwustronne. Innymi słowy, zaufanie nie zmieni się; pozostanie między dwoma urzędami certyfikacji. Urzędy certyfikacji zapewniają to poprzez hamowanie mapowania polityki poprzez rozszerzenie „policy limits”. Rozszerzenia ograniczeń zasad umożliwiają różne zahamowania mapowania zasad w łańcuchu certyfikatów. W większości bezpośrednich certyfikacji krzyżowych mapowanie zasad powinno zostać natychmiast wstrzymane. W przypadku certyfikacji krzyżowej z wykorzystaniem modelu pomostowego CA, aby skorzystać z usług mapowania polityk pomostowego CA, inhibicja polisy powinna być inna dla jednego certyfikatu (czyli certyfikatu pomostowego CA). Ponadto oba urzędy certyfikacji powinny używać rozszerzenia „ograniczenia nazw” w certyfikatach X.509 w wersji 3, aby upewnić się, że ufają drugiej domenie w zakresie nazw, nad którymi ta druga ma kontrolę. Korzystanie z tego rozszerzenia minimalizuje również szanse na kolizję nazw. W przypadku dwustronnej certyfikacji krzyżowej mapowanie polityk powinno zostać natychmiast wstrzymane przez użycie wartości „0” w polu „inhibit policy mapping” rozszerzenia ograniczeń polityk w certyfikatach X.509. Gdy pomost CA jest używany do interoperacyjności międzydomenowej, w tym polu należy użyć wartości „1”. Pozwoli to domenie wydającego urzędu certyfikacji na mapowanie swoich zasad do zasad pomostowego urzędu certyfikacji, a następnie zezwoli pomostowemu urzędowi certyfikacji na mapowanie swoich zasad na przedmiotową domenę urzędu certyfikacji, w efekcie mapowanie z domeny wydającego urzędu certyfikacji na domenę przedmiotowego urzędu certyfikacji. Dopóki wystawiający urząd certyfikacji używa swojej kontroli nad mapowaniem zasad blokowania, pomostowy urząd certyfikacji nie musi używać mapowania zasad blokowania do kontrolowania blokowania mapowania.

Wybór architektury infrastruktury klucza publicznego

To, czy domena (przedsiębiorstwo) wybierze jeden urząd certyfikacji, czy wiele urzędów certyfikacji do swojej operacji wewnątrzdomenowej, należy określić na podstawie różnych czynników, w tym:

* Kultura zarządzania

* Polityka organizacji

* Rozmiar ścieżki certyfikacji

* Wielkość populacji subskrybenta

* Rozkład populacji subskrybentów

* Informacje o odwołaniu

W wielu sytuacjach polityka lub struktura zarządzania może dyktować istnienie wielu urzędów certyfikacji w domenie. Innymi słowy, organizacje na poziomie jednostki biznesowej, na poziomie biura regionalnego, na poziomie korporacji lub na poziomie krajowym mogą chcieć stworzyć CA, aby zapewnić im pewien stopień kontroli, niezależności, autonomii i prestiżu. Sposób organizacji tych urzędów certyfikacji (dwustronna certyfikacja krzyżowa, hierarchia itp.) będzie również zależeć od zarządzania i krajobrazu politycznego domeny. Model zaufania powinien być taki, aby umożliwiał zarządzanie rozmiarem ścieżki certyfikacji; w przeciwnym razie użytkownicy końcowi zobaczą niedopuszczalne pogorszenie wydajności uzyskiwania certyfikatów i list CRL oraz weryfikowania podpisów cyfrowych na certyfikatach i listach CRL. Podobnie, duże populacje subskrybentów mogą wymagać więcej niż jednego urzędu certyfikacji, aby zapewnić, że urząd certyfikacji może zarządzać subskrybentami i utrzymać mały rozmiar listy CRL. W przypadku wybrania produktów urzędu certyfikacji, które wystawiają partycjonowane listy CRL, można zarządzać rozmiarami list CRL nawet w przypadku bardzo dużej populacji subskrybentów. Dalsze omówienie kwestii listy CRL można znaleźć w sekcji 37.7 na temat alternatyw unieważnienia. Rozważając międzydomenową certyfikację krzyżową, należy wziąć pod uwagę podobne kwestie.

Siatka

Ostatnim przykładem modelu zaufania jest siatka (inaczej sieć lub anarchia). Termin „siatka” opisuje dowolny obraz reprezentujący zaufanie między urzędami certyfikacji lub certyfikatami bez żadnych określonych reguł lub wzorców. Model ten jest czasem nazywany siecią zaufania i jest szczególnie kojarzony z oryginalnym projektem Pretty Good Privacy, jednym z pierwszych popularnych systemów implementujących certyfikaty klucza publicznego. W ramach tej struktury każdy odbiorca musi wyraźnie ufać sobie nawzajem. Głównym problemem jest to, że nie skaluje się zbyt dobrze poza kilkuset użytkowników.

Wiele kotwic zaufania

Inną alternatywą jest uzyskanie przez stronę ufającą kluczy publicznych różnych urzędów certyfikacji w zaufany sposób, a następnie użycie tych kluczy publicznych jako kotwic zaufania. Takie podejście jest atrakcyjne, gdy urzędy certyfikacji nie mogą lub nie chcą przeprowadzać certyfikacji krzyżowej, a strona ufająca musi bezpiecznie komunikować się z subskrybentami w domenach urzędów certyfikacji, z których pochodzą. Takie podejście nazywa się wieloma kotwicami zaufania. Każda kotwica zaufania reprezentująca domenę może być pojedynczym urzędem certyfikacji lub PKI z kolekcją urzędów certyfikacji w modelu zaufania.

Most

Kolejnym modelem zaufania jest most. W tym modelu jeden urząd certyfikacji przeprowadza krzyżową certyfikację z każdym urzędem certyfikacji z różnych domen. Domeną mogą być organizacje lub segmenty wertykalne, takie jak bankowość lub opieka zdrowotna. Pomost CA nie jest kotwicą zaufania dla żadnej strony ufającej. CA w domenie strony ufającej jest kotwicą zaufania. W domenie nie ma ograniczeń dotyczących modelu zaufania. Sama domena PKI może być zorganizowana jako dowolny z zaufanych modeli, w tym mostu, co prowadzi do możliwych warstw urzędów certyfikacji mostu

Hierarchia

 W (nieścisłej) hierarchii podrzędne urzędy certyfikacji certyfikują swoich rodziców. Ponieważ graf skierowany jest dwukierunkowy, każdy urząd certyfikacji może być kotwicą zaufania dla stron uzależnionych. Jednak z praktycznego, operacyjnego i wydajnościowego punktu widzenia (tj. długości ścieżki certyfikatu) lokalny urząd certyfikacji powinien być kotwicą zaufania. Lokalny urząd certyfikacji to urząd certyfikacji, który wystawił certyfikat stronie ufającej