Przychodzi podpis na badanie…

Musimy się zatem pogodzić, że cyfrowa rewolucja zajrzy do każdego kąta zamówień publicznych. Ale sukces operacji zależy głównie od nas, uczestników tego rynku, od tego, jak się przygotujemy.
Choć zasady komunikacji mogą się wydawać proste (ale dopiero po uważnym ich zgłębieniu i ze zrozumieniem), to jednak wciąż w praktyce popełniane są te same błędy. Zarówno przez zamawiających, jak i przez wykonawców. Przyjrzyjmy się zatem temu, co się dzieje w elektronizacji przez pryzmat czynności zamawiającego, czyli badanie plików zawierających oferty i oświadczenia. Pominiemy tu fazę zadawania pytań do treści SIWZ.

Narzędzie z ryzykami

Pierwsze zderzenie zamawiającego z twórczością wykonawcy to otwarcie ofert oraz towarzyszących ofercie dokumentów i oświadczeń, np. JEDZ. Ale żeby otworzyć plik, trzeba go w terminie otwarcia ofert najpierw pobrać z wybranego systemu do komunikacji elektronicznej na dysk swojego komputera. Do tego momentu pliki spoczywają w zasobach systemu komunikacji elektronicznej (wyjątkiem jest tu miniPortal, gdzie plik można pobrać z tego systemu od razu po jego złożeniu, ale nie można go otworzyć przed terminem otwarcia ofert).
Pierwszy problem pojawia się w przypadku użytkowników miniPortalu, który, jak wiemy, jest zintegrowany z platformą ePUAP. Zdarza się, że przekazany przez wykonawcę plik, mimo że jest odnotowany w systemie miniPortalu, to jednak fizycznie go nie ma. Problem zaczyna się, gdy nie odnajdzie się w terminie otwarcia ofert. A szukać go może tylko operator platformy ePUAP, niezależny od UZP. 

Kolejny przypadek: niemożność otwarcia pliku w trakcie publicznej sesji otwarcia. Plik jest na dysku zamawiającego, ale nie daje się otworzyć. Pisząc „nie daje się otworzyć”, mam na myśli sytuację, gdy nie można zapoznać się z treścią pliku ani sprawdzić podpisu elektronicznego w odróżnieniu od sytuacji, gdy plik da się odczytać, ale widać, że podpis jest uszkodzony. To znowu najczęściej (ale nie zawsze) przypadłość miniPortalu ze swoim systemem szyfrowania ofert. Decyzja o losach postępowania zależy od tego, co ustali zamawiający. Pytanie, jakie winien postawić sobie zamawiający, to: czy uszkodzenie pliku jest wynikiem działań wykonawcy, czy jest winą (niekoniecznie umyślną) zamawiającego. W drugim przypadku – sprawa jest jasna – unieważnienie postępowania. 

Skuteczną pomocą w rozwikłaniu tego problemu może być obliczanie sum kontrolnych dla każdego pliku składanego do systemu komunikacji. I tu przyda się trochę wyjaśnienia.

Suma kontrolna, funkcja skrótu, hash – to pojęcia znane z kryptografii i powszechnie stosowane. Spotykamy się z nimi np. przy zapisywaniu hasła w dowolnym systemie logowania. Hash pozwala na obliczenie pewnego charakterystycznego ciągu znaków (wg zadanego algorytmu, np. MD5, SHA-1, SHA-256) dla wartości wejściowej, np. dla hasła. 

Ale nikt z nas nie chce, by nasze hasła były przechowywane w postaci jawnej, bo w razie wycieku danych będą te hasła znane przestępcom. Dlatego system logowania przechowuje hash tego hasła, a nie wartość jawną. Gdy podczas logowania wpisujemy swoje hasło, system logowania oblicza hash wprowadzonego ponownie hasła i porównuje z hashem przechowywanym w pamięci. Jeżeli obie wartości są takie same, to znaczy, że hasło jest poprawne. Dlaczego metoda jest bezpieczna? Dlatego że ze skrótu nie da się odtworzyć jawnego hasła. Operacja jest jednokierunkowa. Tak jak z zupy rybnej nie da się zrobić akwarium.

Jeżeli jesteśmy przy funkcjach skrótu, to trzeba wiedzieć, że ich obliczanie jest centralnym punktem podpisu zaawansowanego, a w naszym przypadku – podpisu kwalifikowanego. Otóż w procesie podpisywania jest także obliczana funkcja skrótu dla podpisywanego dokumentu. Kompletny podpis zawiera ten skrót, czyli, przekazując podpisany dokument, przekazujemy go wraz z obliczonym w trakcie podpisywania skrótem. Operacja weryfikacji integralności dokumentu to sprawdzenie, czy podpisana treść się nie zmieniła po podpisaniu. Polega to właśnie na ponownym obliczeniu wartości skrótu, a następnie porównaniu jej z wartością obliczoną przy podpisywaniu. Wynik porównania wskazujący na to, że oba skróty są identyczne, potwierdza brak ingerencji w dokument. 

Ta sama metoda może służyć do sprawdzenia, czy badany przez zamawiającego dowolny plik, nawet niezawierający podpisu, jest tym samym plikiem, który został załadowany do platformy. Oczywiście pod warunkiem, że platforma umożliwia obliczenie takiego skrótu. W tym przypadku hash jest pewnego rodzaju uproszczonym podpisem pliku (niezależnie od tego, że treść może być też podpisana podpisem kwalifikowanym). 

Ktoś zapyta: to w jakim celu obliczać skrót dla pliku podpisanego podpisem elektronicznym, skoro sam podpis zawiera także skrót dokumentu? Zaznaczyłem wcześniej, że możemy mieć sytuację, w której nie będzie można otworzyć pliku, zatem nie dostaniemy się do podpisu. A z drugiej strony, obie operacje mają inny cel: podpis kwalifikowany zabezpiecza podpisaną treść. A hash dowolnego pliku służy do badania integralności każdego pliku, niezależnie od tego, czy był podpisany, czy nie. Z generowaniem funkcji skrótu spotykamy się także przy weryfikacji integralności dokumentu podpisanego podpisem kwalifikowanym.

Zapytasz, drogi Czytelniku, czy nie zaczynamy od ciebie oczekiwać zbyt wiele? Bo to wszystko to zupełnie nowa wiedza, bardziej z obszaru informatyki niż Prawa zamówień publicznych. Niestety, nowe narzędzia wymuszają konieczność poznania tych zagadnień. Choćby powierzchownie. Tak, by wiadomo było, gdzie szukać rozwiązań w razie problemu. I wiedzieć, że rozwiązania są możliwe.

Wracając do naszego problemu uszkodzonych plików: zamawiający musi umieć udowodnić, po której stronie jest wina. W tych czynnościach ważny jest czas. Procedura otwarcia i odczytania pliku musi się zakończyć w czasie trwania publicznej sesji otwarcia ofert, jednak zawsze tego samego dnia co termin składania ofert (na razie, po wejściu w życie nowego prawa to się zmieni). Bywa często tak, że plik nie jest uszkodzony, tylko zamawiający nie potrafi go otworzyć. Albo nie zna dobrze procedury obsługi platformy, albo wykonawca tak „sprytnie” utworzył plik, że jego otwarcie wymaga nieco większych umiejętności. I tu mała podpowiedz dla zamawiających: 

Może się zdarzyć, że plik z ofertą da się otworzyć, ale widzimy lub wydaje się nam, że treść oferty jest uszkodzona, wyświetla się niepoprawnie, nie można odczytać tej treści. Powstaje pytanie: czy to faktycznie jest uszkodzenie, czy ja nie potrafię otworzyć pliku. Ten problem należy także rozstrzygnąć w trakcie publicznej sesji otwarcia, bo przecież do protokołu z otwarcia trzeba coś wpisać. A jak wpisać wartość oferty, gdy widzimy jakieś nieznane nam znaki? Nawet jeżeli weryfikacja podpisu wypadnie negatywnie, co może wyjaśniać problem z plikiem, to znowu powstanie pytanie: kto uszkodził? Zamawiający po pobraniu na dysk czy wykonawca po podpisaniu?

Według nowego Pzp

Sytuacja zmieni się po wejściu w życie nowego Pzp, czyli od dnia 1 stycznia 2021 r. Znika publiczne otwarcie ofert. Zmienia się też korzystnie zapis dotyczący terminu otwarcia:

Art. 222. 1. Otwarcie ofert następuje niezwłocznie po upływie terminu składania ofert, nie później niż następnego dnia po dniu, w którym upłynął termin składania ofert. 

Niezwłocznie, to znaczy tak szybko, jak to możliwe. Czyli jeżeli zamawiający wyznaczy termin składania ofert jako „północ” (czemu nie?), to najbliższy niezwłoczny termin będzie około 6:00–9:00 rano dnia następnego, po rozpoczęciu pracy, gdyż po północy nikt raczej nie będzie ich otwierać. Tyle w sprawie terminu otwarcia. Ale przepis nie mówi o wyznaczeniu terminu otwarcia, ale o otwarciu ofert. Ustawodawca, znając problemy z plikami, daje zamawiającym kolejny dzień na uporanie się z potencjalnymi problemami towarzyszącymi otwarciu.

Jest tu jeszcze jeden prezent:

Art. 222. 2. Jeżeli otwarcie ofert następuje przy użyciu systemu teleinformatycznego, w przypadku awarii tego systemu, która powoduje brak możliwości otwarcia ofert w terminie określonym przez zamawiającego, otwarcie ofert następuje niezwłocznie po usunięciu awarii. 

Wiele osób interpretuje ten zapis w taki sposób, że jak będzie problem z otwarciem pliku, to termin otwarcia można sobie w każdej sytuacji przesunąć. Niestety nie. Można to zrobić, jeżeli otwieramy pliki za pomocą jakiegoś systemu teleinformatycznego i ten system nam np. wyświetli zawartość ofert lub po prostu nie możemy pobrać z tego systemu pliku i zapisać na nasz dysk, by go następnie otworzyć. Jeżeli plik jest już na dysku i nie daje się otworzyć, to ten przepis nie działa.

Przypadek, gdy plik daje się otworzyć i odczytać, jednak podpis jest uszkodzony, nie wchodzi już do puli problemów na sesji otwarcia. Skoro możemy odczytać treść oferty, to trafi ona do protokołu z otwarcia. Natomiast ocena, czy taka oferta jest ważna, będzie przedmiotem badań zamawiającego. 

Wykonawcy, których pliki są uznane za uszkodzone, powinni oczekiwać od zamawiającego solidnego uzasadnienia technicznego.

I w ten sposób dochodzimy do kompleksowego badania ofert, wniosków, JEDZ i innych dokumentów i oświadczeń, które powinny być podpisane podpisem kwalifikowanym. Z punktu widzenia procedury badania nie jest istotne, co zawiera plik. Z punktu widzenia konsekwencji uznania, że podpis jest nieprawidłowy – tak. A to dlatego, że wszelkie wady w ofercie są w zasadzie nieuzupełnialne i niepoprawialne. 
Co do innych dokumentów i oświadczeń, to mamy drogę ratunkową w postaci art. 26 ust 3/3a/4 Pzp, czyli można prosić o podesłanie prawidłowego dokumentu lub wyjaśnienia. Jaki jednak dokument będzie prawidłowy? Zamawiający, który takimi wezwaniami do uzupełnienia chce ratować postępowanie, musi wiedzieć, jak powstają pliki podpisów. To odpowiedź dla tych zamawiających, którzy mówią: my nie podpisujemy, to nie musimy tego znać. A jednak powinni. Powinni w wezwaniu wskazać na wadę i jasno sprecyzować oczekiwanie. 

Innym zagadnieniem jest to, czy wykonawca będzie wiedział, który to jest plik, bo od ZUS dostaje w paczce kilka plików. Wystarczy jednak taki plik „wrzucić” do programu do podpisywania, do opcji weryfikacji, sprawdzić, czy jest podpisany podpisem kwalifikowanym, a następnie w czytniku plików XML zapoznać się z jego treścią. Te same czynności można wykonać, wrzucając plik do czytnika plików XML udostępnionego przez gov.pl. Te usługi lubią jednak zmieniać adresy, a nawet znikać – nie możemy zatem się tylko do nich ograniczać.

W przypadku otrzymanego od wykonawcy pliku XML, zamawiający może odczytać informacje w nim zawarte, importując go do systemu ESPD. Jednak system ESPD nie wyświetli informacji o samym podpisie. Te trzeba uzyskać, stosując oprogramowanie do odczytu podpisu kwalifikowanego. Metody PDF oraz XML w obu wariantach są poprawne, jednak z punktu widzenia łatwości odczytu oraz minimalizowania liczby narzędzi do odczytu to wersja PDF wydaje się optymalna.

Co sprawdza zamawiający w podpisie elektronicznym? 

Przypomnijmy, że potoczny termin „podpis elektroniczny” oznacza komplet: treść oświadczenia oraz dane podpisujące. Mogą one być scalone w jednym pliku lub w dwóch rozłącznych. Dane podpisujące to w uproszczeniu: 

• certyfikat użytkownika podpisu, 
• czas złożenia podpisu, 
• skrót podpisywanego dokumentu (pliku). 

Wspominany wcześniej hash dotyczy tu pliku, który będzie podpisany. Wcześniej mówiliśmy o hashu całego pliku, łącznie z podpisem. Oprogramowanie do podpisu tworzy ten złożony plik podpisu jednym prostym kliknięciem PODPISZ. Wcześniej trzeba zdecydować tylko, w jakim to będzie formacie i typie np. czy XADES otoczony czy otaczający? Niezależnie od tego wyboru czynności sprawdzania pliku są identyczne.
Zamawiający musi znaleźć odpowiedź na następujące pytania:

• Czy plik jest podpisany podpisem kwalifikowanym?
• Czy certyfikat podpisu był ważny w chwili jego użycia?
• Czy nie została naruszona integralność dokumentu?
• Czy osoba podpisująca (posiadacz certyfikatu) jest osobą mogącą reprezentować wykonawcę.

Te informacje należy wydobyć spośród wielu innych zawartych w podpisie. Negatywna ocena choćby jednego z punktów oznacza uznanie oferty za niezgodną z przepisami. Podpisanie oferty przez osobę nieupoważnioną można uratować przez uzupełnienie np. brakującego pełnomocnictwa. W przypadku dokumentów innych niż oferta, wszystkie cztery punkty możemy ratować. Właśnie poprzez wezwanie do uzupełnienia.

W jaki sposób dokonamy sprawdzenia?

Zacznijmy od końca. Pkt 4 – kto podpisał i czy ma prawo reprezentować wykonawcę. Cechą podpisu kwalifikowanego, a ściślej certyfikatu kwalifikowanego, w odróżnieniu od certyfikatu pieczęci kwalifikowanej, jest to, że jest on zawsze osobisty, należy do osoby fizycznej identyfikowanej imieniem, nazwiskiem i numerem PESEL. Nawet jeżeli w certyfikacie będzie nazwa firmy, to należy traktować ją jako informację fakultatywną. Z faktu wpisania nazwy firmy do jednego z pól certyfikatu nie wynika żaden zakres pełnomocnictwa posiadacza certyfikatu. Czyli osobę z certyfikatu musimy porównać z informacją np. z KRS lub dołączonego pełnomocnictwa, jeżeli ta osoba nie figuruje w rejestrach podmiotów. 

Gdy nazwisko z certyfikatu nie pasuje do zasad reprezentacji, możemy wezwać wykonawcę do uzupełnienia tej wady. Jeżeli wykonawca zapomniał po prostu dołączyć pełnomocnictwo wystawione przed podpisaniem oferty przez pełnomocnika, to sprawa jest prosta. Przesyła zamawiającemu „zapomniany” dokument i problem rozwiązany. Jeżeli jednak pełnomocnictwo trzeba dopiero „wystawić”, to pojawia się pytanie – którego w dawnym papierowym świecie nie było – a co z datą podpisu? 

W papierowym świecie data na pełnomocnictwie była zwykle stawiana tak, by pasowała do daty podpisania oferty, czyli przed podpisaniem, a nie po. Ale podpis elektroniczny oferuje datę bieżącą stworzenia podpisu, czyli będzie to data nie tylko po podpisaniu oferty, ale także po otwarciu ofert. Czy tak może być? Oczywiście, ale pod warunkiem, że z treści takiego pełnomocnictwa wynika, iż było udzielone przed podpisaniem oferty. I na to musi zwrócić uwagę wykonawca.

Pozostałe punkty 1–3 to „kryterium weto”. Niespełnienie dowolnego z punktów skutkuje odrzuceniem oferty, zamawiający zatem winien je sprawdzić z niezwykłą starannością i umieć uzasadnić swoją decyzję.
Do tego potrzebuje oprogramowania do weryfikacji podpisu, np. dowolnego programu do podpisywania podpisem kwalifikowanym. Każde takie oprogramowanie ma także funkcjonalność weryfikacji plików podpisanych podpisami innych dostawców, a jest ich w Polsce pięciu.

Można także uruchomić wszystkie pięć programów i przyjąć, że weryfikacja podpisu jest prowadzona na podstawie programu dostawcy danego certyfikatu. Taka weryfikacja jest przeprowadzona na stanowisku – komputerze, na którym jest zainstalowany taki program. Warunkiem koniecznym poprawnego przeprowadzenia całego procesu jest połączenie z Internetem w trakcie weryfikacji.
W przypadku pliku PDF podpisanego podpisem PADES sytuacja jest jeszcze prostsza, gdyż program do odczytu ACROBAR READER DC sam w sobie zawiera narzędzia pozwalające na pozyskanie wszelkich informacji o podpisie. Zamawiający nie może się jednak ograniczyć do przeczytania komunikatu wyświetlonego przez ADOBE: wszystkie podpisy są poprawne. Taki komunikat pojawi się także przy podpisie, który nie jest kwalifikowany, ale przez ADOBE jest traktowany jako zaufany na podstawie innych uregulowań.

Istnieją także rozwiązania chmurowe, czyli załadowanie pliku na cudzy serwer i pozwolenie, by cudze oprogramowanie sprawdziło podpis. Tu jednak trzeba mieć się na baczności. Mimo że dostawcy takich usług twierdzą, iż nie analizują treści dokumentów (bo do weryfikacji ich treść nie ma znaczenia), to jednak taki plik opuszcza komputer zamawiającego, a jeżeli zawiera tajemnice przedsiębiorstwa, może to być jednak ryzykowne.

Jeżeli certyfikat w podpisie nie jest certyfikatem kwalifikowanym, to sprawa jest oczywista. Ale jeżeli certyfikat wygasł, to mimo „czerwonego” alertu należy porównać czas złożenia podpisu z terminami ważności certyfikatu. Jeżeli użycie certyfikatu nastąpiło w czasie ważności certyfikatu, to wszystko jest w porządku. Na pierwszy rzut oka. Na drugi rzut przyglądamy się, czy podpis ma zawarty znacznik czasu (usługa serwera znacznika czasu), czy czas podpisu jest oparty na czasie lokalnym na zegarze komputera. Jeżeli w podpisie mamy czas z komputera, a certyfikat w trakcie badania już wygasł, to może powstać wątpliwość, czy ten czas jest rzetelny. 

Najmniej wątpliwości budzi sprawa weryfikacji integralności podpisu, czyli sprawdzenie, czy treść po podpisaniu nie uległa zmianie. Jeżeli uległa, to każdy program do weryfikacji pokaże to bez problemu i cienia wątpliwości, tak jak było wspomniane wcześniej – sprawdzenie polega na obliczeniu skrótu dokumentu. 

Zasadzka jest gdzie indziej: w przypadku podpisu XADES typu zewnętrznego, a także w przypadku podpisu XML modyfikacja mogła nastąpić u zamawiającego w trakcie otwarcia i zamknięcia pliku. Dlatego warto zaczynać badanie plików od weryfikacji integralności bez ich czytania, a najlepiej tworzyć po pobraniu plików na swój dysk kopie zapasowe: jedną do badania, drugą w rezerwie, gdy będą wątpliwości, czy w trakcie badania nie nastąpiła ingerencja. Ktoś powie, po co kopia, skoro pliki są w systemie do komunikacji? A jeśli ich nie będzie albo będą niedostępne przez chwilę, a my musimy niezwłocznie dokonać analizy?

Podsumowanie

Można tylko współczuć zamawiającym, bo mają teraz zdecydowanie więcej bardzo odpowiedzialnej pracy. Niezależnie od koloru komunikatu weryfikacji, czy będzie to zielony, czy czerwony, to i tak muszą wszystko dokładnie sprawdzić. A podpisów mogą być dziesiątki. Sprawy się komplikują, gdy na jednym dokumencie lądują różne podpisy, niektóre ze znacznikiem czasu, inne bez, a każde narzędzie do weryfikacji wysyła inny werdykt. Aż chce się powiedzieć: w działach zamówień podwyżki po prostu się należą! Pracodawcy, dbajcie o ten dział, bo nie jest tu lekko, a będzie jeszcze… ciekawej. Od 1 stycznia 2021 r.