Raport na temat aktualnego stanu podpisu

Raport na temat aktualnego stanu podpisu

Raport na temat aktualnego stanu podpisu
elektronicznego w Polsce
Paweł Krawczyk
Internet Society Poland
Wersja 5
Wstęp................................................................................................................................... 2
Stan obecny..........................................................................................................................3
Podstawy prawne podpisu elektronicznego.....................................................................3
Advanced Electronic Signature....................................................................................4
Qualified Certificate.....................................................................................................4
Secure Signature Creation Device (SSCD)..................................................................5
Polska ustawa o podpisie elektronicznym....................................................................... 5
Bezpieczne urządzenie według ustawy........................................................................6
Czy rozporządzenie jest w ogóle potrzebne?...............................................................6
Polskie rozporządzenie o warunkach technicznych ....................................................8
Bezpieczne urządzenie według rozporządzenia...........................................................9
Co mamy obecnie na rynku?......................................................................................10
Konsekwencje SSCD opartego o zwykły Windows..................................................11
Niech klient sam zadba o swoje urządzenie.............................................................. 12
„Bezpieczny inaczej”.................................................................................................13
Konflikt między ustawą a rozporządzeniem..............................................................14
Inne nieścisłości.........................................................................................................14
Problemy z formatami....................................................................................................16
Trzy standardy - cztery formaty.................................................................................17
Sigillum SDOC..........................................................................................................18
Konsekwencje wyboru „cztery firmy, cztery formaty”.............................................18
Jaki format wybierze administracja i dlaczego wszystkie cztery? .............................20
Faktury elektroniczne – kwalifikowany vs niekwalifikowany......................................21
Administracja publiczna – dojna krowa........................................................................ 22
Rozwiązania.......................................................................................................................24
Bezpieczne urządzenie do podpisu................................................................................25
Formaty podpisu elektronicznego..................................................................................26
PKCS7, CMS, XML..................................................................................................27
Format XML (XAdEs)...............................................................................................27
Który format najlepszy?.............................................................................................28
Server Based Signature Services................................................................................... 29
Język rozporządzenia.....................................................................................................29
Zakończenie................................................................................................................... 30
Wstęp
Internet Society Poland jest stowarzyszeniem, dla którego zawsze priorytetem była
popularyzacja społeczeństwa informacyjnego przez promowanie technik
informatycznych w życiu publicznym i biznesie.
Podpis elektroniczny jest narzędziem, które ma olbrzymi potencjał i może przynieść
wymierne korzyści zarówno osobom prywatnym, administracji publicznej oraz
biznesowi. Obserwując aktualny stan podpisu elektronicznego dostrzegamy jednak
poważne bariery na drodze do jego poprawnego rozwoju. Ten raport szczegółowo
analizuje te problemy i przedstawia propozycje rozwiązań, które zdaniem ISOC-PL mogą
przyczynić się do faktycznego wprowadzenia podpisu do powszechnego użycia w Polsce
i w Europie.
Autor chciałby podziękować następującym osobom za wkład i uwagi do tego dokumentu:
Mirosław Kutyłowski, Zbigniew Jakubowski, Piotr Waglowski, Władysław Majewski,
Józef Halbersztadt, Sergiusz Pawłowicz, Marcin Cieślak, Łukasz Jachowicz.
Kontakt z autorem: Paweł Krawczyk, tel. +48-602-776959, email: [email protected]
Stan obecny
Podstawy prawne podpisu elektronicznego
Źródłem prawa o podpisie elektronicznym jest Dyrektywa Unijna 1999/93 z dnia 13
grudnia 1999 r. (DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL).
Dyrektywa definiuje aspekt organizacyjny (instytucja centrów certyfikacji) i prawny
podpisu elektronicznego. O dyrektywie trzeba wiedzieć dwie rzeczy:


jest rekomendacją; państwa członkowskie UE (w tym Polska) powinny tworzyć
prawo na podstawie, ale niekoniecznie przez skopiowanie dyrektywy jeden do
jeden – w praktyce tak się zwykle robi, bo jest najłatwiej ale nie zawsze,
dyrektywa jest dość ogólna w zakresie technikaliów – np. mówi ogólnie, że
należy stosować algorytmy bezpieczne kryptograficznie, ale określenie że ma być
to na przykład RSA 1536 bitów nie leży w gestii dyrektywy.
Warto również wiedzieć, że dyrektywa definiuje specyficzny żargon. Do tego żargonu
należy określenie „electronic signature”, „advanced electronic signature” oraz „qualified
certificate” (na razie celowo pozostawiam bez tłumaczenia).
Jaka jest różnica między „electronic” a „advanced electronic”?
W rozumieniu dyrektywy napis „Józef Tkaczuk” napisane w ASCII pod mailem jest
podpisem elektronicznym („electronic signature”). Bo jest podpisem („signature”), i jest
elektroniczny („electronic”).
Chodzi oczywiście o to żeby w prawie istniało miejsce na różne techniki podpisu
stworzone na przestrzeni lat. Np. zeskanowane podpisy odręczne w produktach Adobe.
Advanced Electronic Signature
W tej analizie będziemy skupiać się tylko na podpisie „advanced electronic”. Dokładna
definicja tego podpisu w brzmieniu Dyrektywy:

“advanced electronic signature” means an electronic signature which meets the
following requirements (art 2 pkt 2 dyrektywy)
Dalej jest mowa o wymaganiach funkcjonalnych, takich jak jednoznaczne powiązanie z
właścicielem itd. W praktyce wymagania te są zapewniane przez odpowiednie funkcje
kryptograficzne.
Jest jeszcze jeden podpis – dla nas kluczowy - stanowiący silniejszą wersję „advanced”.
Jest to podpis „advanced” złożony po pierwsze przy pomocy specjalnego certyfikatu, po
drugie na specjalnym urządzeniu:

advanced electronic signatures which are based on a qualified certificate and
which are created by a secure-signature-creation device: (a) satisfy the legal
requirements of a signature in relation to data in electronic form in the same
manner as a handwritten signature (art 5 pkt 1 dyrektywy)
Czyli, odwracając szyk zdania – status prawny identyczny z podpisem odręcznym ma
tylko „zaawansowany podpis elektroniczny” oparty o „certyfikat kwalifikowany” i
„bezpieczne urządzenie do składania podpisu”. I tylko ten.
Tutaj pojawiają się pojęcia “qualified certificate” oraz “secure signature creation device”
(SSCD).
Qualified Certificate
Pierwszy termin „certyfikat kwalifikowany” oznacza certyfikat (klucz publiczny plus
opis właściciela), który został wydany zgodnie z określoną procedurą i musi zawierać
określone dane o posiadaczu.
Sens tego jest taki, że tożsamość przyszłego właściciela certyfikatu musi zostać
zweryfikowany (dowód osobisty, paszport, dokumenty firmy) przez uprawnioną trzecią
stronę (firmę, instytucję) wydającą certyfikat kwalifikowany. Po to, byśmy mieli
pewność że osoba, która go otrzyma jest tą za którą się podaje.
Z tego względu zgodnie z prawem polskim „certyfikatem kwalifikowanym” nie jest np.
klucz przechowywany w Mozilli (bo nie jest na karcie) ani wystawiony przez
miejscowego informatyka, nawet na karcie (bo wujek nie jest uprawnioną instytucją).
Czy jest to konieczne? Tak, ponieważ procedury weryfikacji stosowane przez
miejscowego informatyka mogą nie być wystarczające dla zapewnienia bezpieczeństwa
obrotu gospodarczego.
Secure Signature Creation Device (SSCD)
Drugi termin „bezpieczne urządzenie do składania podpisu elektronicznego” (SSCD)
oznacza urządzenie, które spełnia określone standardy bezpieczeństwa. Wymagania
wobec SSCD są wyłożone w Annex III dyrektywy. Dodatek ten mówi m.in. o tym żeby:




nie dało się odtworzyć klucza prywatnego z urządzenia
klucz prywatny ma być chroniony przed niepowołanymi
podpis ma być chroniony przed fałszerstwem
urządzeniu nie wolno zmieniać podpisywanych danych
Zwróćmy uwagę na ten ostatni punkt, który będzie kluczowy w dalszej części tej analizy.
Proszę również pamiętać, że dyrektywa jest dokumentem prawnym a nie
technicznym! Oznacza to, że „urządzenie” wcale nie musi być fizycznym urządzeniem
podobnym do bankomatu, które większości speców od IT od razu staje przed oczami.
Z prawnego punktu widzenia nawet słoik będzie bezpiecznym urządzeniem jeśli
będzie spełniał listę wymagań określonych w dyrektywie.
Zachowajmy te informacje w pamięci i podsumujmy - sama dyrektywa jest dokumentem
napisanym dobrze, spójnym i nie ma co do niej zastrzeżeń.
Polska ustawa o podpisie elektronicznym
Polska zaimplementowała dyrektywę 1999/93/EC jako „Ustawę z dnia 18. września 2001
r. o podpisie elektronicznym”. Ustawa jest prawie dokładnym tłumaczeniem dyrektywy.
W polskiej ustawie termin „advanced electronic signature” został przetłumaczony jako
„bezpieczny podpis elektroniczny” a nie „zaawansowany”, co się narzuca z
tłumaczenia.
Zwracało na to uwagę wiele osób, m.in. prof. Kutyłowski sugerując, że jest to
nieuzasadnione rozszerzenie znaczenia (gdyby autorzy dyrektywy mieli podstawy by
napisać „bezpieczny”, to napisaliby „secure”, a tymczasem napisali „advanced”).
Wypowiedź prof. Kutyłowskiego:
 http://security.computerworld.pl/artykuly/49795.html
Nie zmienia to jednak finalnego sensu ustawy, ponieważ dalej stwierdza ona
konsekwentnie:

Dane w postaci elektronicznej opatrzone bezpiecznym podpisem
elektronicznym weryfikowanym przy pomocy ważnego kwalifikowanego
certyfikatu są równoważne pod względem skutków prawnych dokumentom
opatrzonym podpisami własnoręcznymi (Art 5 pkt 2)
Czyli polska ustawa konsekwentnie zachowuje rozróżnienie „bezpieczny podpis” versus
„bezpieczny podpis weryfikowany kwalifikowanym certyfikatem”.
W praktyce to drugie nazywa się potocznie „podpisem kwalifikowanym”. Bezpieczny
podpis bez certyfikatu kwalifikowanego nazywa się „podpisem niekwalifikowanym” lub
„podpisem zwykłym”.
Bezpieczne urządzenie według ustawy
O wiele istotniejsze są jednak przepisy dotyczące omówionego wyżej „bezpiecznego
urządzenia do składania podpisu”. Fragment analogiczny do Appendix III dyrektywy jest
w Ustawie zawarty w art. 18. Oto jak brzmi interesujący nas fragment (art. 18 pkt 1):
Bezpieczne urządzenie służące do składania podpisu elektronicznego powinno co
najmniej: (…) nie zmieniać danych, które mają zostać podpisane lub
poświadczone elektronicznie oraz umożliwiać przedstawienie tych danych osobie
składającej podpis elektroniczny przed chwilą jego złożenia, (art. 18 pkt 1)
Kluczowe jest to, że ustawę rozszerza szereg rozporządzeń. Rozporządzenia te regulują
szczegóły techniczne oraz organizacyjne podpisu elektronicznego w Polsce.
W założeniach ustawa określa schemat ogólny i wymagania (jak powyżej), a
rozporządzenie wypełnia je treścią (konkretne zabezpieczenia).
Niestety w przypadku polskiego rozporządzenia stało się inaczej.
Dwa wyróżnione wyżej fragmenty są krytyczne z punktu widzenia poniższych rozważań
o sprzeczności rozporządzenia z ustawą.
Czy rozporządzenie jest w ogóle potrzebne?
Zanim przejdziemy do dalszej analizy, zatrzymajmy się nad jeszcze jedną kwestią. Czy
rozporządzenie do ustawy jest w ogóle potrzebne?
Na tle innych krajów członkowskich widać, że Polska zdecydowała się na wprowadzenie
„restrykcyjnej” wersji ustawy o podpisie elektronicznym, w którym państwo nie tylko
mówi jakie własności powinien mieć bezpieczny podpis (wymogi funkcjonalne
określone w Dyrektywie), ale dodatkowo narzuca jakimi środkami technicznymi ma to
być osiągnięte.
Sama dyrektywa nie mówi nic o szczegółach bezpiecznego urządzenia do składania
podpisu, a jedynie określa wymogi funkcjonalne wobec tego urządzenia - np. że nie
powinno zmieniać danych przeznaczonych do podpisania. Rozporządzenie określające
szczegóły techniczne urządzenia jest naszą rodzimą produkcją.
Niektórzy europejscy ustawodawcy ograniczyli się do wdrożenia ustawy w formie niemal
dosłownie przetłumaczonej z Dyrektywy unijnej. Np. w Czechach nie ma w ogóle
obowiązku korzystania z „bezpiecznego urządzenia” w sensie odrębnej, fizycznej
maszyny. Nie ma także zatem dodatkowego „rozporządzenia o warunkach
technicznych”, określającego szczegóły takiego urządzenia.
W powszechnym użyciu jest certyfikat kwalifikowany w sensie certyfikatu
wystawionego z zachowaniem odpowiednich procedur określonych w Dyrektywie. Ale
do składania podpisu może służyć dowolna aplikacja implementująca podpis
elektroniczny – Outlook Express, Mozilla, Microsoft Office, OpenOffice 2.0 itd.
Przez to, że ustawodawca nie określił szczegółowo ani formatów ani technicznych
parametrów „bezpiecznego urządzenia”, rynek wybrał je sam korzystając z powszechnie
przyjętych standardów technicznych, znanych od lat (np. S/MIME). Nie oznacza to, że
bezpieczeństwo podpisu elektronicznego w Czechach jest radykalnie niższe.
Zgodnie z prawem urządzenie do składania podpisu (czyli np. Windows z Outlookiem)
musi nadal spełniać wymogi ustawy, czyli np. nie zmieniać danych przeznaczonych do
składania podpisu. Jednak sposób w jaki ten wymóg jest w praktyce realizowany zależy
od samego podpisującego. To podpisujący odpowiada za bezpieczeństwo swojego
klucza prywatnego i wynika to wprost z czeskiej ustawy.
Podpis elektroniczny w Polsce został zdefiniowany o wiele bardziej drobiazgowo
(rozporządzenie o warunkach technicznych), co miało w założeniu zapewnić jego
większe bezpieczeństwo. Niestety w praktyce okazało się, że przez niefortunne
wyłączenie jakiejkolwiek ochrony tzw. „oprogramowania niepublicznego” faktyczny stan
podpisu elektronicznego w Polsce został sprowadzony do Windowsa z podłączonym
czytnikiem i zainstalowaną aplikacją do podpisywania.
Niestety, w odróżnieniu od rozwiązań stosowanych powszechnie na rynku, aplikacje te
korzystają z uznaniowo wybranych formatów i są niewygodne w stosowaniu, a
bezpieczeństwo takiego rozwiązania sprowadza się do bezpieczeństwa zwykłego
biurowego czy domowego systemu Windows.
Czyli, okrężną drogą, doprowadzono do tego że o bezpieczeństwie niby-bezpiecznego
urządzenia i tak decyduje tylko użytkownik. Niestety, w przeciwieństwie do Czech,
użytkownicy dowiedzieli się o tym nie z ustawy, tylko od centrów certyfikacji podczas
kłótni wywołanym przez publikację firmy G DATA (szczegóły dalej).
Oznacza to, że Czesi, którzy pozornie wybrali rozwiązanie mniej bezpieczne, w obecnej
chwili dysponują identycznym poziomem bezpieczeństwa jak my, ale bez związanych z
tym problemów z kompatybilnością (które omawiamy poniżej), za to przy radykalnie
większej wygodzie i praktyczności korzystania z tego podpisu.
Czy czeskie rozwiązanie jest lepsze? Na pewno z punktu widzenia przejrzystości prawa –
tak, jest lepsze! Jeśli chodzi o bezpieczeństwo to byłoby mniej bezpieczne, gdyby nasze
rozporządzenie nie wprowadziło dodatkowych zabezpieczeń, które samo potem zniosło.
Jedyną istotną różnicą, która odróżnia wymogi polskie od czeski jest wynikający z
polskieg rozporządzenia obowiązek przechowywania klucza prywatnego na karcie. Jest
to obowiązek słuszny w przypadku podpisu kwalifikowanego, ponieważ zapewnia on
realnie duże bezpieczeństwo klucza prywatnego przed kradzieżą. Kradzież klucza
prywatnego miałaby bardzo poważne konsekwencje dla użytkownika (możliwość
nieograniczonego składania fałszywych podpisów) i obowiązek ten jest wart utrzymania.
Polskie rozporządzenie o warunkach technicznych
Głównym dokumentem określającym szczegóły techniczne podpisu elektronicznego jest
rozporządzenie o warunkach technicznych (pełna nazwa: „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.” ).
Rozporządzenie, w odróżnieniu od ustawy, nie jest oparte o dyrektywę i zostało napisane
w Polsce. Częściowo zawiera ono rozwiązania techniczne opisane w profilu
bezpieczeństwa CWA 14169, zaproponowanym przez Europejski Komitet Standaryzacji
(CEN).
Jednak jako całość, jest ono sprzeczne zarówno z dyrektywą unijną jak i polską ustawą i
to jest kluczowy problem obecnego polskiego prawodawstwa.
Na czym polega ta sprzeczność? Otóż rozporządzenie wprowadza, a zaraz potem w
nieuzasadniony sposób znosi wymogi bezpieczeństwa wobec „bezpiecznego
urządzenia” narzucone przez ustawę.
Daje to centrom certyfikacji prawo do sprzedawania klientom kilku klocków do budowy
„bezpiecznego urządzenia” ze słowami „sami sobie to złóżcie i zabezpieczcie”.
Finalny rezultat, jaki możemy oglądać w praktyce jest sprzeczny z wymogami
narzuconymi przez dyrektywę, nie mówiąc już o zdrowym rozsądku i zasadach dobrej
praktyki inżynierskiej w ochronie danych.
Drugi problem to formaty podpisu, który opiszę później. Przejdźmy do szczegółów
bezpiecznego urządzenia.
Bezpieczne urządzenie według rozporządzenia
Mając cały czas w głowie odpowiedni akapit ustawy („bezpieczne urządzenie powinno
nie zmieniać danych do podpisania”) przyjrzyjmy się pewnej definicji użytej w polskim
rozporządzeniu.
Oprogramowanie publiczne - oprogramowanie podpisujące, do którego w
normalnych warunkach eksploatacji może mieć dostęp każda osoba fizyczna;
Oprogramowaniem publicznym nie jest w szczególności oprogramowanie używane
w mieszkaniu prywatnym, lokalu biurowym lub telefonie komórkowym (par 1 pkt 9)
Na jakiej podstawie założono, że komputer w mieszkaniu czy w biurze jest bezpieczny?
W normalnych dziś warunkach eksploatacji jakim jest stałe łącze do Internetu, do
komputera dostęp ma praktycznie cały świat. Codziennie tysiące komputerów domowych
i biurowych na całym świecie pada ofiarą koni trojańskich.
Fragment ten jest kuriozalny dlatego, że dzięki niemu ustawodawca kawałek dalej
zezwolił producentom na niestosowanie zabezpieczeń w „bezpiecznym urządzeniu”!
Jak to się stało? Otóż autor ustawy na początku wprowadził zabezpieczenia, które musi
implementować „bezpieczne urządzenie” (omawiamy je dalej).
Ale zabezpieczenia te dotyczą tylko oprogramowania publicznego.
To co nie jest „oprogramowaniem publicznym” nie musi tych zabezpieczeń stosować.
Ponieważ „bezpieczne urządzenie” w biurze i w domu nie jest „publiczne”, więc nie musi
mieć zabezpieczeń.
Innymi słowy, autor rozporządzenia założył, że oprogramowanie stosowane w domu lub
w biurze jest bezpieczne samo przez się.
Mowa tutaj o przeciętnym domowym lub biurowym Windowsie, bo tylko pod ten system
są dostępne aplikacje do składania podpisu.
Każdy kto ma cokolwiek wspólnego z bezpieczeństwem wie, że to właśnie komputery
biurowe i domowe najczęściej padają ofiarami wirusów, rootkitów i koni trojańskich. Jak
pisałem powyżej w dobie Internetu, każdy podłączony do sieci system jest publiczny!
Każdy ma do niego dostęp i wynikałoby to z dosłownego brzmienia tego punktu („ma
dostęp” – nie powiedziano że dostęp fizyczny), gdyby zdanie dalej nie wprowadzono
kuriozalnej definicji bezpieczeństwa przez mieszkanie lub biuro.
Z moich doświadczeń wynika że niezałatany system Windows 2000 Server jest
znajdowany przez automatyczne skanery i skutecznie infekowany w ciągu 5 minut po
podłączeniu do sieci. Niezależnie od tego czy stoi w domu na pawlaczu, czy w biurze w
sejfie.
W rezultacie tej nieuzasadnionej klasyfikacji rozporządzenie wyłącza spod ochrony
100% oprogramowania, które tej ochrony właśnie najbardziej potrzebuje.
Od strony prawnej jest to zrealizowane następująco:




rozporządzenie wprowadza pojęcie „bezpiecznego kanału” (par 1 pkt 13), czyli
zabezpieczenia przed naruszeniem integralności podpisywanych danych po
drodze między plikiem a aplikacją,
następnie wprowadza obowiązek stosowania tego kanału przez „oprogramowanie
publiczne” (par 4 pkt 4), gdzie indziej o nim nie wspominając;
a zatem oprogramowanie niepubliczne nie ma obowiązku stosowania
bezpiecznego kanału
jako że dzięki odpowiedniej definicji niemal 100% oprogramowania stosowanego
do podpisu staje się „niepubliczne”, pojęcie „bezpiecznego kanału” jest
martwe!
Jak pokazało życie polskie centra certyfikacji chętnie zastosowały się dwóch ostatnich
punktów.
W rezultacie w rozporządzeniu pominięto kwestię ochrony integralności danych
wyraźnie podkreśloną zarówno w dyrektywie jak i ustawie przez kwestię „bezpieczne
urządzenie powinno nie zmieniać danych do podpisania” rozwadniając ją do momentu
gdzie straciła sens.
Co w intencji autora rozporządzenia miało być „oprogramowaniem publicznym?.
Komputery w kafejkach internetowych lub na uczelniach? Chyba jedynie one w praktyce
podpadają pod zacytowaną definicję. Ale skąd tam czytniki kart? Można sobie również
wyobrazić jakieś kioski internetowe oferujące podpis elektroniczny, które też by pod to
podpadały, ale zwykle są to systemy dedykowane i dobrze zabezpieczone.
O wiele bardziej należy się martwić o zwykłe pecety uznane za autorów rozporządzenia
za bezpieczne „in statu nascendi”.
Co mamy obecnie na rynku?
Wszystkie cztery centra certyfikacji oferują „bezpieczne urządzenie do składania
podpisu” (SSCD) w postaci „zestawu do samodzielnego montażu”.
Oferują, bo im wolno, dzięki takiej a nie innej konstrukcji rozporządzenia.
Kupując takie urządzenie klient otrzymuje:
 czytnik kart elektronicznych,
 kartę elektroniczną z certyfikatem,
 oprogramowanie do składania i weryfikacji podpisu.
Oprogramowanie jest przeznaczone do instalacji na standardowym systemie Windows,
wraz ze wszystkimi tego konsekwencjami.
Konsekwencje SSCD opartego o zwykły Windows
Aby nie być gołosłownym, w październiku 2005 roku firma G DATA ze Szczecinka
zaprezentowała demonstrację, w której oprogramowanie firmy Certum zostało
wykorzystane do sfałszowania podpisu elektronicznego w systemie Windows.
Sfałszowanie polegało na zainstalowaniu w tym systemie rootkita, który przechwytywał
wywołania systemowe Windows. W rezultacie program Certum inny plik wyświetlał
użytkownikowi przed podpisaniem, a inny faktycznie podpisywał. Proszę zauważyć, że
wymóg wyświetlenia dokumentu przed podpisaniem jest również narzucony przez
ustawę (art. 18 pkt 1) i jest on jak najbardziej słuszny. Ale tutaj nic nie pomógł, bo rootkit
inteligentnie „podawał” odpowiednią treść pliku w zależności od tego kto o nią prosił. Do
wyświetlenia zwracał prawdziwą, do podpisania – podmienioną.
Demonstracja wywołała gwałtowną reakcję polskich centrów certyfikacji, które zarzuciły
G DATA merkantylność, nieuctwo, szerzenie paniki itd.
Odpowiedź Certum można znaleźć tutaj:
 http://www.unizeto.pl/unizeto/47911.xml
 http://www.unizeto.pl/unizeto/unizeto,pz_e_podpis_opinie.xml
Podobne oświadczenie wydał m.in. KIR i Signet.
Ale G DATA zademonstrowała zdarzenie, które jest jak najbardziej możliwe w
rzeczywistości. Jest to zdanie osoby która z racji wykonywanego zawodu często spotyka
się z rootkitami, końmi trojańskimi itp. i dobrze zna ich wysoką skuteczność w
przenikaniu do systemów ofiar, niezależnie od lokalizacji.
Dlatego też podjąłem decyzję o opisaniu tego przypadku na łamach Computerworld
Security Online i podjąłem późniejszą polemikę z centrami certyfikacji. Zaowocowała
ona ze strony centrów stworzeniem długiego dokumentu pt. „Mity i fakty o podpisie
elektronicznym”, który jest publikowany na stronach Certum (drugi link zacytowany
powyżej), KIR oraz Signet (http://www.signet.pl/info/aktualnosci.html).
Wiele twierdzeń tam zawartych jest prawdziwych i nie będę z nimi polemizował. Jednak
części problemów centra nie poruszyły w ogóle (formaty podpisu opisane poniżej), a
część przedstawiły tak jak im wygodnie. Tak jest też z bezpiecznym urządzeniem do
podpisu elektronicznego.
Centra certyfikacji posługują się w swoich wypowiedziach dwoma argumentami, które
powtórzę dla zwięzłości swoimi słowami:


„przecież zalecamy instalację antywirusa”
„przecież jesteśmy zgodni z rozporządzeniem”
Niech klient sam zadba o swoje urządzenie
W poniższym akapicie będę pisał głównie o Certum, ale chciałbym na wstępie podkreślić
że problem ten dotyczy wszystkich polskich centrów certyfikacji. Certum aktywnie
brało w tej dyskusji udział m.in. przez swoje publikacje. Fakt ten jest godny
zauważenia. Podobne oświadczenia wydawał KIR i Signet.
Argument „zalecamy instalacje antywirusa”, jest tutaj oparty o jedno zdanie, znalezione
przeze mnie w październiku w instrukcji do jednego z programów Certum (obecnie nie
jest ona dostępny na stronie Certum).
Równocześnie w opisanym wyżej artykule Certum przyznaje że: „atak wirusa G DATA
jest możliwy, ale tylko w przypadku stosowania oprogramowania niezgodnie z
zaleceniami zawartymi w Podręczniku użytkownika dołączanego do produktów Unizeto
Technologies SA.”
Niezgodnie, to znaczy jeśli w systemie nie ma antywirusa co zdaniem Certum jest
gwarancją bezpieczeństwa systemu. Jest to fikcja. Większość obecnie stosowanych
antywirusów nie jest w stanie wykryć rootkitów kontrolujących system, co więcej jest
przez nie skutecznie unieszkodliwiana. Wykrywanie sygnaturowe na jakim polega
większość antywirusów jest całkowicie nieskuteczne przeciwko nowym rootkitom,
zwłaszcza spersonalizowanym pod konkretną grupę ofiar. Szczegółowe informacje o
współczesnych rootkitach można znaleźć tutaj:

http://security.computerworld.pl/news/85231.html
W wspomnianym artykule Certum/Unizeto jest również kilka innych pomysłów „jak
korzystać z aplikacji bezpiecznie”. Na przykład – dodawać do podpisywanego
dokumentu dodatkowy opis co jest w środku, odłączyć komputer od sieci czy
zainstalować wspomniany antywirus i firewall.
Pomysły w rodzaju dodawania dodatkowego opisu do dokumentu czy odpięcia
komputera od sieci mają sens techniczny jako łatanie obecnego stanu rzeczy, ale w
szerszej perspektywie brzmią śmiesznie i sprowadzają do absurdu sens stosowania
podpisu elektronicznego jako łatwego i taniego.
Po to mamy skrót kryptograficzny podpisany kluczem prywatnym żeby nie musieć
dodawać opisu co jest w środku!
Odłączając komputer od sieci nie będziemy mogli za to korzystać ze znakowania czasem,
weryfikować ważności certyfikatów i tak dalej.
Jako początkowe założenie do budowy bezpiecznego urządzenia należy przyjąć że 90%
klientów zainteresowanych podpisem elektronicznym nie ma zielonego pojęcia o tym jak
poprawnie zabezpieczyć Windows. Sugerowanie im żeby sami zbudowali sobie takie
urządzenie i jeszcze go zabezpieczyli jest nieuzasadnionym mąceniem im w głowach!
Podsumowując, argument że to klient powinien dbać o swoje „bezpieczne urządzenie”
jest chybiony z następujących powodów:


powód techniczny - firewalle ani antywirusy dostępne na rynku nie są
skutecznym zabezpieczeniem przed rootkitami i końmi trojańskimi stosowanymi
obecnie;
powód formalny - klient kupujący „bezpieczne urządzenie” w żadnym wypadku
nie powinien otrzymywać zestawu typu „zrób to sam” którego bezpieczeństwo
zależy od tego jakiego zainstalował antywirusa czy jak często uaktualnia
regułki;
Rozwijając drugi punkt: klient nie jest osobą kompetentną do budowania SSCD!
Proponowanie „zestawu do samodzielnego montażu” i bronienie go przed racjonalnymi
zarzutami przez wymyślanie coraz to kolejnych półśrodków jeszcze bardziej pogrąża
podpis elektroniczny w oczach opinii publicznej.
W interesie zarówno użytkowników podpisu jak i centrów certyfikacji jest by
środowisko do składania podpisu było faktycznie bezpieczne, a nie bezpieczne „w
rozumieniu rozporządzenia”.
Rozwiązanie tego problemu nie jest łatwe zarówno od formalnej jak i technicznej strony.
Ale jest możliwe. Swoje propozycje przedstawię pod koniec tego dokumentu.
„Bezpieczny inaczej”
Argumentacja „jesteśmy bezpieczni z rozporządzeniem” wychodzi od definicji w
rozporządzeniu i tworzy wrażenie, że coś co nazwano „bezpiecznym urządzeniem” wcale
– wbrew nazwie – nie musi być bezpieczne. Pojęcie „bezpieczne w rozumieniu
rozporządzenia” nie ma tutaj nic wspólnego z potocznym rozumienia słowo
„bezpieczeństwo”.
We wspomnianym wyżej artykule Certum używa więc pojęcia „bezpieczeństwo prawne”
i argumentuje, że G DATA nie zrozumiała ustawy bo przecież ich bezpieczne urządzenie
jest „bezpieczne w rozumieniu rozporządzenia”. Można by powiedzieć „bezpieczne
inaczej”…
Certum wydaje się być rozgrzeszone z tego, że nie jest bezpieczne bo przecież
rozporządzenie poniekąd zwolniło ich z tego obowiązku (patrz „oprogramowanie
publiczne” powyżej). Poniekąd, ponieważ zgodność z rozporządzeniem nie oznacza, że
można zignorować wymogi ustawy, będącej aktem nadrzędnym.
Konia z rzędem temu, kto na podstawie takiego uzasadnienia wykrzesa w sobie choć
trochę zaufania do podpisu elektronicznego w polskim wydaniu.
Jak zobaczymy poniżej, ta nieuzasadniona interpretacja pojęcia „bezpieczeństwo” została
wprowadzona tylko przez rozporządzenie. Ale już ustawa z której się ono wywodzi
posługuje się normalnie rozumianym pojęciem bezpieczeństwa!
Konflikt między ustawą a rozporządzeniem
Powyższe dyskusje właściwie nie powinny w ogóle mieć miejsca w świetle wymagań,
jakie nakłada ustawa – czyli dokument nadrzędny w stosunku do rozporządzenia.
Przypomnijmy ten fragment (art. 18 pkt 1):
Bezpieczne urządzenie służące do składania podpisu elektronicznego
powinno co najmniej: (…) nie zmieniać danych, które mają zostać podpisane lub
poświadczone elektronicznie oraz umożliwiać przedstawienie tych danych osobie
składającej podpis elektroniczny przed chwilą jego złożenia,
Urządzenie do samodzielnego montażu (pecet z Windows, czytnikiem i kartą) nigdy nie
będzie w stanie praktycznie spełnić tego warunku ponieważ ryzyko zainfekowania
przeciętnego Windowsa rootkitami jest duże i realne, nawet pomimo firewalli i
antywirusów.
Trudno również uznać za zgodne z zamysłem ustawodawcy i zdrowym rozsądkiem
urządzenie, które dziś jest zgodne (bo nie jest zainfekowane i nie zmienia) a jutro nie jest
zgodne (bo akurat antywirus nie zdążył z aktualizacją). Ogólnie - którego
bezpieczeństwo zależy od uznaniowego zainstalowania przez użytkownika
dodatkowego oprogramowania.
Faktem wynikającym z prostej lektury tekstu ustawy i rozporządzenia jest że to co
ustawa definiuje jednoznacznie i funkcjonalnie („nie powinno zmieniać danych”) jest
potem rozwadniane przez rozporządzenie w mętnych wywodach o oprogramowaniu
publicznym.
Z tego wynika, że rozporządzenie jest bezdyskusyjnie sprzeczne z ustawą i
dyrektywą, z której się ona wywodzi, a obecnie oferowane „bezpieczne urządzenia” nie
spełniają wymogów ustawy i Dyrektywy.
Inne nieścisłości
Rozporządzenie – w przeciwieństwie do ustawy i dyrektywy – dzieli „bezpieczne
urządzenie” na dwie części:


komponent techniczny - sprzęt stosowany w celu wygenerowania lub użycia
danych służących do składania bezpiecznego podpisu elektronicznego lub
poświadczenia elektronicznego (par 1 pkt 6)
oprogramowanie podpisujące - oprogramowanie, które przygotowuje dane,
które mają zostać podpisane lub poświadczone elektronicznie, i przesyła je do
komponentu technicznego (par 1 pkt 7)
Dla uproszczenia będziemy mówić o komponencie sprzętowym i programowym.
Rozporządzenie wprowadza również wspomniane wyżej zabezpieczenia – ścieżkę i
kanał:


bezpieczna ścieżka - łącze zapewniające wymianę między oprogramowaniem
podpisującym a komponentem technicznym informacji związanych z
uwierzytelnieniem użytkownika komponentu technicznego, zabezpieczone w
sposób uniemożliwiający naruszenie integralności przesyłanych danych przez
jakiekolwiek oprogramowanie (par 1 pkt 12)
bezpieczny kanał - łącze zapewniające wymianę między oprogramowaniem
podpisującym a komponentem technicznym informacji związanych z
przekazywaniem danych, które mają być podpisane lub poświadczone
elektronicznie, zabezpieczone w sposób uniemożliwiający naruszenie
integralności przesyłanych danych przez jakiekolwiek oprogramowanie (par 1 pkt
13)
Jak widać istnieją mechanizmy zabezpieczające transmisję danych między kartą a
aplikacją oraz między plikiem a aplikację. Tyle tylko że przez opisane wyżej gierki z
„oprogramowaniem niepublicznym” zostały one w praktyce wyłączone.
Również wymagania bezpieczeństwa odnośnie tych komponentów są różne.
Komponent sprzętowy musi posiadać niezależny certyfikat bezpieczeństwa,
zdefiniowany tak:

Komponenty techniczne powinny posiadać certyfikaty zgodności, zaświadczające
spełnienie wymagań określonych w Polskich Normach, a w przypadku braku
takich norm, spełnienie wymagań określonych w dokumentach (…) (par 5 pkt 2)
Następnie są wymienione standardy bezpieczeństwa ITSEC-E3, Common Criteria EAL4
lub FIPS-140. Są to standardy określone przez różne międzynarodowe organizacje,
zgodność z nimi jest w Polsce potwierdzana przez Departament Bezpieczeństwa
Teleinformatycznego ABW. W Polsce obowiązują także certyfikaty wydane przez
analogiczne instytucje NATO. Ze względu na fakt, że większość kart elektronicznych i
czytników jest wyprodukowana w krajach NATO i ma już taki certyfikat, są one
uznawane u nas.
Natomiast komponent programowy musi posiadać tylko i wyłącznie dobrowolną
deklarację zgodności:

Oprogramowanie podpisujące stosowane przy składaniu bezpiecznych podpisów
elektronicznych powinno posiadać deklarację zgodności (par 7 pkt 11)
Deklaracja jest wystawionym przez producenta oświadczeniem, że jego produkt jest
zgodny z rozporządzeniem.
Deklaracja jest jednostronicowym dokumentem, które zawiera dokładnie takie
lakoniczne stwierdzenie jak powyżej – deklaracje te można znaleźć na stronach
poszczególnych centrów.
Co jest najbardziej istotne, deklaracji tych nikt w praktyce nie weryfikuje!
Problemy z formatami
Jeśli przyglądamy się podpisowi elektronicznemu w Polsce z daleka to, poza
problemami z bezpiecznym urządzeniem, wygląda to bardzo elegancko. Wszyscy sobie
mogą podpisywać, wymieniać się dokumentami, fakturami itd. Niedługo będziemy mogli
wysyłać podania do urzędów podpisane elektronicznie.
Przygotowując w ubiegłym roku dla Computerworld tekst o podpisie pobrałem ze stron
centrów certyfikacji aplikacje testowe, część z nich z certyfikatami testowymi. Niestety,
praktyczne testy doprowadziły mnie do wniosku, że podpis elektroniczny, poza
problemami z bezpiecznym urządzeniem, nie nadaje się w Polsce do praktycznego
użytku.
Wszyscy czterej wystawcy certyfikatów kwalifikowanych w Polsce deklarują pełną
zgodność z rozporządzeniem. I faktycznie, każda z firm jest zgodna z jednym ze
standardów zaleconych przez rozporządzenie. Problem polega na tym, że każda z
innym!
Format plików generowanych przez programy do składania bezpiecznego podpisu
elektronicznego określa rozporządzenie o warunkach technicznych (par 30 pkt 1,
podpunkt 1).
Konkretnie, rozporządzenie dopuszcza by aplikacje do składania podpisu generowały
podpis w jednym z trzech formatów:
1. CMS (Cryptographic Message Syntax), format definiowany przez normy ETSI
TS 101 733 oraz RFC 3125 i RFC 3126.
2. Format oparty o XML, definiowany przez normę ETSI TS 101 903 (XAdEs)
3. PKCS7 binarny format będący podzbiorem CMS.
Te trzy formaty są wzajemnie niekompatybilne. Każdy z nich ma inną strukturę i jest
inaczej kodowany (CMS i PKCS7 są plikami binarnymi, a XML jest plikiem
tekstowym). Formaty XML i CMS są mniej więcej równoważne funkcjonalnie, PKCS7
jest uboższy (na przykład nie przechowuje informacji o znacznikach czasowych).
Trzy standardy - cztery formaty
Polskie centa certyfikacji oferują oprogramowanie, które posługuje się następującymi
formatami (stan na październik 2005):
1. Program proCertum CombiLite zapisuje podpisy cyfrowe w formacie CMS.
Żaden inny testowany program nie był w stanie zweryfikować tak złożonego
podpisu. Program zapisuje pliki z rozszerzeniem SIG.
2. KIR oraz jego aplikacj SafeDevice stworzona przez firmę BSB zapisuje podpis
cyfrowy w formacie PKCS7. Ten podpis jako jedyny został poprawnie
zweryfikowany przez proCertum CombiLite. W drugą stronę to jednak nie działa
- SafeDevice nie weryfikuje podpisu w formacie CMS złożonego przez
CombiLite. Można tego było oczekiwać bo CMS jest nadzbiorem PKCS7.
SafeDevice również korzysta z rozszerzenia SIG przez co korzystanie z tych
dwóch programów w jednym systemie jest cokolwiek niewygodne.
3. Signet Proofer nie weryfikuje żadnego z podpisów złożonych przez inne
programy i trudno się dziwić bo jako jedyny korzysta z formatu XML, całkowicie
odmiennego od CMS i PKCS7. Z tego samego powodu żadna z pozostałych
aplikacji nie będzie w stanie zweryfikować podpisu złożonego Signet
Confidantem. Program posługuje się plikami z rozszerzeniem SIGNET.
Trzy wymienione wyżej aplikacje operują na dowolnych plikach, to znaczy z menu
wybieramy fizyczny plik, obojętne w jakim formacie, i składamy na nim podpis. Wynik
jest zapisywany albo do oddzielnego, małego pliku albo w formacie zwartym, w którym
zarówno treść dokumentu jak i podpis znajdują się fizycznie w jednym pliku.
Umożliwiają to wszystkie trzy standardowe formaty - CMS, PKCS7 i XML.
4. Sigillum Sign jest oryginałem wyróżniającym się spośród pozostałych
programów zarówno filozofią jak i formatem zapisywanych dokumentów.
Program nie operuje bowiem na plikach tylko integruje się ściśle z pakietem MS
Office, pozwalając na podpisywanie dokumentów z poziomu Worda, Excella i
PowerPointa. Brak jest funkcji w rodzaju "wybierz plik do podpisania". Zamiast
tego w menu Worda pojawia się nowa pozycja "podpisz dokument", której
wybranie powoduje wygenerowanie graficznego obrazu każdej ze stron
dokumentu czy arkusza. Są one następnie importowane do Sigillum Sign,
podpisywane i zapisywane w prywatnym formacie SDOC opracowanym przez
Sigillum.
Sigillum SDOC
Po bliższym przyjrzeniu się SDOC okazuje się że jest to archiwum w natywnym
windowsowym formacie CAB, zawierające pliki graficzne reprezentujące poszczególne
strony dokumentu oraz - prawdopodobnie - plik z podpisami cyfrowymi każdej z nich.
Z infolinii Sigillum dowiedziałem się że jest to „format prywatny” opracowany przez tę
firmę. Przy kolejnym telefonie powiedziano mi że jednak sam podpis cyfrowy jest
zgodny z PKCS7. Ale nawet jeśli jest, to „zakopany” gdzieś w środku archiwum CAB.
Oczywiście format SDOC nie jest akceptowany przez żaden z wymienionych wyżej
programów.
Słusznie zastanawiają się ci, którzy poszukują formatu SDOC na liście formatów
dopuszczonych przez rozporządzenie. Nie ma go tam.
Rozporządzenie dopuszcza możliwość stosowania innych formatów, ale muszą być one
zarejestrowane w ISO. Dnia 11. lutego wysłałem do Sigillum zapytanie czy ten format
został zarejestrowany i czekam na odpowiedź.
System podpisu elektronicznego wprowadzony przez Sigillum jest rozwiązany elegancko
i byłby wygodny w stosowaniu, ale… tylko wówczas gdyby był jedynym formatem na
świecie.
Jako element rynkowej całości wprowadza tylko dodatkowe zamieszanie. Jako
format narzucony prawem do stosowania z podpisem kwalifikowanym stanowi
poważną barierę dla kompatybilności, dostępności i przenośności.
Konsekwencje wyboru „cztery firmy, cztery formaty”
Polskie centra certyfikacji ze wszystkich możliwych kombinacji wybrały najgorszą–
każde z nich korzysta z innego formatu. W rezultacie opowieści o powszechnym i
łatwym stosowaniu podpisu elektronicznego w biznesie i administracji na dzień dzsiejszy
należy traktować jako mrzonki.
Pojedyncze wdrożenia podpisu elektronicznego, którymi chwalą się centra certyfikacji
(GIIF, serwis aukcyjny zamówień publicznych, pewien bank) nie świadczą o niczym.
Dotyczą one stosunkowo wąskich grup użytkowników wymieniających się tymi samymi
podpisami między sobą i nie pozwoliły im jeszcze doświadczyć w pełni problemów z
formatami. Ale jeśli ktoś zechciałby skorzystać równocześnie i z GIIF, i aukcji
publicznych i z w/w banku to zauważy ze zdumieniem, że są to trzy różne podpisy
elektroniczne i trzy różne aplikacje.
Zgodnie z tym co mamy dzisiaj, jeśli firma A kupi certyfikat w Certum, a firma B w
Sigillum, to będą mogły wysyłać sobie podpisane faktury lub umowy tylko pod
warunkiem że każda będzie mieć zainstalowany program do weryfikacji podpisu
„przeciwnika”. W skrajnym przypadku będą to cztery różne programy, z czego dwa
kolidujące (rozszerzenie SIG).
W praktyce nie mamy więc w Polsce jednego podpisu elektronicznego. Mamy ich
cztery:




podpis wg Certum,
podpis wg Sigillum,
podpis wg Signetu,
podpis wg KIR.
Pociąga to za sobą szereg problemów natury praktycznej:



konieczność instalacji oprogramowania firmy, której certyfikatem będziemy
podpisywać nasze dokumenty (co jest zrozumiałe),
konieczność instalacji oprogramowania każdej z firm, której certyfikatem będą
podpisywać swoje dokumenty nasi kontrahenci (co jest już sporą
niedogodnością),
problemy z używaniem równocześnie oprogramowania Certum i KIR, ponieważ
obie aplikacje zawłaszczają sobie rozszerzenie SIG.
Problemy te brzmią niepoważnie w XXI wieku, kiedy cały świat zmierza w kierunku
otwartych standardów i wzajemnej kompatybilności.
Internet wielokrotnie przechodził boje o kompatybilność („wojny przeglądarek” –
HTML, SSL vs PCT, IPSec vs PPTP i inne) i na dzień dzisiejszy nawet Microsoft w
dużym stopniu stosuje się do powszechnie uznanych standardów (standardowy HTML w
MSIE, migracja do XML w MS Office).
Kolejnym problemem jest również narzucenie systemu Windows jako obowiązkowego
elementu „bezpiecznego urządzenia” – ponieważ centra certyfikacji dostarczają
„oprogramowanie podpisujące” tylko pod ten system. Jest to sprzeczne z ideą
neutralności technologicznej państwa i powtarza np. znany konflikt wokół Płatnika ZUS.
Z drugiej strony warto pamiętać, że Windows stanowi nadal większość desktopów w
biznesie i robienie tutaj czegoś na siłę również jest błędem (więcej na ten temat w
rozdziale Rozwiązania).
Poza tym całe prawodawstwo podpisu elektronicznego jest oparte o powszechnie
dostępne standardy. Zamieszanie wprowadzono dopiero na najniższym poziomie,
formatów plików – zastosowano kilka niekompatybilnych standardów.
Zamieszanie wprowadzono w naszym rozporządzeniu dopuszczając trzy
niekompatybilne formaty i dając centrom certyfikacji swobodę ich wyboru. A te wybrały
sobie po jednym formacie, każde inny.
Jaki format wybierze administracja i dlaczego wszystkie cztery?
W kontekście planowanego wprowadzenia podpisu elektronicznego do administracji
publicznej nasuwa się kilka pytań:




którego z czterech dostawców, a co za tym idzie, który format wybierze
administracja publiczna?
czy każda jednostka administracji publicznej wybierze tego samego dostawcę,
czyli ten sam format?
co będzie się działo jeśli różne organy administracji wybiorą różnych
dostawców?
i, co gorsza, co będzie się działo jeśli te same organy w różnych miejscach
wybiorą różnych dostawców?
Najgorszy możliwy scenariusz jest taki, że do 16. sierpnia nie stanie się nic (czas w
pewnym sensie działa na rękę centrom certyfikacji) i po tym dniu będziemy mieli na
przykład następujące możliwości:




kupić certyfikat i zestaw do podpisu w Certum, żeby wysyłać PIT do urzędu
skarbowego w Rzeszowie (ale już np. Katowice będzie obsługiwać KIR),
kupić drugi certyfikat i zestaw do podpisu w Sigillum, żeby złożyć wniosek o
ścięcie drzewa na posesji w naszej gminie (ale już sąsiednią obsługuje np. Signet),
kupić trzeci certyfikat i zestaw do podpisu w KIR, żeby wysłać przelew bankowy
(KIR raczej nie ma konkurencji w bankach),
kupić czwarty certyfikat i zestaw do podpisu w Signecie, żeby wysłać wniosek o
wymianę prawa jazdy w urzędzie wojewódzkim; i tutaj się okaże, że na jednym
komputerze to nie zadziała, bo program Signetu koliduje z programem Certum
(oba wykorzystują rozszerzenie SIG).
Taka segmentacja rynku leży w pewnym sensie w interesie centrów certyfikacji, bo
zamiast jednego zestawu część instytucji będzie musiała kupić wszystkie cztery (patrz
poniżej rozdział „Dojna krowa”).
Ale to zadziała tylko pod jednym warunkiem – że uda się właśnie zmusić rynek do
wykorzystywania podpisu elektronicznego w wyżej wymienionych zastosowaniach.
Bez przymusu prawnego nikt kto kieruje się przesłankami ekonomicznymi i wygodą nie
będzie się nawet zastanawiał nad wykorzystaniem podpisu elektronicznego w tak
skomplikowanej postaci.
Podpis elektroniczny nie jest gadżetem, który wprowadzamy żeby móc się bawić kartami
i wpisywaniem kodów. Jego stosowanie musi być uzasadnione ekonomicznie przede
wszystkim klientom. W obecnej sytuacji prościej i taniej będzie pójść na pocztę albo
odstać swoje w kolejce do urzędu.
Faktury elektroniczne – kwalifikowany vs niekwalifikowany
Jednym z kroków mającym na celu zmuszenie przedsiębiorców do korzystania z podpisu
elektronicznego było przeforsowanie rozporządzenia o fakturach elektronicznych w
wersji narzucających ich zabezpieczenie za pomocą podpisu kwalifikowanego.
Alternatywą było skorzystanie z podpisu niekwalifikowanego.
Rozporządzenie to zostało wydane latem 2005 roku i wzbudziło – właśnie z tego powodu
– wiele kontrowersji. Interesujący fragment brzmi tak:

Faktury mogą być wystawiane (…) w formie elektronicznej pod warunkiem że
(…) będą zagwarantowane bezpiecznym podpisem elektronicznym (…)
weryfikowanym przy pomocy ważnego kwalifikowanego certyfikatu. (par 4 pkt
1)
Dyrektywa Rady Europy nr 2001/115 mówi o tym tak:

Państwa Członkowskie dopuszczają wysyłanie faktur drogą eletroniczną, pod
warunkiem że autentyczność pochodzenia i integralność treści są zagwarantowane
bezpiecznym podpisem elektronicznym; jednakże Państwa Członkowskie mogą
zażądać, by bezpieczny podpis elektroniczny był oparty na certyfikacie
kwalifikowanym i złożony przy użyciu bezpiecznego urządzenia do składania
podpisu (art. 2, pkt 2 i tam pkt 3 podpunkt c)
Użycie określenia „bezpieczny podpis” zamiast obecnego w angielskim oryginale
„advanced signature” prowadzi do nieporozumień.
We wspomnianym wyżej dokumencie „E-faktury: fakty i mity” Certum argumentuje:

Dyrektywa Unijna wskazuje jako podstawowe formy uwierzytelnienia EDI i
bezpieczny podpis elektroniczny (pkt 1, trzeci akapit)
Jest to prawda. Ale już milczące założenie, że „bezpieczny podpis” to to samo co
„bezpieczny podpis oparty o certyfikat kwalifikowany” jest fałszywe (Certum nie
cytuje oryginalnego brzmienia dyrektywy, bo błąd byłby od razu widoczny).
Tymczasem można dopuścić „bezpieczny podpis” niekwalifikowany i wystawiać
faktury elektroniczne o wiele taniej i cały czas pozostając w zgodzie z dyrektywą.
Z dyrektywy wynika, że stosowanie podpisu kwalifikowanego jest opcjonalne, a nie
obowiązkowe. Nie można więc sprowadzać dyskusji do argumentu „Unia nam kazała”.
Zgodnie z wymową Dyrektywy większość państw europejskich zdecydowała się na
podpis niekwalifikowany pod fakturami elektronicznymi:


Wymagają podpisu kwalifikowanego – Czechy, Hiszpania, Włochy, Niemcy
Nie wymagają podpisu kwalifikowanego – Wielka Brytania, Belgia, Francja,
Irlandia, Norwegia, Austria, Dania, Estonia, Finlandia, Węgry, Luksemburg,
Słowacja, Szwecja, Holandia
Co więcej, podpis kwalifikowany np. w Czechach – jak pisałem wyżej – jest praktycznie
równoważny naszemu niekwalifikowanemu.
Dopuszczenie certyfikatu niekwalifikowanego do wystawiania faktur pozwalałoby na
stosowanie do ich wystawiania popularnych narzędzi takich jak MS Office, OpenOffice,
MS Outlook i Mozilla (wszystkie obsługują podpis elektroniczny).
Nic nie stałoby na przeszkodzie, żeby do tego celu kupić certyfikat w polskich centrach
certyfikacji. W obecnej sytuacji trzeba te narzędzia pisać od zera posiłkując się drogimi
bibliotekami sprzedawanymi przez centra certyfikacji (patrz dalej „Dojna krowa”).
Jak zauważył prof. Kutyłowski, fakt że udało się przeforsować wariant z podpisem
kwalifikowanym byłby sporym ograniczeniem, gdyby nie drobny szczegół – nikt
przecież nie zmusza nas do stosowania faktur elektronicznych jako takich.
I dlatego biznes zareagował na faktury elektroniczne tak jak zareagował, to znaczy
zignorował je i czeka aż staną się opłacalne.
Administracja publiczna – dojna krowa
Głównymi „ofiarami” niekompatybliności formatów stosowanych przez polskie firmy
certyfikacyjne nie będzie wbrew pozorom biznes.
Głównymi przegranymi będą urzędy administracji publicznej, w tym urzędy przyjmujące
od petentów wnioski w formie elektronicznej oraz urzędy skarbowe sprawdzające
faktury elektroniczne. W obecnym stanie prawnym od 16. sierpnia 2006 roku będą miały
one prawny obowiązek przyjmować dokumenty podpisane elektronicznie.
Oznacza to ni mniej ni więcej, że wszystkie stosowane obecnie w administracji
publicznej systemy wymiany dokumentów muszą się do tego czasu przystosować do
przyjmowania nie jednego, wybranego formatu, ale wszystkich „legalnych”
formatów.
Sygnały docierające z rynku świadczą o tym, że takie działania mają już miejsce. Część
firm produkujących oprogramowanie do zarządzania dokumentami zaczynają lub już
zaczęły wdrażanie obsługi kilku formatów wybranych przecież arbitralnie wedle
uznania centrów certyfikacji.
Zamiast komentarza przytoczę wypowiedź jednego z moich Czytelników:

Moja firma właśnie oprogramowuje podpis Sigillum i Certum w aplikacji do
obiegu dokumentów. Oprogramowaliśmy Certum ale działa pod Windowsem i
niestety używa jedynie słusznej przeglądarki. Sigillum podobno działa [ale] ich
kontrolka za żadne grzechy nie chce się uruchomić. Co do wieloplatformowości możemy zapomnieć. Co do bezpiecznego urządzenia i oprogramowania
-bezpieczne oprogramowanie to takie które używa np. bibliotek
kryptograficznych jednego z czterech wystawców. Jest mały problem – te API
jest pisane w Visual Basicu , kontrolki to jest ActiveX a o Javie to panowie nie za
bardzo chcą gadać. Poza tym API jest w postaci windowsowych DLL-ek. A teraz
killer na koniec - API Unizeto kosztuje 4700 pln netto, a każdy runtime Sigillum
900 zł netto, bez dodatkowych opłat. Pytanie dlaczego taka rozbieżność w cenie?
PS: ale i tak mi to nie przeszkadza aby sprzedawać i zarabiać kasę na podpisie
elektronicznym najgorsze jest to ze urzędnicy nie wiedzą co z tym zrobić ..
W prywatnych rozmowach z przedstawicielami kilku urzędów szczebla wojewódzkiego
oraz powiatowego jest całkowicie zgodny z cytowaną wyżej opinią, że urzędnicy „nie
wiedzą co z tym robić”. Co więcej, na zadawane przez nich pytania jednoznacznej
odpowiedzi nie potrafią udzielić nawet odpowiednie ministerstwa.
Widziany przez moich rozmówców obraz przyszłego systemu przyjmowania
dokumentów elektronicznych zgodnego z aktualnych prawodawstwem obejmuje:






oddzielny system komputerowy przyjmujący dokumenty elektroniczne z
zainstalowanymi wszystkim czterema aplikacjami do weryfikacji podpisu,
ręczną weryfikację podpisu i rozpakowanie podpisanego dokumentu w celu
„wpuszczenia” go do natywnego systemu przetwarzania dokumentów
stosowanego w danej instytucji,
przeszkolenie pracownika, który będzie się zajmował akceptacją tych
dokumentów w zakresie obsługi wszystkich czterech aplikacji,
ze względu na konflikt między programami KIR i Certum - wywoływanie tej
właściwej metodą prób i błędów,
nie za bardzo wiadomo co robić z dokumentami SDOC (Sigillum), mają formę
graficzną,
nie wiadomo czy urząd ma obowiązek odpowiedzieć w formie elektronicznej z
podpisem tej samej firmy, której używa petent (co oznacza, że każdy urząd
musiałby kupić cztery zestawy do podpisu).
Oczywiście, wszystko to za pieniądze publiczne. Wdrożenie podpisu elektronicznego
w administracji publicznej w obecnej formie będzie usankcjonowanym prawnie
marnotrawieniem pieniędzy publicznych na ogromną skalę!
Rozwiązania
Rozwiązanie opisanych problemów można osiągnąć na dwa sposoby:


Radykalnie liberalizując prawo przez likwidację rozporządzenia o warunkach
technicznych tak, by jedynym obowiązującym zbiorem wymogów była ustawa.
Zaowocuje to gwałtownym wzrostem stosowania podpisu składanego przy
pomocy powszechnie dostępnych narzędzi. Ale wówczas głównym składnikiem
bezpieczeństwa podpisu będzie bezpieczeństwo prawne, wynikające z procedur
stosowanych przez centra certyfikacji podczas wydawania certyfikatów
kwalifikowanych. Bezpieczeństwo techniczne będzie mniejsze, ze względu na
dopuszczenie popularnych systemów operacyjnych jako urządzeń do składania
podpisu. Analogiczny model obowiązuje obecnie w Czechach i sprawdza się w
praktyce, jednak jego faktyczne bezpieczeństwo techniczne i prawne jest niższe
od naszego w teorii. Inna sprawa, że jest takie same jak nasze obecne w
praktyce.
Pozostawiając obecny, bezpieczniejszy model podpisu uregulowanego
technicznie w najdrobniejszych szczegółach, ale uzdrawiając istniejące w nim
obecnie niekonsekwencje, które wprowadzono dla obniżenia kosztu bezpiecznych
urządzeń. Naszym zdaniem jest to jest właściwy kierunek.
Każdy z wyżej wymienionych problemów techniczno-prawnych można rozwiązać za
pomocą odpowiedniej nowelizacji ustaw i rozporządzeń oraz działań ze strony czterech
firm, które faktycznie skupiają w sobie władzę nad tym segmentem rynku.
Celem powinno być upowszechnienie podpisu elektronicznego na taką skalę, by
przynosił on realne oszczędności stosującym go podmiotom gospodarczym oraz zaczął
przynosić zyski centrom certyfikacji, które jak się wydaje na razie dokładają do tego
interesu.
Realizacja tego metodą „siłową” (nakazywanie korzystania z podpisu drogą prawną) jest
błędną ścieżką, ponieważ pogłębi tylko chaos panujący w polskim prawie regulującym
działalność gospodarczą. Biznes kupi tylko minimalną wymaganą prawem ilość
certyfikatów i potraktuje to jako kolejny podatek. Administracja będzie zmuszona do
zmarnowania gigantycznych ilości pieniędzy nie osiągając żadnej korzyści, bo petenci
nadal nie będą korzystali z podpisu. I tak podpis pozostanie martwy, tak jak dzisiaj.
Podejmowane kroki powinny być koordynowane z analogicznymi inicjatywami w Unii
Europejskiej. Zwłaszcza po to, żeby wkrótce nie okazało się że w Unii jest nie jeden a
kilkanaście podpisów elektronicznych – polski, niemiecki, estoński itd, wzajemnie
niekompatybilne.
Koordynacja powinna polegać na obserwowaniu i analizowaniu tych rozwiązań za
granicą (co częściowo wykonałem), a także na lobbowaniu za granicą za przyjęciem
wspólnych standardów. Jak pokazuje praktyka, na podstawie jednej spójnej dyrektywy
można wyprodukować nieskończoną liczbę technicznie niekompatyblinych rozwiązań.
.
Bezpieczne urządzenie do podpisu
Przyczyna dla której powstało „bezpieczne urządzenie do samodzielnego montażu” była
wyłącznie ekonomiczna - by nie ograniczać „bezpiecznego urządzenia” do ścisłej
definicji oznaczającej po pierwsze „urządzenie” a po drugie „bezpieczne” - jedno i drugie
w powszechnym rozumieniu (czyli coś na wzór małego bankomatu).
Spowodowałoby to oczywiście podniesienie jego ceny i w rezultacie o masowym
kupowaniu certyfikatów i składaniu podpisów nie byłoby mowy. Dlatego, chcąc złapać
dwie sroki za ogon, stworzono „tanie bezpieczne urządzenie”, które jednak nie jest ani
tanie, ani bezpieczne.
W szczególności nie jest odporne przeciwko technikom ataków stosowanym
współcześnie na masową skalę. W 2001 roku, kiedy rozporządzenie powstawało ten
problem mógł nie być aż tak widoczny, chociaż już wtedy wskazywano na jego istnienie
(prof. Kutyłowski). Głosy te zostały zignorowane, a z czasem okazało się powstanie
„taniego bezpiecznego urządzenia” wcale nie doprowadziło do upowszechnienia podpisu.
Spowodowało za to duży problem z bezpieczeństwem (wskazany przez G DATA).
Kroki, jakie powinniśmy podjąć dla naprawienia tej sytuacji zależą od tego jakiego
„bezpiecznego urządzenia” oczekujemy na rynku. To co mamy obecnie jest
niedopuszczalne, ponieważ nie zapewnia podstawowego bezpieczeństwa przeciwko
atakującym dysponującym minimalnymi środkami technicznymi.
Celem tej analizy nie jest opracowanie projektu bezpiecznego urządzenia. Można jednak
wskazać wymagania praktyczne, jakie powinno takie urządzenie spełniać poza tymi,
określonymi w ustawie.
Z rozporządzenia powinny zniknąć mętne zapisy o „oprogramowaniu publicznym” i
„niepublicznym” ponieważ kompromitują one polskie ustawodawstwo techniczne.
Redukują one bezpieczeństwo SSCD do faktycznego stanu jakim dysponują np. Czesi
mając tylko ustawę, bez żadnych dodatkowych rozporządzeń. Równocześnie niebywale
komplikują prawo i finalne rozwiązania techniczne.
Bezpieczne urządzenie powinno podlegać certyfikacji jako całość a nie w rozbiciu na
komponent programowy i sprzętowy. Ze względu na to, że certyfikacja formalna
(Common Criteria, ITSEC) jest procesem bardzo kosztownym i długotrwałym lepszym
rozwiązaniem jest wprowadzenie obowiązku nie certyfikacji, ale oceny bezpieczeństwa
w metodologii testu penetracyjnego. Daje on, przy znacznie niższej cenie, wysoki
poziom praktycznego bezpieczeństwa.
Bezpieczne urządzenie musi być tworem istniejącym fizycznie, przewidywalnym i
jednoznacznym. W szczególności bezpieczeństwo SSCD nie może zależeć od sposobu
jego instalacji przez użytkownika, dodatkowego oprogramowania którym dysponuje,
jego wiedzy i umiejętności zabezpieczenia systemu operacyjnego.
Równocześnie bezpieczne urządzenie powinno pozostawać w klasie cenowej
porównywalnej z dotychczasowymi komponentami podpisu – maksymalnie kilkaset
złotych, a nie kilkanaście tysięcy. Oczywiście, im taniej, tym lepiej.
Bezpieczne urządzenie powinno umożliwiać podłączenie do sieci. Jest to potrzebne co
najmniej do znakowania czasem i pełnej weryfikacji podpisu, włącznie ze sprawdzeniem
całej ścieżki i ważności certyfikatów po OCSP lub CRL. Są to warunki pełnej weryfikacji
podpisu kwalifikowanego. Należy sobie zdawać sprawę z tego, że podłączenie
urządzenia do sieci oznacza że z założenia powinno ono spełniać znacznie wyższe
standardy bezpieczeństwa (system operacyjny, stos TCP/IP) niż urządzenie działające
bez sieci.
Wszystkie urządzenia powinny implementować przynajmniej jeden, wspólny format
podpisu. Kwestie te są omawiane szczegółowo w następnym rozdziale.
Zdaję sobie sprawę, że powyższa lista brzmi jak koncert życzeń. Jest to lista wymagań,
jakie powinno spełniać bezpieczne, tanie i wygodne urządzenie do podpisu. Zadaniem
inżynierów jest wymyślenie i zaimplementowanie takiego urządzenia.
W żadnym wypadku nie są to jednak mrzonki.
Wiem przynajmniej o kilku zespołach projektujących rozwiązania techniczne, które
spełniają przynajmniej większą część tych wymagań. Niestety nie znam szczegółów tych
projektów lub w części przypadków nie zostałem upoważniony do ich ujawniania.
Wszystkie ze znanych mi projektów mają być i tanie, i bezpieczne, i przede wszystkim
po prostu „używalne”. Świadczy to o tym, że stworzenie takiego urządzenia jest w
praktyce możliwe, o czym mam nadzieję przekonamy się w ciągu kilku najbliższych
miesięcy. Jest to również odpowiedź na zarzuty centrów certyfikacji, które twierdzą, że
krytycy obecnego stanu rzeczy nie mają lepszego pomysłu.
Formaty podpisu elektronicznego
Rozwiązaniem aktualnej sytuacji, w której na rynku istnieją cztery prawnie
usankcjonowane ale niekompatybline formaty jest zmiana rozporządzenia o warunkach
technicznych, które usankcjonuje jeden format jako obowiązkowy format do
stosowania przez administrację publiczną:



zapewni to kompatybilność tam gdzie ona jest niezbędna,
przez narzucenie jednego formatu administracji, wskaże się format preferowany
dla rozwiązań, które nie mają innych specyficznych wymogów,
równocześnie nie narzuci się sztucznych i nieuzasadnionych wymogów co do
formatów biznesowi, który może mieć inne potrzeby w określonych
zastosowaniach.
Istnieje możliwość że centra certyfikacji dogadają się między sobą i ustalą jeden,
wspólny format w celu „ruszenia” rynku, bo leży to w ich interesie. Wymagałoby to
jednak współpracy czterech dużych firm, które mogą mieć przeciwstawne interesy w
sytuacjach kiedy to właśnie brak kompatybilności z innymi wpływa dodatnio na ich
zyski. W rezulacie jest to mało prawdopodobne.
PKCS7, CMS, XML
Jeśli chodzi wybór konkretnego formatu to należy wziąć pod uwagę następujące
czynniki:



format PKCS#7 jest najstarszy i najuboższy funkcjonalnie, nie pozwala na
przykład na dołączanie znacznika czasowego;
format CMS (Cryptographic Message Syntax, ETSI TS 101 733) zawiera pełny
zestaw funkcji wykorzystywanych obecnie do podpisu elektronicznego; jest to
format binarny;
format XML (XAdEs, ETSI TS 101 903) jest funkcjonalnie równoważny CMS;
jest formatem opartym o składnię XML.
Jak widać CMS i XML są równoważne funkcjonalnie.
Jedyną wadą formatu XML jest narzut objętości dochodzący maksymalnie do 30%
wynikający z kodowania ciągów binarnych jako ASCII.
Format XML (XAdEs)
Format XML jest chętniej wybierany do zastosowań wymagających kompatybilności
między różnymi systemami, ze względu na następujące zalety:


w większości stosowanych współcześnie systemów przetwarzania informacji
XML jest podstawowym formatem zapisu danych,
jako format tekstowy XML nadaje się do bezpośrednich wydruków, a następnie
skanowania,

istnieją otwarte (open-source) i darmowe (GPL) implementacje praktycznie
wszystkich operacji na XML, włącznie z kwalifikowanym podpisem
elektronicznym.
Druga z wymienionych cech została wykorzystana w Austrii do wdrożenia systemu
elektronicznej publikacji prawa, które docelowo ma być publikowane wyłącznie w tej
formie z podpisem elektronicznym. Każdy dokument zawiera nagłówek XML
zawierający podpis elektroniczny ustawodawcy. Podpis nie przepada po wydrukowania
tekstu ustawy, ponieważ można go ponownie zeskanować (każda linia zawiera sumy
kontrolne dla OCR) i zweryfikować w formie elektronicznej.
Estonia, najbardziej zaawansowana w Europie pod względem wdrożenia podpisu
elektronicznego, zbudowała kompletny system kwalifikowanego podpisu również
opartego o format XML i udostępniła go na darmowej licencji LGPL (projekt
OpenXAdEs). Dzięki temu dodanie tej funkcjonalności do już istniejących aplikacji
będzie się wiązało z minimalnym nakładem finansowym.
Format XAdEs jest również kompatybilny z innymi rozwiązaniami przyjętymi jako
standardowe formaty wymiany danych w polskiej administracji publicznej – na przykład
dokumentami OASIS OpenDocument.
Dodajmy jeszcze, że z informacji w programie do podpisu oferowanym przez Signet
wynika, że wykorzystuje on kod projektu OpenXAdEs.
Który format najlepszy?
Formatem zapewniającym najlepszą kompatybilność będzie XML XAdEs. Jest to
również format zgodny z rozporządzeniem o mimimalnych wymaganiach dla systemów
informatycznych do ustawy o informatyzacji. Rozporządzenie to mówi wprost o formacie
XML i XML-DSig, które są kompatybilne z XAdEs.
Jak pisałem powyżej, mogą istnieć inne argumenty za innymi formatami, które
spowodują że one będą lepsze. Nie ma to większego znaczenia który, grunt żeby
obowiązkowy format był jeden.
Inne formaty mogą funkcjonować równolegle w zależności od potrzeb (jestem pewien że
SDOC został wprowadzony jako rozwiązanie dla jakiejś konkretnej potrzeby), ale
standard obowiązkowy – zwłaszcza w administracji publicznej – musi być jeden.
Chciałbym podkreślić jeszcze raz: nie jest tak istotne który format zostanie wybrany,
krytyczne jest to żeby był to jeden format na terenie Polski, a jeszcze lepiej – jeden
format na terenie Unii. Warunki te w największym stopniu spełnia format XML.
Server Based Signature Services
Rozwiązaniem, które w znacznym stopniu zlikwidowałoby szereg wymienionych wyżej
problemów z kompatybilnością oraz przenośnością systemów do weryfikacji i składania
podpisu elektronicznego jest weryfikacja podpisu za pomocą usług webowych.
Usługi webowe – czyli w uproszczeniu aplikacje uruchamiane przez klienta na zdanym
serwerze, w których protokołem komunikacyjnym jest HTTP, XML i pochodne (SOAP,
WSDL) są obecnie technologią wykorzystywaną powszechnie w aplikacjach
biznesowych. Do interakcji z użytkownikiem może służyć standardowa przeglądarka
WWW, aplikacja łącząca się po SOAP („rich client”) lub nawet telefon komórkowy czy
PDA („thin client”).
Udostępnienie weryfikacji podpisu przez usługi webowe umożliwiłoby:



dostęp do usługi weryfikacji niezależnie od systemu operacyjnego czy języka
programistycznego; wystarczyłaby tylko specyfikacja danej usługi webowej
zapisana zgodnie ze obowiązującymi standardami (SOAP i WSDL są
wymienione w rozporządzeniu o minimalnych wymogach do systemów
informatycznych do ustawy o informatyzacji),
ułatwienie integracji podpisu elektronicznego z istniejącymi aplikacjami
biznesowymi (np. finansowo-księgowymi) czy stosowanymi w administracji
publicznej (np. obieg dokumentów),
podniesienie poziomu bezpieczeństwa procedury weryfikacji, ponieważ jej
kluczowe funkcje byłyby wykonywane fizycznie po stronie usługodawcy
(centrum certyfikacji).
Weryfikacja podpisu za pomocą usług webowych jest szczególnie istotna w przypadku
podpisu kwalifikowanego, którego pełna weryfikacja wymaga obszerniejszej procedury,
m.in. ze względu na potwierdzenie ważności certyfikatów. Zagadnienia te szczegółowo
omawia Jacek Pokraśniewicz z firmy ENIGMA w prezentacji
http://www.enigma.com.pl/pliki/publikacje/prezentacjaISecMan.pdf.
Równocześnie warto zauważyć, że to co wydaje się być najpoważniejszą barierą w
przypadku weryfikacji za pomocą usług webowych – konieczność dostępu do sieci –
wcale nią nie jest. W pełni poprawna weryfikacja podpisu elektronicznego, włącznie ze
znacznikiem czasu i ważnością certyfikatu (po CRL lub OCSP), również wymaga
dostępu do sieci w momencie weryfikacji.
Język rozporządzenia
Rozporządzenie takie jak rozporządzenie o warunkach technicznych nie może
posługiwać się językiem pozostawiającym jakiekolwiek wątpliwości.
Sformułowanie „komponent powinien mieć certyfikat” pozostawia takie wątpliwości ze
względu na nie dostatecznie silny nakaz w słowie „powinien”, które w języku polskim
oznacza „dobrze by było gdyby miał, ale nie musi”. Zamiast tego należy napisać, że
„komponent musi mieć certyfikat”.
Opisane rozwiązanie jest spotykane w standardach technicznych Internetu (RFC), które
często posługują się sformułowaniami w rodzaju: „implementacja protokołu XYZ zawsze
MUSI obsługiwać format ABC, POWINNA obsługiwać format DEF i MOŻE
obsługiwać GHJ”.
Zakończenie
Omówione wyżej propozycje rozwiązania aktualnych problemów podpisu
elektronicznego zostały przedstawione w oficjalnym stanowisku ISOC-PL.