Polityka Certyfikacji dla Głównego Urzędu Certyfikacji Administracji Publicznej (Root CA)

Dokumentacja Centrum Certyfikacji Ministerstwa Spraw Wewnętrznych Tytuł dokumentu: Polityka Certyfikacji dla Głównego Urzędu Certyfikacji Administracji Publicznej (Root CA) Wersja: 1.1 Data wersji: 2013-11-27

Spis treści 1. Słownik używanych pojęć... 5 2. Wstęp... 7 2.1. Wprowadzenie... 7 2.2. Identyfikator Polityki Certyfikacji... 7 2.3. Opis systemu certyfikacji i uczestniczących w nim podmiotów... 8 2.4. Użycie certyfikatów... 9 2.4.1 Niedozwolone użycie certyfikatów... 9 2.4.2 Rozszerzenia certyfikatów... 9 2.5. Zasady administrowania Polityką Certyfikacji... 10 2.5.1 Punkty kontaktowe... 10 3. Zasady dystrybucji i publikacji informacji... 11 4. Identyfikacja i uwierzytelnienie... 12 4.1. Struktura nazw Subskrybentów... 12 4.2. Rejestracja i uwierzytelnienie Subskrybentów... 12 4.2.1 Sposoby uwierzytelnienia Subskrybentów przy początkowej rejestracji i wystawianiu pierwszego zaświadczenia certyfikacyjnego... 12 4.3. Sposoby uwierzytelnienia Subskrybenta przy wystawianiu kolejnych zaświadczeń certyfikacyjnych... 13 4.4. Sposoby uwierzytelnienia Subskrybenta przy zgłaszaniu żądania unieważnienia zaświadczeń... 13 5. Cykl życia zaświadczenia certyfikacyjnego wymagania operacyjne... 14 5.1. Wniosek o wydanie zaświadczenia... 14 5.2. Przetwarzanie wniosków i zgłoszeń certyfikacyjnych... 15 5.3. Wystawienie zaświadczenia... 16 5.4. Akceptacja zaświadczenia certyfikacyjnego... 16 5.5. Korzystanie z pary kluczy i zaświadczenia certyfikacyjnego... 16 5.5.1 Obowiązki Subskrybenta... 17 5.6. Wymiana zaświadczenia certyfikacyjnego... 17 5.7. Wydanie zaświadczenia certyfikacyjnego dla tej samej pary kluczy... 18 5.8. Modyfikacja zaświadczenia certyfikacyjnego... 18 5.9. Unieważnienie i zawieszenie zaświadczenia certyfikacyjnego... 18 5.10. Sprawdzanie statusu certyfikatu... 19 5.11. Zakończenie subskrypcji... 19 5.12. Odtwarzanie lub odzyskiwanie kluczy... 19 6. Zabezpieczenia organizacyjne, operacyjne i fizyczne CC... 20 6.1. Zabezpieczenia fizyczne... 20 6.2. Zabezpieczenia proceduralne... 20 6.3. Zabezpieczenia osobowe... 20 6.4. Procedury rejestrowania zdarzeń... 20 Strona 2 z 42

6.5. Archiwizacja zapisów... 20 6.6. Wymiana pary kluczy podsystemu certyfikacji Root CA... 21 6.7. Postępowanie po ujawnieniu lub utracie klucza prywatnego podsystemu certyfikacji Root CA... 22 6.7.1 Postępowanie po ujawnieniu klucza prywatnego podsystemu certyfikacji Root CA... 22 6.7.2 Postępowanie po zniszczeniu klucza prywatnego podsystemu certyfikacji Root CA... 23 6.7.3 Postępowanie po jednoczesnym ujawnieniu i utracie klucza prywatnego podsystemu certyfikacji Root CA... 24 6.8. Zakończenie działalności podsystemu certyfikacji Root CA... 25 7. Zabezpieczenia techniczne CC... 26 7.1. Generowanie i instalowanie par kluczy... 26 7.1.1 Generowanie par kluczy... 26 7.1.2 Dostarczenie klucza prywatnego Subskrybentowi... 26 7.1.3 Dostarczenie klucza publicznego Subskrybenta do CPR... 26 7.1.4 Dostarczenie klucza publicznego podsystemu certyfikacji Root CA... 27 7.1.5 Rozmiary kluczy... 27 7.1.6 Cel użycia klucza... 27 7.2. Ochrona kluczy prywatnych... 28 7.2.1 Standardy dla modułów kryptograficznych... 28 7.2.2 Wieloosobowe zarządzanie kluczem... 28 7.2.3 Powierzenie klucza prywatnego (key-escrow)... 28 7.2.4 Kopia bezpieczeństwa klucza prywatnego... 28 7.2.5 Archiwizowanie klucza prywatnego... 28 7.2.6 Wprowadzanie klucza prywatnego do modułu kryptograficznego... 29 7.2.7 Metoda aktywacji klucza prywatnego... 29 7.2.8 Metoda dezaktywacji klucza prywatnego... 29 7.2.9 Metoda niszczenia klucza prywatnego... 30 7.3. Inne aspekty zarządzania parą kluczy... 30 7.3.1 Długoterminowa archiwizacja kluczy publicznych... 30 7.3.2 Okresy ważności kluczy... 30 7.4. Dane aktywujące... 31 7.5. Zabezpieczenia komputerów... 31 7.6. Zabezpieczenia związane z cyklem życia systemu informatycznego... 32 7.6.1 Środki przedsięwzięte dla zapewnienia bezpieczeństwa rozwoju systemu... 32 7.6.2 Zarządzanie bezpieczeństwem... 32 7.7. Zabezpieczenia sieci komputerowej... 32 7.8. Oznaczanie czasem... 32 8. Profil zaświadczeń certyfikacyjnych i list ARL... 33 8.1. Profil zaświadczeń certyfikacyjnych... 33 8.1.1 Rozszerzenia zaświadczeń certyfikacyjnych i ich krytyczność... 34 8.1.2 Formaty identyfikatorów podsystemu certyfikacji Root CA... 34 8.1.3 Identyfikatory zgodnych Polityk Certyfikacji... 35 8.2. Profil list ARL... 35 8.2.1 Rozszerzenia list ARL i wpisów na listach ARL oraz krytyczność rozszerzeń... 36 8.2.2 Przyczyny unieważnienia zaświadczenia certyfikacyjnego... 37 8.3. Profil OCSP... 37 Strona 3 z 42

9. Audyt... 38 10. Inne postanowienia... 39 10.1. Opłaty... 39 10.2. Odpowiedzialność finansowa... 39 10.3. Poufność informacji biznesowych... 39 10.4. Ochrona danych osobowych... 39 10.5. Zabezpieczenie własności intelektualnej... 40 10.6. Udzielane gwarancje... 40 10.7. Zwolnienia z domyślnie udzielanych gwarancji... 40 10.8. Ograniczenia odpowiedzialności... 40 10.9. Przenoszenie roszczeń odszkodowawczych... 40 10.10. Przepisy przejściowe i okres obowiązywania Polityki Certyfikacji... 41 10.11. Określanie trybu i adresów doręczania pism... 41 10.12. Zmiany w Polityce Certyfikacji... 41 10.13. Rozstrzyganie sporów... 41 10.14. Obowiązujące prawo... 41 10.15. Podstawy prawne... 42 10.16. Inne postanowienia... 42 Strona 4 z 42

1. Słownik używanych pojęć W niniejszym dokumencie następujące sformułowania użyte będą w wymienionym poniżej znaczeniu: Pojęcie Opis CC certyfikat Gestor Inspektor ds. Rejestracji lista ARL lista CRL nośnik danych PKI (Public Key Infrastructure) CPR Centrum Certyfikacji system certyfikacji prowadzony pod kontrolą Gestora; system CC składa się z podsystemów certyfikacji realizujących odrębne polityki i posługujących się odrębnymi kluczami do generowania certyfikatów i list unieważnionych zaświadczeń certyfikacyjnych. elektroniczne zaświadczenie, za pomocą którego dane służące do weryfikacji podpisu elektronicznego są przyporządkowane do osoby składającej podpis elektroniczny i które umożliwiają identyfikację tej osoby. Kierownik komórki organizacyjnej, w tym przypadku Ministerstwa właściwego do spraw wewnętrznych, któremu na mocy wewnętrznego aktu prawnego, jakim jest Regulamin Organizacyjny, powierzono zarządzanie zasobem. Gestor ponosi odpowiedzialność kierowniczą przed Ministrem właściwym do spraw wewnętrznych za nadzór nad eksploatacją, rozwojem, utrzymaniem, korzystaniem, bezpieczeństwem i dostępem do zasobu. Osoba upoważniona do pracy w PR, posiadająca klucze kryptograficzne i certyfikaty upoważniające do wykonywania w podsystemie certyfikacji operacji przypisanych do PR. Lista unieważnionych zaświadczeń certyfikacyjnych dla centrów certyfikacji. Lista unieważnionych certyfikatów dla użytkowników końcowych. pamięć flash, płyta CD/DVD. Infrastruktura Klucza Publicznego zbiór urządzeń, oprogramowania, ludzi, polityk oraz procedur niezbędnych do tworzenia, zarządzania, przechowywania i dystrybucji certyfikatów klucza publicznego. Centralny Punkt Rejestracji Centrum Certyfikacji element systemu odpowiedzialny za obsługę Subskrybentów i składanych przez nich zgłoszeń certyfikacyjnych. Strona 5 z 42

Pojęcie Opis Rozporządzenie Rozporządzenie Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (Dz. U. nr 128 poz. 1094 ze zm.). Subskrybent Ustawa zaświadczenie certyfikacyjne Organ administracji publicznej, korzystający z usług certyfikacyjnych na podstawie otrzymanego od Gestora zaświadczenia certyfikacyjnego, zgodnie z postanowieniami Polityki Certyfikacji. Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (tekst jednolity Dz. U. z 2013 r. Poz. 262 z późn. zm.). elektroniczne zaświadczenie, za pomocą którego dane służące do weryfikacji poświadczenia elektronicznego są przyporządkowane do podsystemu certyfikacji CC i które umożliwiają identyfikację CC oraz podsystemu. Strona 6 z 42

2. Wstęp 2.1. Wprowadzenie Polityki Certyfikacji stanowią zbiór zasad określających warunki świadczenia usług certyfikacyjnych przez urzędy certyfikacji. Niniejszy dokument stanowi Politykę Certyfikacji dla usług wydawania i zarządzania zaświadczeniami certyfikacyjnymi. Usługi te realizowane są przez główny urząd certyfikacji na potrzeby pośrednich urzędów certyfikacyjnych obsługujących systemy administracji publicznej w Polsce. W związku z tym, że dokument zawiera również uregulowania szczegółowe w zakresie objętym Polityką Certyfikacji, pełni on jednocześnie rolę regulaminu certyfikacji. Podczas tworzenia dokumentu wykorzystano zalecenia zawarte w RFC 3647 "Internet X.509 Public Key Infrastructure Certification Policy and Certification Practices Framework". 2.2. Identyfikator Polityki Certyfikacji Nazwa polityki Polityka Certyfikacji dla Głównego Urzędu Certyfikacji Administracji Publicznej (Root CA) Wersja polityki 1.1 Numer OID (ang. Object Identifier) {joint-iso-itu-t(2) ds(5) ce(29) certificatepolicies(32) anypolicy(0)} Data wydania 2013-11-27 Strona 7 z 42

2.3. Opis systemu certyfikacji i uczestniczących w nim podmiotów Niniejsza Polityka Certyfikacji realizowana jest przez Centrum Certyfikacji (CC), działające w strukturach organizacyjnych Ministerstwa właściwego do spraw wewnętrznych (zwanego dalej Ministerstwem). CC realizuje szereg Polityk Certyfikacji, poprzez powołane w jego ramach tzw. podsystemy certyfikacji. Ogół podsystemów certyfikacji zdefiniowanych w CC określany jest mianem systemu certyfikacji. Każdy podsystem certyfikacji posługuje się własnymi kluczami służącymi do podpisywania certyfikatów (lub zaświadczeń certyfikacyjnych) i list unieważnionych certyfikatów oraz własnym identyfikatorem wyróżniającym wystawcy certyfikatów. W ramach każdego podsystemu certyfikacji obowiązują określone dla realizowanej Polityki (lub Polityk) Certyfikacji procedury i zasady oraz profile nazw i certyfikatów. Subskrybenci zainteresowani uzyskaniem zaświadczeń certyfikacyjnych w ramach Polityki Certyfikacji powinni kontaktować się z CC za pośrednictwem CPR, którego dane kontaktowe podane są poniżej w punkcie 2.5.1. CPR prowadzi obsługę Subskrybentów w zakresie przyjmowania zgłoszeń certyfikacyjnych oraz zgłoszeń unieważnienia zaświadczeń certyfikacyjnych, wprowadzania do systemu informatycznego CC zleceń wystawienia oraz unieważnienia zaświadczenia certyfikacyjnego. PR rejestruje Subskrybentów, uwierzytelnia Subskrybentów, przyjmuje nadsyłane przez nich zgłoszenia, a także przekazuje Subskrybentom wytworzone zaświadczenia certyfikacyjne. PR stanowi również punkt kontaktowy dla wszelkich zapytań związanych z działaniem urzędu Root CA. Subskrybentami w ramach Polityki Certyfikacji mogą być wyłącznie instytucje administracji publicznej w Polsce, po otrzymaniu zgody Gestora. Sposób realizacji zabezpieczeń po stronie Subskrybenta nie jest przez niniejszą Politykę Certyfikacji określony, za wyjątkiem wymagania, aby wszystkie klucze prywatne były generowane, przechowywane i przetwarzane w nośnikach kluczy kryptograficznych lub urządzeniach spełniających techniczne wymagania dla komponentów technicznych, określone w Ustawie. Strona 8 z 42

2.4. Użycie certyfikatów W ramach niniejszej Polityki Certyfikacji generowane są zaświadczenia certyfikacyjne Subskrybentów, pełniących rolę punktów zaufania dla wydawanych przez nich certyfikatów. Ponadto, w ramach podsystemu certyfikacji Root CA, realizującego niniejszą Politykę Certyfikacji, generowany jest autocertyfikat, tj. samopodpisane zaświadczenie certyfikacyjne, jak również zakładkowe zaświadczenie certyfikacyjne. 2.4.1 Niedozwolone użycie certyfikatów Użycie zaświadczeń certyfikacyjnych opisane jest w profilu za pomocą rozszerzenia o nazwie KeyUsage oraz Extended KeyUsage. Jakiekolwiek użycie zaświadczeń certyfikacyjnych niezgodne z ich specyfikacją techniczną stanowi naruszenie zasad opisanych w Polityce Certyfikacji. W przypadku użycia zaświadczenia certyfikacyjnego poza zakresem Polityki Certyfikacji, Subskrybent ponosi całkowitą odpowiedzialność za skutki tego użycia w stosunku do osób trzecich, które polegały na zawartości zaświadczenia certyfikacyjnego lub zweryfikowały na tej podstawie jeden lub więcej podpisów cyfrowych. 2.4.2 Rozszerzenia certyfikatów CC używa krytycznych i niekrytycznych rozszerzeń wydawanych przez siebie zaświadczeń certyfikacyjnych. W zaświadczeniach certyfikacyjnych wydawanych przez CC zostały umieszczone następujące rozszerzenia krytyczne: 1) basicconstraint odróżnia certyfikaty urzędów certyfikacji od certyfikatów użytkowników końcowych; 2) keyusage ogranicza zastosowania pary kluczy, w której dla klucza publicznego zostało wydane zaświadczenie certyfikacyjne, do celów wskazanych w Polityce Certyfikacji. Strona 9 z 42

2.5. Zasady administrowania Polityką Certyfikacji Podsystem certyfikacji Root CA realizujący, Politykę Certyfikacji, jest elementem CC działającego pod kontrolą Gestora. Wszelkie zmiany w Polityce Certyfikacji, z wyjątkiem zmian, które poprawiają oczywiste błędy redakcyjne oraz zmian teleadresowych punktu kontaktowego, wymagają zatwierdzenia decyzją Gestora. Obowiązująca wersja Polityki Certyfikacji jest dostępna w repozytorium, opisanym w rozdziale 3. O ile Gestor nie postanowi inaczej, wszystkie zaświadczenia certyfikacyjne wystawione w okresie obowiązywania wcześniejszej wersji polityki certyfikacji i nadal ważne w chwili zatwierdzenia nowej wersji, zachowują swoją ważność i podlegają postanowieniom tej wersji Polityki Certyfikacji, zgodnie z którą zostały wystawione. 2.5.1 Punkty kontaktowe Punktem kontaktowym dla obsługi wszelkich spraw związanych z realizacją Polityki Certyfikacji przez CC jest CPR: Centralny Punkt Rejestracji Departament Strategii i Analiz (DSiA) Ministerstwo Spraw Wewnętrznych 02-106 Warszawa ul. Adolfa Pawińskiego 17/21 Telefony kontaktowe (od poniedziałku do piątku w godz. 8:15-16:15): (022) 60 28 410, (022) 60 28 411 Fax (czynny całą dobę przez wszystkie dni tygodnia): (022) 60 28 001 Strona 10 z 42

3. Zasady dystrybucji i publikacji informacji W ramach CC działa repozytorium zaświadczeń certyfikacyjnych oraz list ARL. Jest ono dostępne za pośrednictwem protokołu LDAP (serwer LDAP) i protokołu HTTP (serwer WWW). CC zapewnia dystrybucję wystawionych zaświadczeń certyfikatów i list unieważnionych zaświadczeń w następujący sposób: 1) zaświadczenia certyfikacyjne publikowane są na serwerze LDAP; 2) listy ARL publikowane są na serwerze LDAP oraz na serwerze WWW. Zaświadczenia certyfikacyjne publikowane są niezwłocznie po ich wystawieniu, nie później jednak niż w ciągu 72 godzin od momentu wystawienia. Listy ARL publikowane są niezwłocznie po ich wygenerowaniu, nie później jednak niż w ciągu 1 godziny od tego momentu wytworzenia. Listy ARL generowane są w odstępach nie dłuższych niż co 365 dni. Najpóźniejszy moment wygenerowania następnej planowanej listy ARL, zapisany jest w jej strukturze w polu nextupdate. Każdorazowe unieważnienie zaświadczenia certyfikacyjnego skutkuje niezwłocznym wygenerowaniem i publikacją listy ARL. Treść wszystkich kolejnych wersji Polityk Certyfikacji publikowana jest w repozytorium. Każda nowa wersja polityki certyfikacji umieszczana jest na serwerze niezwłocznie po jej zatwierdzeniu przez Gestora. W repozytorium umieszczane są również informacje o wszystkich wydanych zaświadczeniach oraz lista Subskrybentów, dla których zostały wydane zaświadczenia. Szczegółowych informacji dla Subskrybentów o adresach i zasadach dostępu do repozytorium udziela CPR. Strona 11 z 42

4. Identyfikacja i uwierzytelnienie Niniejszy rozdział opisuje zasady identyfikacji i uwierzytelnienia Subskrybentów. 4.1. Struktura nazw Subskrybentów Subskrybenci identyfikowani są w certyfikatach przy użyciu identyfikatorów wyróżniających (Distinguished Names) zgodnie ze standardami X.500. Budowa identyfikatora wyróżniającego Subskrybenta nie jest określana przez Politykę Certyfikacji, jednakże zalecane jest określenie: Kraj (countryname) C = PL Organizacja (organizationname) O = <nazwa organizacji> Nazwa powszechna (commonname) CN = <unikalna nazwa wyróżniająca Subskrybenta> Każdy Subskrybent posiada identyfikator wyróżniający inny niż identyfikatory wyróżniające pozostałych Subskrybentów. 4.2. Rejestracja i uwierzytelnienie Subskrybentów 4.2.1 Sposoby uwierzytelnienia Subskrybentów przy początkowej rejestracji i wystawianiu pierwszego zaświadczenia certyfikacyjnego Rejestracja Subskrybentów oraz wygenerowanie im zaświadczeń certyfikacyjnych odbywa się na podstawie pisemnego zapotrzebowania na zaświadczenie certyfikacyjne (tzw. wniosek certyfikacyjny), podpisanego przez osoby upoważnione do reprezentowania podmiotu starającego się o wystawienie certyfikatów dla Subskrybenta. Wniosek certyfikacyjny powinien być kontrasygnowany przez Gestora po sprawdzeniu prawidłowości reprezentacji podmiotu wnioskującego. Uwierzytelnienie osoby uprawnionej do odbioru zaświadczenia lub dostarczenia zgłoszeń certyfikacyjnych przed wydaniem zaświadczenia lub zaakceptowaniem zgłoszeń, jest wykonywane przez personel CPR i polega na kontroli dokumentu tożsamości i sprawdzeniu zgodności danych identyfikacyjnych tej osoby z danymi zawartymi we wniosku certyfikacyjnym. Strona 12 z 42

4.3. Sposoby uwierzytelnienia Subskrybenta przy wystawianiu kolejnych zaświadczeń certyfikacyjnych Wystawienie Subskrybentowi kolejnego zaświadczenia certyfikacyjnego, odbywa się według tych samych reguł co wystawienie pierwszego zaświadczenia. Nie dopuszcza się możliwości wymiany wielu zaświadczeń certyfikacyjnych w oparciu o jeden wniosek certyfikacyjny. W celu zachowania ciągłości pracy Subskrybent powinien wystąpić o wymianę zaświadczenia certyfikacyjnego w okresie ważności zaświadczenia dotychczasowego, z odpowiednim wyprzedzeniem, nie mniejszym niż 14 dni i nie większym niż 28 dni. 4.4. Sposoby uwierzytelnienia Subskrybenta przy zgłaszaniu żądania unieważnienia zaświadczeń Uprawnionym do unieważnienia zaświadczenia certyfikacyjnego jest zarówno Subskrybent jak i osoby uprawnione do reprezentowania podmiotu wnioskującego o wydanie certyfikatów dla Subskrybenta, wskazane we wniosku certyfikacyjnym. Unieważnienie zaświadczenia certyfikacyjnego jest przeprowadzane na podstawie oryginału żądania unieważnienia. Nie przewiduje się zawieszania zaświadczeń certyfikacyjnych. Żądanie unieważnienia zaświadczenia certyfikacyjnego musi zawierać co najmniej: 1) identyfikator wyróżniający Subskrybenta; 2) numer seryjny zaświadczenia certyfikacyjnego. Strona 13 z 42

5. Cykl życia zaświadczenia certyfikacyjnego wymagania operacyjne 5.1. Wniosek o wydanie zaświadczenia Każde zaświadczenie certyfikacyjne wystawiane jest w ramach Polityki Certyfikacji w oparciu o tzw. wniosek certyfikacyjny. Wniosek certyfikacyjny powinien zawierać co najmniej następujące dane: 1) nazwa polityki certyfikacji, której dotyczy wniosek; 2) data wypełnienia wniosku; 3) pełna nazwa wnioskującego podmiotu Subskrybenta; 4) adres podmiotu; 5) imię (lub imiona) i nazwisko, seria i numer dokumentu tożsamości osoby upoważnionej do reprezentowania Subskrybenta, stanowisko służbowe; 6) imię (imiona), nazwisko, seria i numer dokumentu tożsamości i stanowisko służbowe osoby (lub osób) upoważnionej do odbioru zaświadczeń certyfikacyjnych w imieniu Subskrybenta jeśli jest to inna osoba niż wymieniona w punkcie powyżej; 7) imię (imiona), nazwisko, seria i numer dokumentu tożsamości i stanowisko służbowe osoby (lub osób) upoważnionych do zgłaszania wniosków o unieważnienie zaświadczeń certyfikacyjnych w imieniu Subskrybenta jeśli jest to inna osoba niż wymieniona w punkcie powyżej. Wniosek certyfikacyjny musi być podpisany przez osobę upoważnioną do reprezentowania Subskrybenta. Wniosek certyfikacyjny powinien być przesłany do Gestora za pisemnym potwierdzeniem odbioru lub złożony osobiście przez osobę upoważnioną wymienioną we wniosku. Strona 14 z 42

5.2. Przetwarzanie wniosków i zgłoszeń certyfikacyjnych Wniosek certyfikacyjny wraz ze zgłoszeniem certyfikacyjnym przekazywany jest do zatwierdzenia (kontrasygnowania) Gestorowi. Wniosek może zostać odrzucony w następujących przypadkach: 1) podmiot nie spełnia wymagań Polityki Certyfikacji; 2) podmiot nie jest uprawniony do wnioskowania o zaświadczenie certyfikacyjne; 3) wniosek nie zawiera wszystkich wymaganych informacji lub zawiera niepoprawne lub nieprawdziwe dane; 4) wniosek nie jest podpisany przez osobę upoważnioną; 5) istnieją inne, uzasadnione przesłanki do odrzucenia wniosku. Informacja o odrzuceniu wniosku jest przekazywana Subskrybentowi wraz z pisemnym uzasadnieniem. Zatwierdzony (kontrasygnowany) przez Gestora wniosek certyfikacyjny przekazywany jest wraz ze zgłoszeniem certyfikacyjnym do PR. Zatwierdzenie lub odrzucenie wniosku certyfikacyjnego powinno nastąpić w ciągu 14 dni od daty wpływu wniosku do CPR. CPR przyjmuje zgłoszenia certyfikacyjne w formacie PKCS#10. Zgłoszenia certyfikacyjne powinny być dostarczone na nośniku danych (płyta CD, DVD, pamięć przenośna ze złączem USB). Po otrzymaniu zgłoszeń, CPR podejmuje w stosunku do każdego zgłoszenia następujące czynności: 1) jeżeli Subskrybent nie jest jeszcze zarejestrowany w systemie certyfikacji, jest on rejestrowany na podstawie danych zawartych we wniosku certyfikacyjnym; 2) zgłoszenie certyfikacyjne jest weryfikowane pod kątem integralności i składni oraz zgodności z danymi we wniosku certyfikacyjnym; 3) zgłoszenie certyfikacyjne przekazywane jest do realizacji. Strona 15 z 42

5.3. Wystawienie zaświadczenia Zaświadczenie certyfikacyjne wystawiane jest na podstawie zgłoszenia certyfikacyjnego. Po wytworzeniu w CC, zaświadczenie dostarczane jest do CPR, gdzie nagrywane jest na nośnik danych. Nośnik z zaświadczeniem jest następnie przesyłany na adres wskazany we wniosku albo wydawany Subskrybentowi lub osobie przez niego upoważnionej. Wytworzone i wydane zaświadczenia certyfikacyjne są również publikowane w repozytorium opisanym w rozdziale 3. 5.4. Akceptacja zaświadczenia certyfikacyjnego Subskrybent zobowiązany jest do sprawdzenia poprawności danych zawartych w zaświadczeniu certyfikacyjnym. W razie stwierdzenia nieprawidłowości w treści wydanego zaświadczenia certyfikacyjnego, Subskrybent zobowiązany jest niezwłocznie zawiadomić o tym fakcie CPR. Informacja musi być złożona na piśmie nie później niż w terminie 7 dni od daty wydania zaświadczenia certyfikacyjnego. W przypadku opisanym powyżej, CPR publikuje informację o unieważnieniu tego zaświadczenia. W przypadku braku informacji w w/w terminie zaświadczenie certyfikacyjne uważa się za zaakceptowane. 5.5. Korzystanie z pary kluczy i zaświadczenia certyfikacyjnego Użycie zaświadczeń certyfikacyjnych i kluczy w zastosowaniach zgodnych z Polityką Certyfikacji oznacza przyjęcie przez Subskrybenta określonych praw i obowiązków. Strona 16 z 42

5.5.1 Obowiązki Subskrybenta Subskrybent akceptując zaświadczenie certyfikacyjne ma obowiązek: 1) zapoznania się z zasadami używania zaświadczeń certyfikacyjnych i działania infrastruktury klucza publicznego; 2) zapoznania się i zaakceptowania warunków użycia zaświadczeń certyfikacyjnych opisanych w Polityce Certyfikacji; 3) niedokonywania modyfikacji zaświadczenia certyfikacyjnego wydanego przez CC; 4) używania zaświadczenia certyfikacyjnego wydanego przez CC zgodnie z postanowieniami Polityki Certyfikacji i do celów zgodnych z prawem i jego przeznaczeniem; 5) ochrony klucza prywatnego odpowiadającego kluczowi publicznemu zawartemu w zaświadczeniu certyfikacyjnym przed utratą, kradzieżą, modyfikacją, ujawnieniem lub innym nieuprawnionym jego użyciem; 6) niezwłocznego złożenia wniosku o unieważnienie zaświadczenia certyfikacyjnego w przypadku istotnego zagrożenia jego integralności lub kontroli nad nim; 7) niezwłocznego powiadomienia CC o wszelkich zmianach w informacjach podanych w zaświadczeniu certyfikacyjnym; 8) zaprzestania używania zaświadczenia certyfikacyjnego w przypadku, gdy jakakolwiek podana w nim informacja stała się myląca lub nieaktualna. 5.6. Wymiana zaświadczenia certyfikacyjnego Wystawienie nowego zaświadczenia certyfikacyjnego dla klucza publicznego urzędu Subskrybenta, dla którego istnieje już ważne zaświadczenie, wystawione w ramach Polityki Certyfikacji, odbywa się według procedur określonych w rozdziałach 5.1-5.4. Nie dopuszcza się wydania kolejnego zaświadczenia certyfikacyjnego dla pary kluczy, dla której poprzednio wystawione zaświadczenie zostało unieważnione, niezależnie od przyczyny unieważnienia. Subskrybent zobowiązany jest do zapewnienia, iż w kolejnych nadsyłanych przez niego zgłoszeniach certyfikacyjnych nie wystąpi już klucz publiczny urzędu, którego certyfikat wystawiony w ramach Polityki Certyfikacji został unieważniony. Strona 17 z 42

5.7. Wydanie zaświadczenia certyfikacyjnego dla tej samej pary kluczy Nie przewiduje się wystawiania zaświadczenia certyfikacyjnego dla tej samej pary kluczy. Wystawienie nowego zaświadczenia certyfikacyjnego dla nowej pary kluczy odbywa się według procedur określonych w rozdziałach 5.1-5.4. 5.8. Modyfikacja zaświadczenia certyfikacyjnego Zmiana danych zawartych w zaświadczeniu certyfikacyjnym wymaga unieważnienia dotychczasowego zaświadczenia i wystawienia kolejnego, zawierającego nową treść. Wystawienie nowego zaświadczenia odbywa się według procedur określonych w rozdziałach 5.1-5.4. 5.9. Unieważnienie i zawieszenie zaświadczenia certyfikacyjnego Zawieszanie zaświadczeń certyfikacyjnych nie jest możliwe. Zaświadczenie certyfikacyjne może być unieważnione jeżeli: 1) nastąpiła utrata, kradzież, modyfikacja, nieuprawnione ujawnienie lub w inny sposób naruszono bezpieczeństwo klucza prywatnego należącego do Subskrybenta; 2) Subskrybent naruszył zobowiązania wynikające z Polityki Certyfikacji; 3) wypełnienie zobowiązań wynikających z Polityki Certyfikacji zostało opóźnione lub stało się niemożliwe w wyniku działania siły wyższej, co spowodowało, że bezpieczeństwo informacji zostało naruszone lub powstała groźba jego naruszenia; 4) informacje zawarte w certyfikacie zdezaktualizowały się; 5) zachodzą okoliczności przewidziane przepisami prawa; 6) zmianie ulegnie Polityka Certyfikacji i konieczne jest zaprzestanie używania dotychczasowych zaświadczeń certyfikacyjnych ze względu na sprzeczność z postanowieniami nowej Polityki. O unieważnienie zaświadczenia certyfikacyjnego może wystąpić: 1) Subskrybent lub osoba przez niego upoważniona; 2) Gestor. Strona 18 z 42

Za skutki użycia zaświadczenia certyfikacyjnego, do czasu wystawienia przez CC pierwszej listy ARL zawierającej informację o unieważnieniu tego certyfikatu, odpowiada Subskrybent. Nowa lista ARL publikowana jest w ciągu 1 godziny od momentu przyjęcia przez CPR zgłoszenia żądania unieważnienia, przy czym żądania unieważnienia zaświadczenia certyfikatu przyjmowane są w dni robocze w godzinach od 08:15 do 16:15. Listy ARL publikowane są z częstotliwością określoną w rozdziale 3. 5.10. Sprawdzanie statusu certyfikatu Informacja o statusie certyfikatu (czy jest on ważny czy unieważniony) udostępniana jest poprzez publikację list ARL w repozytorium (opisanym w rozdziale 3). 5.11. Zakończenie subskrypcji Subskrypcja w rozumieniu Polityki Certyfikacji wygasa wraz z upływem terminu ważności zaświadczenia certyfikacyjnego lub jego unieważnieniem. 5.12. Odtwarzanie lub odzyskiwanie kluczy CC przechowuje kopie klucza prywatnego podsystemu Root CA w celu zapewnienia ciągłości działania. Zabezpieczenie urządzenia służącego do przechowywania kopii zapasowych klucza prywatnego opisane jest w Rozdziale 7.2. Strona 19 z 42

6. Zabezpieczenia organizacyjne, operacyjne i fizyczne CC Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. W niniejszym rozdziale zawarto jedynie niektóre aspekty dotyczące zabezpieczeń organizacyjnych, operacyjnych i fizycznych. 6.1. Zabezpieczenia fizyczne Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. 6.2. Zabezpieczenia proceduralne Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. 6.3. Zabezpieczenia osobowe Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. 6.4. Procedury rejestrowania zdarzeń Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. 6.5. Archiwizacja zapisów Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. Strona 20 z 42

6.6. Wymiana pary kluczy podsystemu certyfikacji Root CA Wymiana pary kluczy podsystemu certyfikacji Root CA może następować w planowych terminach (przed upływem ważności dotychczasowego zaświadczenia certyfikacyjnego) lub w przypadku wykrycia zwiększonego ryzyka utraty klucza prywatnego (np. na skutek uszkodzenia niektórych nośników klucza prywatnego przechowujących dane niezbędne do odtworzenia klucza prywatnego w stosowanym schemacie podziału sekretu). Nie dopuszcza się wystawiania nowych samopodpisanych zaświadczeń certyfikacyjnych dla dotychczasowej pary kluczy podsystemu certyfikacji Root CA. Wymiana pary kluczy podsystemu certyfikacji Root CA powinna nastąpić w terminie wynikającym z okresu zakładkowego, określonego w rozdziale 7.3.2. Postępowanie w przypadku wymiany pary kluczy podsystemu certyfikacji Root CA jest następujące: 1) generowana jest nowa para kluczy i zaświadczenie certyfikacyjne oraz nowa lista ARL. 2) nowe samopodpisane zaświadczenia certyfikacyjne instalowane są jako tzw. punkty zaufania w tych modułach, które tego wymagają, w taki sposób, aby akceptowane były również zaświadczenia certyfikacyjne Subskrybentów poświadczone poprzednim kluczem prywatnym podsystemu Root CA (oznacza to, że moduły powinny traktować oba samopodpisane zaświadczenia certyfikacyjne dotychczasowe i nowe jako punkty zaufania lub, że moduły powinny traktować tylko nowe samopodpisane zaświadczenie certyfikacyjne jako punkt zaufania i posiadać dostęp do zakładkowego zaświadczenia certyfikacyjnego, zawierającego dotychczasowy klucz publiczny Root CA, poświadczony nowym kluczem prywatnym podsystemu. 3) CPR udostępnia Subskrybentom nowe samopodpisane zaświadczenia certyfikacyjne lub odpowiednie zakładkowe zaświadczenia certyfikacyjne w sposób zapewniający autentyczność dostarczonych zaświadczeń. Strona 21 z 42

6.7. Postępowanie po ujawnieniu lub utracie klucza prywatnego podsystemu certyfikacji Root CA Przez ujawnienie klucza prywatnego podsystemu certyfikacji Root CA należy rozumieć sytuację, w której nieuprawniona osoba uzyskała możliwość wykorzystywania tego klucza. Procedury obowiązujące przy ujawnieniu klucza należy zastosować również wtedy, gdy istnieje uzasadnione podejrzenie ujawnienia klucza. W przypadku zaistnienia sytuacji, w której nastąpiło naruszenie lub podejrzenie naruszenia poufności, integralności bądź dostępności klucza prywatnego podsystemu certyfikacji, należy podjąć czynności mające na celu: 1) identyfikację okoliczności i osób mających wpływ na zaistnienie nieprawidłowości; 2) zebranie materiału dowodowego; 3) wyciągnięcie wniosków, przedstawienie i realizację zaleceń minimalizujących możliwość zaistnienia podobnych sytuacji w przyszłości; 4) pociągnięcie osób odpowiedzialnych do odpowiedzialności dyscyplinarnej i/lub karnej. 6.7.1 Postępowanie po ujawnieniu klucza prywatnego podsystemu certyfikacji Root CA Wykrycie ujawnienia klucza prywatnego podsystemu certyfikacji Root CA lub uzasadnione podejrzenie takiego ujawnienia powoduje niezwłoczne podjęcie następujących działań: 1) Gestor zawiadamia o zaistniałej sytuacji wszystkich Subskrybentów. Subskrybenci podejmują procedury dotyczące postępowania po kompromitacji klucza prywatnego podsystemu; 2) CC unieważnia wszystkie ważne certyfikaty oraz zaświadczenia certyfikacyjne, w tym samopodpisane zaświadczenia certyfikacyjne; 3) CC generuje nową parę kluczy, nowe zaświadczenia certyfikacyjne, nową listę ARL oraz certyfikaty Inspektorów ds. Rejestracji i certyfikaty kluczy infrastruktury; 4) CPR, działając w uzgodnieniu z Subskrybentami, na podstawie posiadanych wniosków certyfikacyjnych, generuje nowe zaświadczenia certyfikacyjne zastępujące wszystkie dotychczas wystawione zaświadczenia. Jeżeli konieczne jest wygenerowanie nowych par kluczy, wówczas wymagane jest przeprowadzenie standardowego postępowania określonego w rozdziałach 5.1-5.4; Strona 22 z 42

5) CPR dostarcza nowe zaświadczenia certyfikacyjne w sposób uzgodniony z Subskrybentem, zapewniając autentyczność dostarczonych zaświadczeń certyfikacyjnych; 6) nowe samopodpisane zaświadczenia certyfikacyjne instalowane są jako tzw. punkty zaufania w tych modułach, które tego wymagają; 7) zaświadczenia certyfikacyjne związane z ujawnionym kluczem powinny być usunięte z systemów, w których stanowią tzw. punkty zaufania; 8) dotychczasowy (ujawniony) klucz prywatny jest niszczony (sposób niszczenia jest określony w procedurach operacyjnych). Jeśli baza danych podsystemu jest wiarygodna pomimo ujawnienia klucza, decyzją Gestora, nowe certyfikaty można wygenerować w oparciu o certyfikaty znajdujące się w tej bazie danych bez powtórnego analizowania wniosków certyfikacyjnych. 6.7.2 Postępowanie po zniszczeniu klucza prywatnego podsystemu certyfikacji Root CA Utrata dostępności klucza prywatnego podsystemu certyfikacji, związana z bezpowrotnym zniszczeniem klucza prywatnego podsystemu certyfikacji, w przypadku braku podejrzeń dotyczących jego ujawnienia, powoduje niezwłoczne podjęcie następujących działań mających na celu zapewnienie ciągłości działania: 1) CC generuje nową parę kluczy, nowe zaświadczenia certyfikacyjne, nową listę ARL oraz certyfikaty Inspektorów ds. Rejestracji i certyfikaty kluczy infrastruktury; 2) nowe samopodpisane zaświadczenia certyfikacyjne instalowane są jako tzw. punkty zaufania w tych modułach, które tego wymagają, w taki sposób, aby akceptowane były również zaświadczenia certyfikacyjne Subskrybentów poświadczone poprzednim, utraconym kluczem prywatnym podsystemu (oznacza to, że moduły powinny traktować oba samopodpisane zaświadczenia certyfikacyjne dotychczasowe i nowe jako punkty zaufania lub, że moduły powinny traktować tylko nowe samopodpisane zaświadczenie certyfikacyjne jako punkt zaufania i posiadać dostęp do zakładkowego zaświadczenia certyfikacyjnego, zawierającego dotychczasowy klucz publiczny podsystemu Root CA poświadczony nowym kluczem prywatnym podsystemu; 3) CPR dostarcza Subskrybentom nowe samopodpisane zaświadczenia certyfikacyjne i odpowiednie zakładkowe zaświadczenia certyfikacyjne w sposób zapewniający autentyczność dostarczonych zaświadczeń certyfikacyjnych. Strona 23 z 42

6.7.3 Postępowanie po jednoczesnym ujawnieniu i utracie klucza prywatnego podsystemu certyfikacji Root CA Wykrycie jednoczesnego ujawnienia (lub uzasadnionego podejrzenia ujawnienia) i utraty klucza prywatnego podsystemu certyfikacji Root CA powoduje niezwłoczne podjęcie następujących działań: 1) Gestor zawiadamia o zaistniałej sytuacji wszystkich Subskrybentów. Subskrybenci podejmują procedury dotyczące postępowania po kompromitacji klucza prywatnego podsystemu; 2) CC unieważnia zaświadczenia certyfikacyjne podpisane skompromitowanym kluczem prywatnym, w tym samopodpisane zaświadczenia certyfikacyjne, generuje nową parę kluczy, nowe zaświadczenia certyfikacyjne, nową listę ARL oraz certyfikaty Inspektorów ds. Rejestracji i certyfikaty kluczy infrastruktury; 3) nowe samopodpisane zaświadczenia certyfikacyjne instalowane są jako tzw. punkty zaufania w tych modułach, które tego wymagają; 4) CPR, działając w uzgodnieniu z Subskrybentami, na podstawie posiadanych wniosków certyfikacyjnych, generuje nowe zaświadczenia certyfikacyjne, zastępujące wszystkie dotychczas wystawione zaświadczenia; jeżeli konieczne jest wygenerowanie nowych par kluczy, wówczas wymagane jest przeprowadzenie standardowego postępowania określonego w rozdziałach 5.1-5.4; 5) CPR dostarcza nowe zaświadczenia certyfikacyjne i samopodpisane zaświadczenia certyfikacyjne w sposób uzgodniony z Subskrybentem, zapewniający autentyczność dostarczonych zaświadczeń certyfikacyjnych. Jeśli baza danych podsystemu jest wiarygodna pomimo ujawnienia klucza, decyzją Gestora, nowe certyfikaty można wygenerować w oparciu o certyfikaty znajdujące się w tej bazie danych bez powtórnego analizowania wniosków certyfikacyjnych. Strona 24 z 42

6.8. Zakończenie działalności podsystemu certyfikacji Root CA Decyzję o zakończeniu działalności podsystemu certyfikacji podejmuje Gestor, uwzględniając wszystkie zawarte umowy i porozumienia. W przypadku zakończenia działalności podsystemu, CC podejmie następujące działania: 1) poinformuje Subskrybentów posiadających ważne zaświadczenia certyfikacyjne o zamiarze zakończenia działalności podsystemu z co najmniej 3-miesięcznym wyprzedzeniem; 2) w ostatnim dniu 3-miesięcznego okresu powiadomienia unieważni wszystkie certyfikaty nawet, jeżeli Subskrybenci nie wyrazili zgody na ich unieważnienie; 3) zorganizuje z należytą starannością warunki zabezpieczenia dokumentacji, zgodnie z postanowieniami Polityki Certyfikacji. Strona 25 z 42

7. Zabezpieczenia techniczne CC Zabezpieczenia stosowane przez CC określone są w dokumentacji bezpieczeństwa. W niniejszym rozdziale zawarto jedynie niektóre aspekty dotyczące zabezpieczeń technicznych. 7.1. Generowanie i instalowanie par kluczy 7.1.1 Generowanie par kluczy Pary kluczy podsystemu certyfikacji Root CA i Inspektorów ds. Rejestracji generowane są przez personel CC, zgodnie z procedurami operacyjnymi CC. Generowanie par kluczy odbywa się w bezpiecznym urządzeniu kryptograficznym HSM. 7.1.2 Dostarczenie klucza prywatnego Subskrybentowi Nie dotyczy. 7.1.3 Dostarczenie klucza publicznego Subskrybenta do CPR Klucz publiczny Subskrybenta jest dostarczany do CPR w formie zgłoszenia certyfikacyjnego na nośniku danych. Tożsamość osoby dostarczającej klucz jest weryfikowana. Klucz powinien być zapisany w pliku w formacie zgłoszenia certyfikacyjnego PKCS#10. Zgłoszenie powinno zawierać identyfikator DN, który zostanie umieszczony w zaświadczeniu certyfikacyjnym. Identyfikator DN musi posiadać budowę zgodną z Polityką Certyfikacji. Strona 26 z 42

7.1.4 Dostarczenie klucza publicznego podsystemu certyfikacji Root CA Klucz publiczny podsystemu certyfikacji Root CA jest dostarczany Subskrybentom w postaci samopodpisanych zaświadczeń certyfikacyjnych, opatrzonych pieczęcią Gestora, na opisanych nośnikach danych. 7.1.5 Rozmiary kluczy Klucze podsystemów certyfikacji Root CA i Policy CA mają długość nie mniejszą niż: 1) w przypadku generowania kluczy algorytmem RSA 4096 bitów; 2) w przypadku generowania kluczy algorytmem ECDSA 256 bitów. 7.1.6 Cel użycia klucza Pole rozszerzenia keyusage w certyfikatach zgodnych z Zaleceniem X.509:2000 określa zastosowanie (jedno lub kilka) klucza publicznego zawartego w certyfikacie. Klucz prywatny Root CA może być wykorzystywany tylko do podpisywania zaświadczeń certyfikacyjnych i list ARL zgodnie z Polityką Certyfikacji. Odpowiadający mu klucz publiczny służy wyłącznie do weryfikowania zaświadczeń certyfikacyjnych i list ARL. Samopodpisane zaświadczenia certyfikacyjne i zakładkowe zaświadczenia certyfikacyjne mają ustawione odpowiednie wartości (crlsign i keycertsign) w polu rozszerzenia keyusage. Klucz prywatny Policy CA może być wykorzystywany tylko do podpisywania zaświadczeń certyfikacyjnych i list CRL zgodnie z Politykami Certyfikacji dla pośrednich urzędów certyfikacji. Odpowiadający mu klucz publiczny służy wyłącznie do weryfikowania zaświadczeń certyfikacyjnych i list CRL. Zaświadczenia certyfikacyjne i zakładkowe zaświadczenia certyfikacyjne mają ustawione odpowiednie wartości (crlsign i keycertsign) w polu rozszerzenia keyusage. Strona 27 z 42

7.2. Ochrona kluczy prywatnych 7.2.1 Standardy dla modułów kryptograficznych Klucze prywatne podsystemu Root CA są generowane, a następnie przechowywane w bezpiecznym urządzeniu kryptograficznym HSM, posiadającym certyfikat zgodności z wymaganiami normy FIPS 140-3 poziom 3 lub normy ISO/IEC 15408 Evaluation criteria for IT Security, poziom EAL-4, które zapewniają odpowiedni poziom bezpieczeństwa przechowywania kluczy wewnątrz urządzenia oraz przeprowadzania operacji z użyciem klucza prywatnego. 7.2.2 Wieloosobowe zarządzanie kluczem Klucze prywatne podsystemu certyfikacji Root CA są przechowywane z wykorzystaniem mechanizmu podziału sekretów w schemacie progowym stopnia (m, n), gdzie wartość m=2 i n=5. 7.2.3 Powierzenie klucza prywatnego (key-escrow) Nie występuje. 7.2.4 Kopia bezpieczeństwa klucza prywatnego Kopia bezpieczeństwa klucza prywatnego podsystemu certyfikacji Root CA wynika z realizacji podziału sekretów. Kopie bezpieczeństwa kluczy prywatnych Subskrybenta nie są tworzone przez podsystem certyfikacji Root CA. Jeśli zasada zachowania ciągłości pracy jest dla danego Subskrybenta istotna, powinien on to przewidzieć i zapewnić rezerwowe nośniki kluczy kryptograficznych i certyfikatów oraz bezpiecznie je przechowywać. 7.2.5 Archiwizowanie klucza prywatnego Nie przewiduje się archiwizowania kluczy prywatnych. Strona 28 z 42

7.2.6 Wprowadzanie klucza prywatnego do modułu kryptograficznego Klucze prywatne podsystemu certyfikacji Root CA są wprowadzane do modułu kryptograficznego przez personel CC, zgodnie z procedurami operacyjnymi. W przypadku kluczy prywatnych Inspektorów ds. Rejestracji i kluczy prywatnych infrastruktury, wprowadzanie klucza prywatnego do modułu kryptograficznego nie występuje. Nie nakłada się dodatkowych wymagań na sposób wprowadzania klucza prywatnego Subskrybenta do stosowanych przez niego modułów kryptograficznych poza tym, aby jego klucz prywatny w żadnym momencie nie opuszczał nośnika kluczy kryptograficznych. 7.2.7 Metoda aktywacji klucza prywatnego Klucz prywatny podsystemu certyfikacji jest aktywowany przez personel CC poprzez wprowadzenie na klawiaturze PIN-ów chroniących dostęp do nośników kluczy kryptograficznych, przechowujących części tego klucza prywatnego, zgodnie z procedurami operacyjnymi. Klucze prywatne Inspektorów ds. Rejestracji są aktywowane przez Inspektorów ds. Rejestracji poprzez wprowadzenie na klawiaturze PIN-ów chroniących dostęp do nośników kluczy kryptograficznych przechowujących te klucze. Polityka Certyfikacji nie nakłada wymagań na metodę aktywacji kluczy prywatnych Subskrybentów. 7.2.8 Metoda dezaktywacji klucza prywatnego Klucz prywatny podsystemu certyfikacji może zostać dezaktywowany przez personel CC poprzez usunięcie z modułu kryptograficznego nośników kluczy kryptograficznych przechowujących części tego klucza prywatnego. Klucze prywatne Inspektorów ds. Rejestracji są dezaktywowane poprzez usunięcie nośnika kluczy kryptograficznych z czytnika. Polityka Certyfikacji nie nakłada wymagań na metodę dezaktywacji kluczy prywatnych Subskrybentów. Strona 29 z 42

7.2.9 Metoda niszczenia klucza prywatnego Klucze prywatne podsystemu certyfikacji niszczone są poprzez fizyczne zniszczenie nośników kluczy kryptograficznych zawierających fragmenty tych kluczy, zgodnie z procedurami określonymi w odrębnym dokumencie. Klucze prywatne Inspektorów ds. Rejestracji są niszczone poprzez fizyczne zniszczenie nośników kluczy kryptograficznych zawierających te klucze, zgodnie z procedurami określonymi w odrębnym dokumencie. Polityka Certyfikacji nie nakłada wymagań na metodę niszczenia kluczy prywatnych Subskrybentów. 7.3. Inne aspekty zarządzania parą kluczy 7.3.1 Długoterminowa archiwizacja kluczy publicznych CC prowadzi długoterminową archiwizację kluczy publicznych podsystemu certyfikacji oraz wszystkich wystawionych przez siebie zaświadczeń certyfikacyjnych oraz list ARL. 7.3.2 Okresy ważności kluczy 1) Okres ważności pary kluczy podsystemu certyfikacji Root CA jest nie dłuższy niż 20 lat. 2) Okres ważności samopodpisanych zaświadczeń certyfikacyjnych jest nie dłuższy niż 20 lat. 3) Okres ważności zakładkowych zaświadczeń certyfikacyjnych wynosi co najwyżej 20 lat. Koniec okresu ważności zakładkowych zaświadczeń certyfikacyjnych jest równy lub wcześniejszy od końca okresu ważności poprzedniego samopodpisanego zaświadczenia certyfikacyjnego. 4) Okres ważności par kluczy Inspektorów ds. Rejestracji jest nie dłuższy niż 2 lata. 5) Okres ważności certyfikatów kluczy Inspektorów ds. Rejestracji jest nie dłuższy niż 2 lata. Strona 30 z 42

6) Okres ważności par kluczy pośrednich urzędów certyfikacji Policy CA jest nie dłuższy niż 15 lat. 7) Okres ważności zaświadczeń certyfikacyjnych Subskrybentów jest nie dłuższy niż 15 lat. Zmiany w Polityce Certyfikacji mogą powodować konieczność wymiany zaświadczenia certyfikacyjnego Subskrybenta. 7.4. Dane aktywujące W CC występują następujące dane aktywujące: 1) hasła dostępu do systemu operacyjnego; 2) hasła dostępu do programu obsługującego PKI; 3) hasła dostępu do bazy danych CC i bazy logu CC; 4) kody numeryczne (PIN) do kart kryptograficznych zawierających części klucza prywatnego podsystemu certyfikacji; 5) Kody numeryczne (PIN) do kart kryptograficznych administratorów i audytorów. W PR występują następujące dane aktywujące: 1) hasła dostępu do systemu operacyjnego; 2) kody numeryczne (PIN) do kart kryptograficznych zawierających klucze prywatne Inspektorów ds. Rejestracji. Dane aktywujące w CC i CPR są zarządzane zgodnie z procedurami umieszczonymi w odrębnych dokumentach. 7.5. Zabezpieczenia komputerów Zabezpieczenia komputerów zostały określone w dokumentach bezpieczeństwa oraz innej dokumentacji systemu posiadanej przez CC. Strona 31 z 42

7.6. Zabezpieczenia związane z cyklem życia systemu informatycznego 7.6.1 Środki przedsięwzięte dla zapewnienia bezpieczeństwa rozwoju systemu W CC przyjęto zasady dokonywania modyfikacji lub zmian w systemie teleinformatycznym. W szczególności dotyczy to testów nowych wersji oprogramowania i/lub wykorzystania do tego celu istniejących baz danych. Zasady te gwarantują nieprzerwaną pracę systemu teleinformatycznego, integralność jego zasobów oraz zachowanie poufności danych. 7.6.2 Zarządzanie bezpieczeństwem Za realizację procesów bezpieczeństwa jest odpowiedzialny personel CC. Środki bezpieczeństwa zostały określone w dokumentacji bezpieczeństwa oraz innej dokumentacji CC. 7.7. Zabezpieczenia sieci komputerowej Nie przewiduje się podłączenia podsystemu Root CA do sieci komputerowej. 7.8. Oznaczanie czasem Do oznaczania czasem certyfikatów, zaświadczeń certyfikacyjnych, list ARL oraz zapisów w logach urządzeń i oprogramowania stosuje się wskazanie bieżącego czasu, pochodzące z zegarów wbudowanych w urządzenia lub stacje robocze. Zakres niniejszego dokumentu nie obejmuje polityki wystawiania znaczników czasu. Strona 32 z 42

8. Profil zaświadczeń certyfikacyjnych i list ARL Rozdział zawiera informacje o profilu zaświadczeń certyfikacyjnych i list ARL wytwarzanych zgodnie z Polityką Certyfikacji. 8.1. Profil zaświadczeń certyfikacyjnych CC wystawia certyfikaty i zaświadczenia certyfikacyjne zgodnie z: 1) Rozporządzeniem Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (Dz. U. Nr 128, poz. 1094); 2) RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Zaświadczenia certyfikacyjne zawierają następujące pola: Pole tbscertificate signaturealgorithm Algorithm parameters signaturevalue Opis/wartość Poświadczona elektronicznie treść certyfikatu, opisana szczegółowo w rozdziale 8.1.1 Identyfikator algorytmu służącego do podpisania zaświadczenia certyfikacyjnego RSAwithSHA-256; RSAwithSHA-512; ecdsa-with-sha256 lub ecdsa-with-sha512 Null Wartość poświadczenia elektronicznego Strona 33 z 42

8.1.1 Rozszerzenia zaświadczeń certyfikacyjnych i ich krytyczność Wymagane pola podstawowe i standardowe rozszerzenia: Pole Opis (wartość) Krytyczne Version Wersja v3 (2) NIE serialnumber Unikalny numer seryjny NIE Identyfikator algorytmu służącego do podpisania zaświadczenia Signature certyfikacyjnego; wartość musi być jednakowa jak w polu signaturealgorithm, określonym w rozdziale 8.1 NIE Issuer Dane wystawcy zaświadczeń certyfikacyjnych, określone w rozdziale 8.1.2 NIE Validity Subject Okres ważności zaświadczenia certyfikacyjnego not before Początek okresu ważności zaświadczenia certyfikacyjnego, UTC NIE not after Koniec okresu ważności zaświadczenia certyfikacyjnego, UTC NIE Informacje o Subskrybencie wypełnione na podstawie unikalnego pola distinguishedname Subject public key Klucz publiczny i informacja o zastosowanym algorytmie NIE authoritykeyidentifier subiectkeyidentifier Skrót z klucza publicznego wystawcy zaświadczenia certyfikacyjnego, w przypadku autocertyfikatu pole jest pomijane Skrót z klucza publicznego zaświadczenia certyfikacyjnego Subskrybenta keyusage Dopuszczalne użycie klucza (CRLSign, keycertsign) TAK certificatepolicies Informacja o Polityce Certyfikacji policyidentifier Identyfikator - anypolicy ({2 5 29 32 0}) NIE basicconstraints Informacja o tym, czy Subskrybentem jest urząd certyfikacji ca (True) TAK CRLDistributionPoints Odnośnik do listy unieważnionych zaświadczeń certyfikacyjnych NIE NIE NIE NIE Wymagane rozszerzenia niestandardowe: brak. 8.1.2 Formaty identyfikatorów podsystemu certyfikacji Root CA Kraj (countryname) C = PL Nazwa organizacji (organizationname) O = MSWiA Nazwa powszechna (commonname) CN = Root CA MSWiA Format identyfikatorów Subskrybenta przedstawiony został w rozdziale 4.1. Strona 34 z 42

8.1.3 Identyfikatory zgodnych Polityk Certyfikacji Brak. 8.2. Profil list ARL CC wystawia listy ARL w formacie zgodnym z: 1) Rozporządzeniem Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (Dz. U. Nr 128, poz. 1094); 2) RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Listy unieważnionych zaświadczeń certyfikacyjnych zawierają następujące pola: Pole tbscertlist signaturealgorithm Algorithm parameters signaturevalue Opis/wartość Poświadczona elektronicznie lista unieważnionych zaświadczeń certyfikacyjnych, opisana szczegółowo w rozdziale 8.2.1 Identyfikator algorytmu służącego do podpisania listy ARL RSAwithSHA-256; RSAwithSHA-512; ecdsa-with-sha256 lub ecdsa-with-sha512 Null Wartość poświadczenia elektronicznego listy ARL Strona 35 z 42