ad-m
commented
4 years ago Standardowy protokół dla walidacji podpisu – OASIS DSS Standardowy protokół dla walidacji certyfikatu – XKMS
Open ad-m opened 4 years ago
ad-m
commented
4 years ago Standardowy protokół dla walidacji podpisu – OASIS DSS Standardowy protokół dla walidacji certyfikatu – XKMS
ad-m
commented
4 years ago Na https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation jest usługa EU do weryfikacji podpisu. Na https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_validate_a_document jest dokumentacja jej REST API. Co ważne, tworzy to nam strukturę API. Na https://github.com/esig/dss mamy kod źródłowy tej usługi sieciowej.
W takim przypadku wygląda na to, że najlepiej całą złożoność weryfikacji podpisów zamknąć w web-servicie w dodatkowym kontenerze w Javie, a my będziemy się z nią jedynie komunikować.
Uwagi ogólne
Dla zwykłych użytkowników nie jest łatwym poprawne zweryfikowanie podpisu elektronicznego ze względu na mnogości formatów. Przeprowadzona weryfikacja podpisu elektronicznego wymaga także zwykle interpretacji prawnej. Weryfikacja podpisu elektroniczne jest istotna ze względu na skutki prawne podpisu złożonego pod dokumentami.
Możemy spotkać się przede wszystkim z formatami:
Zarysowanie problematyki podpisu kwalifikowanego dostępne na https://epodrecznik.mc.gov.pl/mediawiki/index.php?title=Podpis_kwalifikowany .
Weryfikacja *aDeS
Podpis *aDeS opiera się na tzw. zaufanej trzeciej strony tzn. centrum certyfikacji. W przypadku podpisów o skutkach prawnych wywołujących prawne musimy zweryfikować czy jest to uznane centrum.
Wymagania prawne są narzucone przez rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE.
Weryfikacja PaDeS
W tym zakresie mamy bibliotekę "endesive" ( https://github.com/m32/endesive/ ). Wymaga ona rozwoju co najmniej w zakresie:
W zakresie prezentacji możemy się zainspirować na przykład https://weryfikacjapodpisu.pl/ .
Składałem takie podpisy, jak również niejednokrotnie weryfikowałem.
Weryfikacja XaDeS
W tym zakresie mamy bibliotekę endesive ( https://github.com/m32/endesive/ ).
W tym zakresie konieczne jest zwrócenie, że możemy mieć dwa pliki, gdzie oba będą wymagane do podpisu elektronicznego.
Składałem takie podpisy, jak również niejednokrotnie weryfikowałem.
Weryfikacja S/MIME
W tym zakresie nie analizowałem bibliotek, jednak mam doświadczenie z automatycznym podpisem z wykorzystaniem S/MIME w NodeJS. Rozwiązanie nie jest prawne, więc nie jest tak istotne dla Stowarzyszenia.
Podobnie jak HTTPS nie mamy jednoznacznej listy zaufanych centrów, a wiele podmiotów tworzy własne. Możemy bazować na listach zaufanych przez programy pocztowe np. GMail (lista dostępna na https://support.google.com/a/answer/7448393?hl=pl&ref_topic=9061730 ). Warto dostrzec, że większość programów pocztowych skutecznie prezentuje informacje na temat poprawności podpisu:
Składałem takie podpisy, jak również niejednokrotnie weryfikowałem.
Interpretacja *aDeS
Podpis kwalifikowany (Profil Zaufany) umożliwia złożenie podpisu elektronicznego wywołującego skutki prawne. Pozostałe formy takich skutków nie wywołują.
Istotne w interpretacji jest:
Pomijamy w tym miejscu m. in. weryfikację unieważnienia certyfikatów i kwalifikowane znaczniki czasu.
Osobiście mogę dostarczyć eksperckiej wiedzy technicznej prawnej w tym zakresie. Mam także doświadczenie jako świadomy użytkownik każdej z form podpisów. Nie mam jednak pełnego doświadczenia w zakresie implementacji tych narzędzi kryptograficznych.
W przypadku wykorzystania usług API do weryfikacji podpisu jesteśmy ograniczeni ochroną poufności danych w Stowarzyszeniu, więc wymaga to rozważenia. Możemy się w tym zakresie skontaktować np. z https://weryfikacjapodpisu.pl/cooperation .