Urzędowe poświadczenie odbioru w formacie PDF

W chwili obecnej Urzędowe poświadczenie odbioru (UPO) jest generowane przez skrzynki podawcze (ESP) różnych dostawców z tym samym zamiłowaniem do chaosu, jakie cechuje formaty podpisu elektronicznego od początków polskiej informatyzacji. W jaki sposób można to uporządkować pozostając w ramach obowiązującego prawa?

Otóż proszę pamiętać, że rozporządzenie które wprowadziło pojęcie ESP i UPO (Dz. U.05.200.1651) nie korzysta z bezpiecznego podpisu elektronicznego, tylko stosuje własną, niejako - jak to określił na niedawnym spotkaniu PTI prezes Paluszyński - wprowadzając tylnymi drzwiami zaawansowany podpis elektroniczny do polskiego prawa.

Co to znaczy w praktyce? Przede wszystkim to, że certyfikat użyty do złożenia podpisu pod UPO nie musi być kwalifikowany i że podpis ten można składać oraz weryfikować praktycznie w dowolnym oprogramowaniu.

Autorzy znanych mi skrzynek podawczych poszli w kierunku tradycyjnie źle pojętej innowacyjności - każdy wymyślił to po swojemu. I tak, skrzynka podawcza Zeto Białystok zwraca UPO jako wymyślony przez siebie XML z podpisem w formacie XML-DSig i rozszerzeniem ZSI.

Skrzynka podawcza Certum zwraca z kolei plik w formacie S/MIME z podpisem PKCS#7 i rozszerzeniem EML. To ostatnie można uznać za rozwiązanie przenośne, bo plik taki weryfikuje bez problemu Outlook lub Thunderbird.

Ale inne rozwiązanie jest stosowane... przez banki - mBank i MultiBank od dawna wysyłają klientom mailem salda rachunków w postaci dokumentu PDF podpisanego certyfikatem VeriSign. Taki plik otwiera się bez problemu w Acrobacie i - co najważniejsze - automatycznie weryfikuje się bo certyfikat jest zaufany z punktu widzenia Windows.

W kontekście e-faktury dla zwolenników "bezpiecznego podpisu"...

Przechodząc od UPO do e-faktur, proszę się zastanowić, które z poniższych zapewni odbiorcy końcowemu wyższy poziom bezpieczeństwa faktycznego:

  • automatycznie weryfikujący się podpis w jednym pliku PDF (złożony przy pomocy certyfikatu VeriSign, GoDaddy czy innego znanego Windows),
  • niepodpisany plik PDF z e-fakturą, do którego dołączony jest drugi plik z podpisem, który trzeba ręcznie weryfikować oddzielną aplikacją (tak to jest zrobione w e-fakturze Sigillum)

Pytam, bo wczoraj na konferencji e-Dokument przedstawiciel PWPW/Sigillum bez żadnego skrępowania mówił, że "oczywiście mało kto taki podpis faktycznie weryfikuje, co najwyżej za pierwszym razem".

Na moje pytanie czy biorą pod uwagę możliwość masowej wysyłki fałszywych faktur z podmienionym numerem konta np. gdy taki system stanie się masowy (wdraża go TPSA, Tele2) odpowiedziano że "to wina użytkownika, że nie korzysta z dostarczonego zabezpieczenia" (wszystkie cytaty z pamięci).

Moje kolejne pytanie o sensowność zabezpieczenia, które wprost zniechęca do korzystania z niego pozostało bez odpowiedzi...

Comments

Comment viewing options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Select your preferred way to display the comments and click "Save settings" to activate your changes.

Cieszy mnie, że dochodzi do takich konfrontacji. Szkoda, że M.Czajka nie może inaczej mówić, nawet jeśli myśli inaczej (mam taką głęboką nadzieję) ze względów oczywistych.

Trudno się nie zgodzić z Panem P.Krawczykiem - niewątpliwie ma rację w tej kwestii.
Nie słusznie zauważył Pan M.Czajka, że Adobe ma opóźnienia w dostosowaniu swoich produktów. Jest to swoiste odwrócenie kota ogonem, ponieważ to polskie prawo w materii podpisu cyfrowego jest w dalekim polu. Dokładając też bezmyślność (i wręcz porażającą nieumiejętność przewidywania wydażeń architektów takich rozwiązań - osobny temat, nie dokońca należy tu winić pracowników), czyni całość "niezgrabnym".

Uważałbym, też z zamiłowaniem do formatu PDF. Jestem zwolennikiem rozwiązań wygodnych z punktu widzenia użytkownika. Skoro mamy do dyspozycji dwie przeglądarki (IE i FF) to całość się powinna zamykać w granicach funkcjonalnych tych aplikacji. Instalowaie Adobe Readera nie jest tu najleprzym pomysłem. Można użyć z powodzeniem do formularzy (dokumentów elektornicznych) samego XML'a (czy też wersje z podpisem XMLDSIG oraz archiwalne XADES-A) z powodzeniem wspierane przez wymienione przeglądarki. Tak naprawdę Adobe Reader potrzebuje dodatkowego plugina do poprawnej pracy, a poza tym to też jest format XML'a (w przypadku dokumentów podpisanych). W takim kontekście można Adobe postawić na równi z innymi dziwnymi (lecz mało popularnymi i nie uniwersalnymi) narzędziami proponowanymi przez polskie firmy. Oczywiście JAVA musi pozostać, bo nie można inaczej podpisać dokumentu - mając oczywiście na uwage Widnows i Linux oraz IE i FF. Kotś powie .NET. Powiem zgoda byle by działało poprawnie pod FF (tym samym pod Linuxem). Oczywiście z Linuxem jest osobny problem steroników do czytników kart:)

pozdrawiam

Z różnych dostępnych na naszym rynku rozwiązań typu "petent wysyła dane do urzędu a urząd mu odpowiada" największą używalnością wykazuje się skrzynka Certum, wdrożona w kilku urzędach czy ministerstwach.

Wskazałbym tutaj na następujące zalety, wynikające z racjonalnych decyzji podjętych przez inżynierów Certum:

  1. formularze oparte o XML i XSLT (proszę zajrzeć do źródła), weryfikacja pól robiona JavaScriptem - działa bez problemu w FF i MSIE w dowolnym systemie
  2. podpis elektroniczny robiony pluginem w Javie, która jest zdecydowanie bardziej wieloplatformowa niż .NET

Również UPO w skrzynce Certum jest zrobione rozsądnie, chociaż na pierwszy rzut oka wygląda skomplikowanie. Klient dostaje podpisanego S/MIME maila z formularzem XML ponownie podpisanym jako XML-DSig.

Wydaje mi się że ta komplikacja wynika ze słusznie wskazanego mi mailem wymogu wynikającego z rozporządzenia Dz. U. 2006.227.1664, że UPO ma mieć postać XML.

Co zasługuje na pochwałę to to, że zamiast bezmyślnie i dosłownie zaimplementować literę rozporządzenia w postaci "gołego" pliku XML tak jak to zrobiono w formacie ZSI, Certum robi to w sposób stosunkowo używalny:

  1. podpis w przychodzącym mailu jest weryfikowany automatycznie przez program pocztowy
  2. plik zwracany przez HTTP ma rozszerzenie EML, czyli przy jego "kliknięciu z dysku" patrz punkt 1
  3. wewnątrz jest zawarty formularz XML z podpisem XAdES, który nie wiem przez kogo i jak może być weryfikowany ale spełnia wymóg rozporządzenia

W przypadku e-Deklaracji problem jak mi się wydaje jest trochę inny - a mianowicie mamy do czynienia z formularzem, który musi weryfikować dane w znacznie szerszym stopniu niż prosty formularz do skrzynki podawczej. Proszę zauważyć, że występują tam liczne pola liczbowe, które muszą być przeliczane i zaokrąglane zgodnie z przepisami ordynacji podatkowej. Być może dlatego MinFin zdecydował się na zastosowanie kontenera PDF a nie aktywnego HTML.

Do tego dochodzi jeszcze kwestia zachowania kopii wypełnionego formularza. W skrzynce Certum można taki formularz zdaje się zachować w postaci pliku XML, ale nie jestem pewien jak by się to spisało w przypadku formularza o wielu polach liczbowych. W przypadku e-Deklaracji to nawet działa - księgowa wysyła mi wstępnie wypełnioną cyferkami deklarację np. VAT-7, ja dopisuję co trzeba, podpisuję i wysyłam do systemu - kontenerem jest cały czas PDF.

PDF (Portable DOCUMENT Fformat) ma bardzo wiele zalet a większość obecnie tworzonych dokumentów jest właśnie w tym formacie - przejrzyjmy strony administracji - wszystko co jest tam do pobrania zwykle jest w PDF i nie ma obaw, że ktoś dokumentu nie odczyta. Możemy skanować dokumenty do formatu PDF, możemy zapisywać do tego formatu praktycznie z dowolnej aplikacji. Co więcej możemy osadzić w nim formularz i wczytać dane XML gdy zachodzi potrzeba by dokument zawierał dane w takim formacie. Sama aplikacja natomiast potrafi zweryfikować podpis złożony pod dokumentem - więc czego nam więcej potrzeba? Mamy najpopularniejszy na świecie format dokumentu używany już powszechnie w administracji. Mamy jednocześnie format dokumentu, kontenera i aplikację zainstalowaną praktycznie na każdym komputerze na ŚWIECIE.

Pozwólmy na początek dostarczać dokumenty elektroniczne do urzędów i odbierać odpowiedzi i nie kombinujmy przy tym za mocno z wydziwianymi XMLowymi formatami itd... gdyż gołym okiem widać do czego to doprowadziło (gdyż nawet jeżeli użyjemy XML-a będziemy mieć niezły problem z formatami podpisu (nie ma nawet konkretnej implementacji Xadesa dla popularnych języków programowania a istniejące rozwiązania w ramach tego jednego standardu są między sobą niekompatybilnej), z rozszerzeniami plików (bo kto zrezygnuje z własnego), ze schematami do XMLa, warstwami prezentacji, załącznikami do dokumentów, dokumentami skanowanymi, itd można by długo wymieniać). Zapewniajmy na początek możliwość szybkiego i taniego załatwiania spraw w urzędach poprzez wysłanie/odebranie dokumentu PDF, a gdy to zadziała i przyniesie wymierne korzyści kombinujmy dalej. Zrobiła tak Belgia, Pdf jest sosowany w USA.

Jeżeli chodzi natomiast o wskazane rozporządzenie to informacja o xml w UPO znajduje się jedynie w UZASADNIENIU i co ciekawe jedynie w dokumencie znajdującym się na serwerze stowarzyszenia PEMI !!! Co ciekawe w dokumencie który znajduje się na stronach rządowych (będącym nawiasem mówiąc równiez dokumentem PDF) słowo XML wcale nie pada. Jaką więc jest zgodna z prawem interpretacja o XML w UPO??

http://isip.sejm.gov.pl/servlet/Search?todo=file&id=WDU20062271664&type=...

Na koniec inny dosyć popularny i kontrowersyjny format - OpenXML. Wg. mnie jest zgodny z ustawą bardziej niż "swojskiej roboty" rozwiązania oparte o xml. Jest to dokument XML pozwalający w dodatku na zaawansowane formatowanie z możliwością podpisania dokumentu z poziomu Microsoft Office podpisem w formacie XML-DSig. Posiada możliwość budowania formularzy z zaawansowaną walidacją opartą o XML schemę. Microsoft udostepnia narzędzia programistyczne do operowania na takich dokumentach. Jedyny problem tego formatu to fakt, że czytnik dokumentów nie jest darmowy (pomijając Word Viewer 2003 + compatybility pack) i na tym polu przegrywa z PDF.

Szkoda, że moje wypowiedzi są przytaczane bez kontekstu całości.
Pana artykuł jest mocno stronniczy i oczywiście ma na celu propagowania "jedynie słusznego" formatu PDF. Szkoda tylko, że firma Adobe z tak dużym opóźnieniem reaguje na wymagania polskiego rynku i że dopiero wersja 8.0 obsługuje elementy związane z podpisem elektronicznym zgodnym z polskim prawem.
Po pierwsze to powiedziałem, że "spodziewamy się, że nie przy każdym pobieraniu faktur użytkownicy będą weryfikować podpis" a nie, że "mało kto taki podpis weryfikuje".
Proces weryfikacji podpisu jest czasochłonny i jeżeli przy każdym otwieraniu pliku jeszcze musiałbym za każdym razem weryfikować podpis to sam Pan przyzna, będzie to dłużej trwało.
Fakt jest taki, że nie można na komputery i informatykę przenieść całej odpowiedzialności za działalność człowieka.
Jeżeli kierowca nie zapnie pasów i w czasie wypadku uderzy o kierownice będzie miał wypadek to kto za to ponosi odpowiedzialność? Użytkownik samochodu czy jego producent?
Proszę mi jeszcze powiedzieć w jaki sposób to rozwiązanie zniechęca do korzystania z niego?
Bo póki co to DRM zastosowany w PDF jest zniechęcający dla odbiorcy do zakupu publikacji wydanych w tym formacie.
PDF ma jeszcze jedną wadę jeżeli chodzi o e-faktury. Średnio się nadaje gdy ktoś chce zaimportować e-fakturę do swojego systemu FK.
Co do mBanku i Multibanku to chyba jasno udowodniłem na konferencji, że sposób realizacji tej usługi jest realizowane w sposób mało bezpieczny. I weryfikacja podpisu w trakcie otwierania dokumentu nie zabezpieczy klientów mBanku oraz Multibanku przed upublicznieniem poufnych informacji. Szkoda też, że nie wspomniał Pan o tym, że sami przedstawiciele tych banków wspomnieli, że ich klienci dobrowolnie zgadzają się na taką usługę czyli, że biorą ryzyko na siebie i że wdrożenie bardziej wyrafinowanych metod zabezpieczeń jest bardziej skomplikowane.
Oczywiście można się spierać co jest lepsze. Ale prosił bym o trochę umiaru w przypisywaniu mi słów, których nie wypowiedziałem oraz pokazywanie trochę szerszego kontekstu.
Z poważaniem
Marcin Czajka

Witam!

Dziękuję za odpowiedź. Proszę nie traktować tego komentarza personalnie - jeśli Pańska firma wprowadza na rynek określone rozwiązanie to musicie się liczyć z tym, że będzie ono komentowane, także w sposób krytyczny.

Pańską wypowiedź przytoczyłem z pamięci (co jest zaznaczone na końcu tekstu) i nie uważam by była ona przytoczona stronniczo. Jestem pewien, że sens Pańskiej wypowiedzi był taki, że dopuszcza Pan możliwość że użytkownik zweryfikuje podpis tylko za pierwszym razem, a później będzie go ignorował.

Zaproponowane przez was rozwiązanie jest obarczone zasadniczą wadą praktyczną, którą wyraziłem na konferencji i teraz powtórzę - rozdzielenie faktury na dwa pliki i wymóg stosowania do jej otwarcia dwóch aplikacji zaowocuje w naturalny sposób tym, że odbiorcy końcowi nie będą weryfikowali podpisu pod fakturami

To jest aspekt, który miałem na myśli pisząc o "zniechęceniu do korzystania z zabezpieczeń". Również dlatego spytałem na konferencji o Pańskie zdanie na temat ryzyka phishingu.

Oczywiście, że odpowiedzialność za zastosowanie danego zabezpieczenia ponosi formalnie użytkownik, ale analiza ryzyka powinna uwzględniać czynniki obiektywne takie jak naturalna skłonność do ignorowania przez użytkowników zabezpieczeń nieobligatoryjnych i równocześnie uciążliwych w stosowaniu.

Wprowadzacie Państwo do obiegu rozwiązanie, w którym zabezpieczenie jest tak uciążliwe że zniechęca do jego stosowania i robicie to ze świadomością, że będzie ono w związku z tym wybiórczo stosowane. Jest to nieuczciwe w stosunku do konsumenta, jak i podmiotu wykorzystującego system, nawet jeśli jest to zgodne z prawem.

W przypadku pojawienia się phishingu z fałszywymi e-fakturami istotnie odpowiedzialność za wykonanie przelewu na niewłaściwe konto poniesie klient, ale ostateczny koszt poniesie wystawca faktury w postaci opóźnień wpłat i konieczności obsługi sporów z klientami. Wytłumaczenie, że klient nie zweryfikował podpisu jest być może wygodnym sposobem uniknięcia odpowiedzialności, ale jednorazowym - bo taki klient raz na zawsze utraci zaufanie do firmy.

Na konferencji skrytykował Pan rozwiązanie mBanku i Multibanku polegające na wysyłaniu sald w postaci PDF podpisanych certyfikatem Verisign. Nie wspomniałem o tym, bo nie ma to związku z meritum - krytykował Pan przecież brak ochrony poufności tych sald, a nie fakt użycia certyfikatu niekwalifikowanego.

Tymczasem ich rozwiązanie jest zwyczajnie łatwe w użyciu dla konsumenta - nie wymaga instalowania dodatkowych certyfikatów, bo są one już w systemie, i podpis weryfikuje się automatycznie albo kliknięciem jednego guzika.

Ma Pan rację, że PDF średnio nadaje się do importu do systemu F-K, ale o ile zrozumiałem wcześniejszą argumentację kolegów z itBCG jest to rozwiązanie dla konsumenta, a nie B2B. Dla konsumenta jest istotna czytelność pliku, łatwość obsługi i powszechność oprogramowania.

Jeśli chodzi o "promowanie" przeze mnie formatu PDF - chciałbym z całą mocą podkreślić, że Adobe nie płaci mi w żaden sposób za promowanie ich rozwiązań. Jeśli piszę o sensowności zastosowania tego - bądź co bądź otwartego (ISO 32000) - formatu, to tylko dlatego że widze na własne oczy jak się ona sprawdza w tych konkretnych zastosowaniach praktycznych.

Stąd umieszczenie tego w kontekście mBanku i Multibanku, bo  są one dobrym przykładem że to działa, jest wygodne i zapewnia wystarczającą ochronę autentyczności i integralności.

Kwestia poufności sald jest w tym przypadku drugorzędna, bo wynika jak rozumiem z niezastosowania przez nich dostępnych mechanizmów technicznych (szyfrowanie można zrobić choćby w S/MIME) ze względu zapewne na rodzące to problemy z zarządzaniem.

Ma Pan również rację, że proces weryfikacji podpisu kwalifikowanego
jest długotrwały bo wymaga sprawdzenia całej ścieżki - ale jest to
właściwie kolejny argument na bezsensowność stosowania podpisu
kwalifikowanego w tym przypadku.

Oczywiście, w obecnej sytuacji prawnej nie mogli Państwo zrobić tego
inaczej.

Ale pozwolę sobie przypomnieć, że jeszcze w 2005 roku w
dokumencie sygnowanym przez KIR, Certum i PWPW te trzy firmy zapewniały, że podpis kwalifikowany jest dla e-faktury najlepszym rozwiązaniem.

Gracie więc państwo na ustalonych przez siebie warunkach.