Artykuły

Sprawdzenie z posiedzenia #34 komitetu ESI

Nov 26


11/26/2012 3:43 PM  RssIcon

Informacje podstawowe

Posiedzenie komitetu odbyło się w dniach 13-15 grudnia 2011. Gospodarzem posiedzenia był Universitat Politecnica de Catalunya (UPC). Posiedzenie odbyło się w Barcelonie. Instytut Maszyn Matematycznych był reprezentowany na posiedzeniu przez Daniela Wachnika.

 

Agenda posiedzenia

Posiedzenie przebiegało zgodnie z następującym planem:

1.       Przegląd statusu stałych czynności wykonywanych w ramach komitetu

2.       Prezentacja na temat Narodowego Testu Interoperacyjności Podpisu Elektronicznego

3.       Przegląd planu prac komitetu

4.       Przyjęcie raportu postępów z działalności grup standaryzacyjnych

a.       STF 425

b.      STF 426

c.       STF 427

d.      STF 428

e.      STF 412

W trakcie prezentacji przeprowadzanych przez liderów grup standaryzacyjnych podnoszono kwestie dotyczące prac standaryzacyjnych prowadzonych przez poszczególne grupy. Kwestie te były dyskutowane na bieżąco.

Przegląd stałych czynności wykonywanych w ramach komitetu

Do stałych czynności realizowanych w ramach komitetu można zaliczyć:

·         monitorowanie informacji dotyczących konieczności aktualizacji algorytmów kryptograficznych

·         status rozmów nad porozumieniami z innymi ciałami standaryzacyjnymi

·         współpraca z innymi jednostkami takimi jak przedstawicielstwa dużych projektów (PEPPOL, eCODEX, STORK)

·         rozliczenie zadań postawionych przed członkami komitetu na poprzednich posiedzeniach

Ze względu na fakt, że wymienione czynności są związane z działalnością operacyjną ETSI, a nie z działalnością standaryzacyjną, sprawozdanie nie obejmuje tych czynności.

Prezentacja na temat Narodowego Testu Interoperacyjności Podpisu Elektronicznego

Narodowy Test Interoperacyjności Podpisu Elektronicznego został przeprowadzony w Polsce w dniach 26-27 października 2011. W trakcie dwóch dni przeprowadzono sesję warsztatową i równoległą konferencje tematyczną dotyczącą interoperacyjności podpisu elektronicznego.

Przedstawicielom ETSI zostało zaprezentowanie podsumowanie testu. Prezentacja składała się z trzech głównych części:

·         informacje na temat testu (patronat, zakres, środowisko testowe)

·         wyniki testu (prezentacja przykładowych wyników, przykładowej macierzy interoperacyjności)

·         wnioski.

Dokładne informacje na temat testu i raport zawierający wyniki testów warsztatowych jest dostępny pod adresem http://www.commonsign.eu.

W ramach wniosków przekazano sugestię utworzenia bibliotek programistycznych, albo aplikacji referencyjnej dla zaawansowanego podpisu elektronicznego.

Pozostałe wnioski miały charakter techniczny:

·         potrzeba utworzenia profili certyfikatu dla urzędów CA

·         potrzeba dodatkowych wskazówek dotyczących przetwarzania list TSL.

Prezentacja spotkała się z zainteresowaniem ze strony ETSI. Dyskusja w dużej mierze dotyczyła pomysłu utworzenia bibliotek programistycznych (SDK) dla podpisu zaawansowanego. Pomysł nie został zaakceptowany, ze względu na fakt, iż propozycja tego rodzaju (dotycząca aplikacji referencyjnej) była przedstawiana Komisji Europejskiej, ale nie spotkała się ona z szerszym odzewem.

 

Przegląd planu prac komitetu

Przegląd planu prac wykazał, że większość prac jest prowadzona zgodnie z harmonogramem i nie ma zagrożeń związanych z opóźnieniami prac i rozliczeniami z Komisją Europejską odnośnie produktów tworzonych w ramach mandatu m460.

 

Raport z postępów prac grupy STF 425 (Electronic Signature Standarisation in Rationalized Framework)

Prace prowadzone w ramach grupy roboczej są realizowane zgodnie z planem. Na chwilę obecną zrealizowano następujące zadania:

·         przygotowano draft dokumentu opisującego ramy standaryzacyjne dla podpisu elektronicznego (dokument dostępny do pobrania na stronie www.e-signatures-standards.eu)

·         przygotowano draft dokumentu opisującego repozytorium standardów dla podpisu elektronicznego

·         przeprowadzono szereg spotkań, na których prezentowano wyniki prac.

Draft dokumentu Rationalized Framework for Electronic Signature Standarization

Celem dokumentu jest uporządkowanie standaryzacji podpisu elektronicznego pod kątem:

·         potrzeb biznesowych

o   przygotowanie wskazówek do implementacji

o   przygotowanie wskazówek do testowania

o   przygotowanie przejrzystych wymagań

o   opisu

·         uproszczenia standardów (eliminowania niepotrzebnych opcji)

·         nadania wybranym dokumentom standaryzacyjnym statusu norm EN

·         ułatwienie dostępu do standardów przez utworzenie repozytorium i wprowadzenie wspólnej numeracji

Obszar standaryzacji podpisu elektronicznego został podzielony na kilka obszarów:

Rysunek 1 Obszary standaryzacji podpisu elektronicznego

 

Zakres prac nad modyfikacją standaryzacji dotyczącej podpisu został podzielony na dwa etapy:

1.       Szybkie poprawki (Quick Fixes) - które wyłącznie korygują błędy w istniejących specyfikacjach (etap zostanie zakończony na początku przyszłego roku).

2.       Przeprowadzenie działań opisanych w dokumencie „Rationalized Framework for Electronic Signature Standarization

Działania przewidziane dla obszaru 1 (Signature Creation & Validation)

Rysunek 2 Zakres działań związanych ze standaryzacją obszaru 1

W ramach obszaru „Signature Creation & Validation” przewiduje się utworzenie dokumentów:

·         zawierających wymagania dla aplikacji do składania i weryfikacji podpisu

·         specyfikacji dotyczących formatów podpisu elektronicznego

·         Wymagań dotyczących oceny zgodności aplikacji SCVA

·         Specyfikacji dotyczących sposobów testowania formatów podpisu i polityk podpisu

Dokumenty tworzone na potrzeby tego obszaru w dużej mierze są dojrzałe (specyfikacje formatów podpisu wraz z profilami). Dokumenty dotyczące testowania zgodności i interoperacyjności są w większości w fazie przygotowań (Test Suite for XAdES, CAdES, PAdES, ASiC – dostępne publicznie w katalogu http://docbox.etsi.org/ESI/Open/Latest_Drafts/ ). Procedury weryfikacji podpisu są w chwili obecnej w fazie draft (http://docbox.etsi.org/ESI/Open/Latest_Drafts/05_signature-verification-procedures%20and%20policies_000074v0018.pdf).

Profile zabezpieczeń dla aplikacji są wypracowywane w ramach CEN.

Działania przewidziane dla obszaru 2

Rysunek 3 Zakres działań związanych ze standaryzacją obszaru 2

W ramach obszaru 2 zostaną utworzone dokumenty odnoszące się do urządzeń do składania podpisu obejmujące następujące aspekty:

·         Zalecenia

·         Wymagania dla urządzeń

·         Specyfikacje interfejsów

·         Zagadnienia związane z oceną zgodności

Najbardziej dojrzałe w tym obszarze są dokumenty zawierające wymagania bezpieczeństwa (Protection Profiles) dla urządzeń, przygotowywane przez CEN.  Pozostałe dokumenty będą wypracowywane. W ramach CEN przygotowywany jest Protection Profile dla

Działania przewidziane dla obszaru 3 (Algorytmy kryptograficzne)

Rysunek 4 Zakres zadań związanych ze standaryzacją obszaru 3

Dla obszaru algorytmów kryptograficznych przewidziano utworzenie dokumentów opisujących:

·         zalecenia

·         Algorytmy dla podpisów elektronicznych

Specyfikacje techniczne związane z tym obszarem w dużej mierze będą bazować na specyfikacji TS 102176 (ALGO)

Działania przewidziane dla obszaru 3 (Dostawcy usług wspierających podpis elektroniczny)

Rysunek 5 Zakres działań związanych ze standaryzacją obszaru 4

W ramach obszaru jest wypracowywanych szereg dokumentów dotyczących polityk certyfikacji. Duża część pracy będzie bazować na istniejących dokumentach, w szczególności na zaktualizowanych http://docbox.etsi.org/ESI/Open/Latest_Drafts/08_Policy%20requirements%20for%20certification%20authorities%20issuing%20qualified%20certificates_000087v001.pdf, oraz http://docbox.etsi.org/ESI/Open/Latest_Drafts/09_Policy%20requirements%20for%20Certification%20Authorities%20issuing%20public%20key%20certificates_000088v001.pdf.

W chwili obecnej przygotowywany jest również draft dokumentu obejmującego swoją tematyką wymagania dotyczące certyfikatów EV (Extended Validation – certyfikaty SSL).

Część dokumentów, w szczególności dotyczących usług generacji i weryfikacji podpisu nie posiada na ten moment silnej bazy w postaci istniejących dokumentów.

Przygotowania wymaga zestaw dokumentów odnoszący się do oceny zgodności. Dokumenty dostępne na ten moment pokrywają obszar wydawania certyfikatów i generyczny zestaw wymagań: http://docbox.etsi.org/ESI/Open/Latest_Drafts/06_Trust%20Service%20Provider%20Conformity%20Assessment%20-general%20requirements_000075v003.pdf

Działania przewidziane dla obszaru 5 (Trust Application Service Providers)

Rysunek 6 Zakres zadań związanych ze standaryzacją obszaru 5

Obszar związany z dostawcami usług związanych z zaufaniem, na chwilę obecną obejmuje usługodawców oferujących:

·         usługi e-delivery (dostarczanie podpisanych elektronicznie przesyłek)

·         usługi archiwizacji podpisanych dokumentów

W obu obszarach powstają aktualnie specyfikacje dotyczące wymagań bezpieczeństwa dla tych systemów. Obszar związany z dostarczaniem elektronicznie podpisanych przesyłek jest dosyć dobrze opisany w specyfikacjach opisujących elektroniczną pocztę poleconą (REM).

Pozostałe dokumenty będą przygotowywane w ramach realizacji planu działań.

Działania przewidziane dla obszaru 6 (Trust Service Status List Providers)

Rysunek 7 Zakres działań związanych ze standaryzacją list TSL

W ramach dokumentacji związanej z szeroko pojętą tematyką list TSL zostaną przygotowane dokumenty dotyczące:

·         wymagań bezpieczeństwa

·         oceny zgodności

Odnośnie samego formatu listy TSL można spodziewać się nieznacznych modyfikacji.

Tematy poruszone podczas prezentacji postępu prac grupy STF 425

1.       Przeznaczenie listy TSL – czy powinny stanowić listę usług, które posiadają ocenę zgodności, czy wyłącznie służyć jako wsparcie dla walidacji? Konkluzja: TSL powinien w pierwszej kolejności służyć jako miejsce publikacji usług, które posiadają ocenę zgodności. Konieczne będzie rozszerzenie zawartości list TSL o informacje dotyczące źródła wymagań (Protection Profile, norma itp) i rodzaju akredytacji.

2.       Cryptographic suites – przydatne byłoby utrzymywanie listy algorytmów dopuszczonych w różnych krajach w jednym, centralnym miejscu. Kraje członkowskie miałyby obowiązek aktualizacji takich informacji.

3.       Jakie są na chwilę obecną możliwości wprowadzenia na listę TSL podmiotów z krajów innych niż z Europy? Konkluzja: Są dwa warianty współpracy. Można negocjować z Komisją Europejską warunki na jakich kraj spoza UE tworzyłby własną listę, albo podmiot może akredytować  się w systemie dobrowolnej akredytacji – może wtedy zostać wpisany na listę TSL jako podmiot akredytowany.

4.       Nazewnictwo Trusted Service List (instancja) i Trusted Service Status List (specyfikacja bazowa) jest mylące. Konkluzja: dyskusja została przeniesiona na poziom STF.

Raport z postępu prac grupy STF 428 (Quick Fix Testing)

Grupa STF 428 zajmuje się przygotowaniem dokumentów i infrastruktury niezbędnej do przeprowadzania testów interoperacyjności (Plugtests). W ramach prac grupa miała do realizacji cztery zadania:

1.       przygotowanie dokumentu opisującego zestaw testów dla PAdES wraz z przeprowadzeniem pierwszego PlugTestu

2.       przygotowanie dokumentu opisującego zestaw testów dla ASiC wraz z przeprowadzeniem pierwszego PlugTestu

3.       przygotowanie narzędzia do sprawdzania zgodności z Baseline profile dla XAdES

4.       przygotowanie specyfikacji przeprowadzania testów zgodności dla formatu XAdES

Status realizacji poszczególnych zadań jest następujący

1.       Został przygotowany draft dokumentu “Test Suite for PDF Advanced Electronic Signature (PAdES) interoperability test events” (http://docbox.etsi.org/ESI/Open/Latest_Drafts/13_test%20suite%20for%20PAdES%20interop_000096v004.pdf ), test interoperacyjności (PlugTest) jest w trakcie trwania (od 24 listopada do 19 grudnia)

2.       Został przygotowany draft dokumentu „Test Suite for Associated Signature Containers (ASiC) interoperability test events” (http://docbox.etsi.org/ESI/Open/Latest_Drafts/14_test%20suite%20for%20ASiC%20interop_000097v006.pdf ).  Odnośnie przygotowywania testu dla formatu ASiC gromadzenie materiału niezbędnego do przeprowadzenia testu rozpocznie się w styczniu.

3.       Narzędzie do testowania zgodności z Baseline Profile dla formatu XAdES jest w trakcie przygotowywania. Przewiduje się zakończenie prac w Lutym 2012. Na ten moment aplikacja obsługuje:

a.       wszystkie elementy obowiązkowe dla profilu short-term

b.      większość elementów opcjonalnych dla profilu short-term

c.       niektóre elementy dla profilu long-term

d.      zawiera zaawansowany mechanizm raportowania (raport w XML z trzema rodzajami wizualizacji)

4.       Przygotowano specyfikację dla przeprowadzania testów zgodności z Baseline Profile dla formatu XAdES (http://docbox.etsi.org/ESI/Open/Latest_Drafts/12_conformance%20Testing%20for%20XAdES%20Baseline%20Profile_000095v004.pdf )

 

Tematy poruszone podczas prezentacji postępów prac grupy STF 428

1.       Możliwość przygotowania testu interoperacyjności dla ASiC w pierwszym kwartale 2012. Konkluzja: Nie jest możliwe przygotowanie w tym terminie, ze względu na przygotowania do PlugTestów XAdES.

2.       Zakres udostępnienia narzędzia do weryfikacji zgodności z Baseline Profile dla XAdES. Konkluzja: Nie ma pewności czy narzędzie będzie dostępne publicznie przez 365 dni w roku. Na pewno będzie udostępnione uczestnikom PlugTest’ów dla XAdES’a.

 

Raport z postępu prac grupy STF 427 (Quick fixes to electronic signature standards)

Grupa STF 427 zajmuje się szerokim spektrum prac standaryzacyjnych:

·         zmianami w wymaganiach dla polityk certyfikacji i oceną zgodności

·         zmianami w profilach certyfikatów

·         procedurami walidacji podpisu

Poszczególne tematy były raportowane przez osoby odpowiedzialne za realizację danego tematu w ramach grupy:

Wymagania dla polityk certyfikacji i ocena zgodności

Wymagania dla polityk certyfikacji

Wymagania dla polityk certyfikacji nie zostały zmienione. Została przeorganizowana ich struktura w taki sposób, aby wymagania wspólne umieścić w ogólnym dokumencie, a wymagania szczegółowe w specyfikacjach odnoszących się do poszczególnych rodzajów usług.

Rysunek 8 Organizacja dokumentów zawierających wymagania polityk

W dokumencie opisującym ogólne wymagania bezpieczeństwa wprowadzono dodatkowy tymczasowy aneks A, zawierający listę problemów do rozwiązania.

Ocena zgodności:

Dla oceny zgodności przyjęto następujący model:

Rysunek 9 Schemat oceny zgodności

Proponowany schemat oceny zgodności przewiduje włączenie podmiotów oceniających zgodność do europejskiego systemu oceny zgodności. Dla Polski oznacza to, że podmioty weryfikujące zgodność musiałyby być akredytowane przez PCA (Polskie Centrum Akredytacji). W zakresie dobrowolnej akredytacji byłby to wymóg, natomiast w zakresie nadzoru – zalecenie. Wprowadzone zostały także  wymagania dotyczące audytorów dokonujących oceny zgodności.

Sam proces oceny zgodności byłby przeprowadzany na podstawie dokumentów zawierających wymagania bezpieczeństwa – odpowiednik dzisiejszych specyfikacji takich jak „Policy Requirements for certification authorities issuing qualified certificates”.

Ocena zgodności byłaby przeprowadzana raz na 3 lata (pełny audyt). Raz do roku przeprowadzany byłby audyt weryfikujący.  Przewiduje się także przeprowadzenie audytu weryfikującego w przypadku zgłoszenia informacji o incydencie bezpieczeństwa.

Tematy poruszane podczas prezentacji tematyki oceny zgodności

1.       Problematyka niejasnej terminologii (certyfikacja w znaczeniu dyrektywy oznacza wydanie certyfikatu, certyfikacja w znaczeniu oceny zgodności oznacza przyznanie potwierdzenia (approval) spełnienia wymagań; dobrowolna akredytacja w rozumieniu dyrektywy 99/93/EC oznacza certyfikację w znaczeniu oceny zgodności). Konkluzja: Dokumenty będą używać terminologii wywodzącej się z oceny zgodności i dokumentów normatywnych. W dokumencie opisującym system oceny zgodności, znajduje się mapowanie terminów na terminy z Dyrektywy 99/93/EC.

2.       Pytanie czy nazwa Trust Service Status Notification Body nie powinna zostać zmieniona na Schema Operator zgodnie ze specyfikacjami opisującymi listy TSL? Konkluzja: NIE. W dokumencie jest mowa o schemacie akredytacji i nadzoru. Nastąpiłoby pomieszanie pojęć.

Poprawki w profilach certyfikatów

W ramach poprawek odnoszących się do profili certyfikatów, wzięto pod uwagę profile:

·         certyfikatu kwalifikowanego;

·         certyfikatu dla osób fizycznych

Obecny zakres prac nie obejmuje profilu certyfikatu dla osoby prawnej.

Profil certyfikatu kwalifikowanego

W ramach profilu certyfikatu kwalifikowanego wprowadzono następujące modyfikacje:

·         Rozszerzenie QCStatement NIE MOŻE być oznaczane jako krytyczne

·         Po 30 czerwca 2015 obowiązkowe jest dołączanie nowego rozszerzenia zawierającego link do dokumentu PDS (PKI Disclosure Statement)

·         Wprowadzono obowiązek umieszczania pola QC Compliance Statement

Dodatkowo, poprawiono także odwołania do zaktualizowanych specyfikacji np: RFC 5280 zamiast RFC 3280.

Profil certyfikatu dla osób fizycznych

W ramach profilu zaktualizowano odwołania do zaktualizowanych specyfikacji.

Wprowadzono także:

·         obowiązek umieszczania pola AIA ze wskazaniami na certyfikaty urzędu CA

·         obowiązek umieszczania pola AIA ze wskazaniem na usługę OCSP

·         zaproponowano dodatkowy identyfikator opisujący semantykę dla pola serialNumber, dla osoby fizycznej i prawnej

Tematy poruszane podczas prezentacji tematyki profili certyfikatów

1.       Jakiego rodzaju separator o ile jakikolwiek powinien być używany dla semantyki pola SerialNumber. Konkluzja: Konieczne jest dodatkowe sprawdzenie dokumentów normatywnych, które być może regulują kwestie związane z semantyką identyfikatora, tak aby nie powodować konfliktów.

2.       Czy umieszczać rozszerzenie PDS w certyfikacie? Konkluzja: TAK: Obecność takiego rozszerzenia może mieć znaczenie w przypadku sprawy sądowej.

Procedura walidacji podpisu

Dokument opisujący procedurę walidacji podpisu został udostępniony publicznie pod adresem: http://docbox.etsi.org/ESI/Open/Latest_Drafts/05_signature-verification-procedures%20and%20policies_000074v0018.pdf.

W trakcie opisywania procedury zastosowano podejście blokowe. Wyróżniono podstawowe bloki procesu. Dla poszczególnych bloków zidentyfikowano wejścia i wyjścia, oraz opisano przebieg procesu.

Rysunek 10 Przebieg procedury walidacji podpisu

W ramach procedury wprowadzono pojęcie POE (Proof Of Existence) – jest to dowód, że obiekt (certyfikat, CRL, wartość podpisu itp.) istniała w określonym momencie czasu, który może być również zlokalizowany w przeszłości.

Wprowadzono także pojęcie „maksymalnej świeżości” informacji o unieważnieniu – informacja o unieważnieniu jest uznawana za „świeżą” wyłącznie przez określony kwant czasu.

Dokument opisuje również proces weryfikacji podpisu na moment w przeszłości. W tym wypadku posługuje się datą „control-time”, która określa moment czasu, dla którego możliwe jest stwierdzenie, że podpis istniał. Moment ten może przesuwać się w zależności od informacji znajdujących się w podpisie. Proces weryfikacji rozpoczyna się ustawiając „control-time” na wartość czasu bieżącego. W miarę przetwarzania poszczególnych elementów podpisu (listy CRL, znaczniki OCSP) wartość „control-time” przesuwa się w przeszłość, wskazując na jaki moment czasu został zweryfikowany podpis.

Tematy poruszane podczas prezentacji tematyki walidacji podpisu

1.       Obecny algorytm umożliwia przerwanie procesu walidacji po wykryciu, że certyfikat został unieważniony, nie umożliwiając zastosowania ewentualnych ograniczeń zawartych w polityce podpisu. Polityka podpisu w szczególności może wyłączać obowiązek weryfikacji poszczególnych certyfikatów ścieżki. Konkluzja: W opisie procesu weryfikacji certyfikatu konieczne jest dodanie notki, że w przypadku, gdy w ograniczeniach podpisu (validation constrains) zostaje wyłączona konieczność weryfikacji ważności certyfikatu, algorytm powinien pominąć krok weryfikacji i zwrócić wartość VALID.

Raport z postępu prac STF 426 (Baseline profiles)

Głównym zadaniem grupy jest stworzenie zestawu dokumentów opisujących profil referencyjny dla podpisu elektronicznego zgodny z Decyzją 2011/130/EC. Praca nad dokumentami była realizowana w dwóch fazach:

·         utworzenie dokumentów z profilem referencyjnym dla Wersji BES i EPES

·         utworzenie dokumentów dla profili długoterminowych T, A, XL, LTV

W ramach prac opublikowano następujące specyfikacje:

Data publikacji

Specyfikacja

 (2011-09-30)

XAdES TS 103 171

 (2011-09-30)

PAdES TS 103 172

 (2011-09-30)

CAdES TS 103 172

 (2011-09-30)

ASiC    TS 103 174

 

 

 

Wymienione specyfikacje obejmują wyłącznie wersje BES i EPES. Obecne drafty obejmują także profile dla wersji długoterminowych podpisu. Praca nad profilami zostanie zakończona w styczniu 2012.

Przyjęto następujące założenia dla profilu referencyjnego dla wersji archiwalnej podpisu:

·         podpis archiwalny może być tworzony bezpośrednio na bazie wersji T

·         podpis archiwalny nie może zawierać referencji do materiału (list CRL, odpowiedzi OCSP) znajdującego się na zewnątrz podpisu (zgodnie z wymaganiami decyzji 2011/130/EC)

W celu umożliwienia budowania wersji archiwalnej bezpośrednio na wersji T, dla formatu PAdES została zdefiniowana wersja T podpisu.

Wersja T podpisu zawiera obiekt SignatureTimestamp zgodny ze specyfikacją CAdES, albo alternatywnie zawiera DocumentTimestamp.

W celu umożliwienia budowania podpisu CAdES w wersji XL z pominięciem wersji C specyfikacja CAdES została zmodyfikowana:

·         referencje, na bazie których budowano wersję XL zostały oznaczone jako opcjonalne

·         dodatkowo, wprowadzono nową definicję archiwalnego znacznika czasu.

Nowa definicja archiwalnego znacznika czasu (ArchiveTimestampv3)rozwiązuje szereg problemów występujących w poprzedniej wersji znacznika czasu:

·         umożliwia strumieniowanie (streaming)

·         jest odporniejsza na dekodowanie

·         wprowadza także możliwość zastosowania ERS (Evidence Record Syntax – patrz RFC 4998)

 

Ustalenia dotyczące kolejnych spotkań

Na zakończenie spotkania ustalono harmonogram spotkań na rok 2012:

07-08 Luty 2012 – Waszyngton (USA)

05-06 Czerwiec 2012 – Sophia-Antipolis (Francja)

09-10 Październik 2012 – Londyn (Wielka Brytania)

 

Rekomendowane działania

1.       Ze względu na zmiany wprowadzane w dokumentach opisujących profil certyfikatu kwalifikowanego, proponuje się przegląd projektu rozporządzenia zmieniającego rozporządzenie 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,  pod kątem wprowadzanych zmian. Należy przy tym zauważyć, że dokumenty w obecnej wersji mogą ulec zmianie, co będzie wymagać kolejnych modyfikacji przepisów.

2.       Ze względu plany polegające na normalizacji zestawu wymagań dla podmiotów generujących listy TSL, zalecane jest aby przedstawiciele NBP monitorowali postęp prac w tym zakresie i aktywnie włączali się w tworzenie standardów.

3.       Ze względu na planowane wprowadzenie nowych profili zabezpieczeń dla podpisów typu „server based”, pożądany jest aktywny udział stron przedstawicieli podmiotów tą tematyką w procesie tworzenia standardów np. poprzez uczestnictwo w odpowiednich Komitetach Technicznych PKN.

4.       Ze względu na planowany kształt normalizacji obszaru oceny zgodności zalecane jest przedsięwzięcie w ramach Ministerstwa Gospodarki kroków polegających na utworzeniu odpowiedniego zaplecza spełniającego warunki wymienione w specyfikacji. Korzystne byłoby także aktywne zaangażowanie się PCA w proces tworzenia standardu.

IMM
Instytut Maszyn Matematycznych
2014 Instytut Maszyn Matematycznych. Prawa autorskie zastrzeżone.