Podpis zewnętrzny a wewnętrzny: XAdES otoczony, otaczający i podpis w osobnym pliku

Podpis zewnętrzny zapisuje się w osobnym pliku, a podpis wewnętrzny w tym samym pliku co dokument. Cała różnica dotyczy opakowania, nie mocy prawnej. Ten sam kwalifikowany podpis elektroniczny złożony raz zewnętrznie, a raz wewnętrznie wywołuje identyczne skutki, bo o skutkach decyduje certyfikat i przepis, a nie sposób zapisania pliku na dysku.

W praktyce spotkasz trzy warianty. Dwa z nich to podpisy wewnętrzne, różniące się tym, co jest w środku czego.

Najprostszy sposób, żeby tego nie mylić: otoczony znaczy, że podpis jest otoczony dokumentem, a otaczający, że podpis otacza dokument. W obu przypadkach dostajesz jeden plik. Tylko wariant zewnętrzny daje dwa.

Podpis zewnętrzny to podpis zapisany w pliku odrębnym od dokumentu, najczęściej z rozszerzeniem .xades, .xml albo .sig. Plik podpisu nie zawiera treści dokumentu, a jedynie jego skrót kryptograficzny i dane certyfikatu. Weryfikacja polega na policzeniu skrótu z pliku oryginalnego i porównaniu go z tym zapisanym w podpisie, dlatego oba pliki muszą dotrzeć do odbiorcy razem.

Stąd bierze się najczęstszy problem w polskim obiegu dokumentów. Ktoś podpisuje umowę, widzi nowy plik z ikoną aplikacji do podpisu i wysyła właśnie ten plik, uznając, że to jest „podpisana umowa”. Odbiorca dostaje kilkanaście kilobajtów, których nie potrafi otworzyć, i nie ma z czym porównać skrótu. Dokument formalnie jest podpisany, ale nikt tego nie udowodni, dopóki nie znajdzie się plik oryginalny w dokładnie tej wersji, która była podpisywana.

Drugi problem jest cichszy. Podpis zewnętrzny wiąże się z konkretną zawartością pliku, więc każda operacja, która tę zawartość zmienia, zrywa powiązanie. Otwarcie i ponowny zapis PDF w innym programie, konwersja kodowania w pliku XML czy dodanie komentarza wystarczą, żeby weryfikacja pokazała, że dokument został zmodyfikowany po podpisaniu.

Podpis otoczony (enveloped) dokłada się do środka dokumentu XML jako dodatkowy element ds:Signature. Podpis otaczający (enveloping) działa odwrotnie: to podpis jest plikiem nadrzędnym, a oryginalny dokument zostaje do niego załączony w środku. Oba warianty kończą się jednym plikiem i oba są akceptowane przez większość systemów administracji.

Praktyczna konsekwencja jest taka, że wariant otoczony zachowuje pierwotną strukturę pliku. Jeżeli otworzysz podpisany w ten sposób XML, dalej zobaczysz swoje dane, tylko z doklejonym na końcu blokiem podpisu. System odbierający może go przetworzyć nawet wtedy, gdy nie interesuje się podpisem.

Wariant otaczający tej cechy nie ma. Oryginalny dokument jest tam osadzony w środku struktury podpisu, często dodatkowo zakodowany w base64, więc żeby dostać się do treści, trzeba go najpierw wydobyć. To nie jest wada, ale wyjaśnia, dlaczego wariant otoczony bywa preferowany przez systemy, które i tak muszą przeczytać dane.

Ograniczenie wariantu otoczonego jest jedno i istotne: działa tylko dla plików XML. Nie da się wstawić elementu ds:Signature do środka pliku JPG, ZIP czy DOCX, bo nie mają one struktury XML, do której można cokolwiek dopisać. Dla takich plików zostaje wariant otaczający albo zewnętrzny.

Bo tak ma ustawioną konfigurację fabryczną, i producent mówi to otwarcie. W oficjalnej instrukcji podpisywania i weryfikacji dokumentów w aplikacji Szafir (KIR) przy opisie podpisu XAdES stoi zdanie: „Jest dostepny w domyślnej konfiguracji. Aby złożyć taki podpis wystarczy po otworzeniu aplikacji Szafir wybrac przycisk «Podpisz». Podpis składa się wówczas rozłącznie, a zatem po podpisaniu potrzebne będą do weryfikacji dwa pliki: oryginalny oraz ten, który utworzy się w aplikacji Szafir.”

To jedno zdanie tłumaczy większość zgłoszeń typu „urząd nie przyjmuje mojego podpisu”. Użytkownik instaluje aplikację, klika „Podpisz”, dostaje plik .xades i wysyła go samego, bo nikt mu nie powiedział, że powstał podpis rozłączny. Jeżeli chcesz jeden plik, musisz świadomie wejść w konfigurację i zmienić wariant przed podpisaniem, a nie po.

Ta sama pułapka dotyczy formatu CAdES, tylko pod inną nazwą. Tam decyduje opcja „Zapisz podpisywane dane razem z podpisem”. Instrukcja KIR ostrzega przy niej wprost: „Nie zaznaczenie tej opcji będzie oznaczało, że razem z plikiem z podpisem trzeba wysłać odbiorcy plik oryginalny (podpisywany)”. Zaznaczona daje jeden plik .sig zawierający dane i podpis, niezaznaczona znowu dwa pliki.

Wniosek praktyczny: zanim podpiszesz cokolwiek, co idzie do urzędu, podpisz jeden testowy plik i zobacz, ile plików powstało. To zajmuje minutę i oszczędza rundę korespondencji.

Zależy od konkretnego dokumentu, i to jest sedno problemu. Nawet w obrębie jednej usługi wymagania potrafią się różnić. Najlepiej widać to w specyfikacji API e-Sprawozdań Finansowych publikowanej przez Ministerstwo Finansów (wersja 7.0).

Dla dokumentu InitRequest, czyli pliku otwierającego wysyłkę, specyfikacja dopuszcza jeden wariant. Podpis ma być złożony „zgodnie z algorytmem XAdES BES Enveloped w postaci pliku XML zgodnego ze schematem http://www.w3.org/2000/09/xmldsig”. Enveloping ani external nie są tu wymienione.

Dla samego sprawozdania finansowego ta sama specyfikacja wymienia już trzy obsługiwane wersje:

• XAdES-BES ENVELOPED (podpis jako dodatkowy element ds:Signature w oryginalnym XML)
• XAdES-BES ENVELOPING (podpis do którego załączona jest oryginalny XML)
• XAdES-BES EXTERNAL (podpis w oddzielnym pliku)

Czyli sprawozdanie przejdzie w każdym z trzech wariantów, a plik inicjujący wysyłkę tylko w jednym. Jeżeli ktoś ustawi sobie aplikację raz, na podpis rozłączny, i podpisze nim oba pliki, sprawozdanie będzie poprawne, a wysyłka i tak się nie uda. Specyfikacja dodaje jeszcze dwa warunki, o których łatwo zapomnieć: funkcją skrótu ma być RSA-SHA256, a obsługiwane są wszystkie podpisy kwalifikowane zgodne z eIDAS, „niezależnie od kraju ich wydania, łącznie z wydanymi poza UE”. Ten ostatni fragment bywa zaskoczeniem dla spółek z zagranicznym zarządem, które zakładają, że potrzebują polskiego certyfikatu.

Reguła praktyczna: nie zgaduj wariantu. Wejdź do specyfikacji technicznej danej usługi i sprawdź, co jest napisane dla tego konkretnego pliku, bo wymagania różnią się nawet w obrębie jednej wysyłki.

PAdES podpisuje wyłącznie pliki PDF i zawsze zapisuje podpis wewnątrz dokumentu. XAdES podpisze dowolny plik, ale wymaga decyzji, jak podpis ma być opakowany. Stąd bierze się cała różnica w codziennym użyciu.

Przy PAdES pytanie „otoczony czy zewnętrzny” nie pada, bo podpis staje się częścią struktury PDF. Odbiorca otwiera plik w zwykłej przeglądarce PDF i widzi panel podpisu. Nie musi mieć aplikacji do weryfikacji, nie musi wiedzieć, czym jest XAdES, i nie może zgubić drugiego pliku, bo drugiego pliku nie ma.

Przy XAdES zyskujesz uniwersalność. Podpiszesz plik XML, ale też ZIP, JPG czy arkusz. Płacisz za to tym, że odbiorca potrzebuje narzędzia do weryfikacji, a Ty musisz pilnować konfiguracji.

Zasada, która porządkuje wybór: jeżeli dokument jest w PDF i nikt nie żąda inaczej, wybierz PAdES. XAdES zostaw dla plików XML i dla usług, które wprost go wymagają.

Nie jest to kwestia dobrej woli konkretnego urzędu. Decyzja wykonawcza Komisji (UE) 2015/1506 wskazuje formaty, które podmiot publiczny ma obowiązek uznać. Artykuł 1 stanowi, że państwo członkowskie wymagające zaawansowanego podpisu elektronicznego „uznaje zaawansowane podpisy elektroniczne w formatach XML, CMS lub PDF na poziomie zgodności B, T lub LT bądź zastosowanie formatu ASiC”.

Załącznik do decyzji przypisuje tym formatom konkretne specyfikacje ETSI:

Artykuł 3 powtarza te same wymagania dla zaawansowanych pieczęci elektronicznych. Poziomy B, T i LT opisują, jak dużo dowodu podpis niesie ze sobą: poziom podstawowy, poziom ze znacznikiem czasu oraz poziom z dołączonymi danymi walidacyjnymi, dzięki którym podpis da się zweryfikować także po wygaśnięciu certyfikatu. Jeżeli zależy Ci na weryfikowalności za kilka lat, to właśnie ten trzeci poziom ma znaczenie, o czym szerzej piszemy przy okazji znacznika czasu w podpisie elektronicznym.

Warto zwrócić uwagę na formę wyliczenia. Przepis mówi o formatach XML, CMS i PDF jako o równorzędnych. Nie ma w nim wymogu, żeby podpis był zewnętrzny albo wewnętrzny, bo z punktu widzenia prawa unijnego to ustawienie techniczne. Wymóg konkretnego wariantu bierze się zawsze z dokumentacji danej usługi krajowej, nie z eIDAS.

Do umowy między firmami nie potrzebujesz ani XAdES, ani PAdES, ani podpisu kwalifikowanego. Wystarczy forma dokumentowa z art. 77(2) Kodeksu cywilnego, a tę zachowuje każde oświadczenie złożone w postaci elektronicznej w sposób umożliwiający ustalenie osoby składającej oświadczenie. Zwykły podpis elektroniczny ze śladem audytowym spełnia ten warunek.

To dotyczy zdecydowanej większości dokumentów, które firma podpisuje w ciągu roku: umów B2B, zleceń, umów o dzieło, NDA, umów najmu lokalu użytkowego, zamówień, aneksów i wypowiedzeń. Formatu XML nie żąda tam żaden przepis. Wybór XAdES oznacza w takiej sytuacji, że obie strony instalują aplikację, konfigurują wariant opakowania i pilnują kompletu plików, żeby osiągnąć skutek prawny, który i tak przysługiwał im bez tego.

XAdES staje się obowiązkowy dopiero tam, gdzie wymaga go specyfikacja techniczna usługi publicznej: przy jednolitym pliku kontrolnym, sprawozdaniu finansowym składanym do KAS, części wysyłek przez ePUAP i w systemach branżowych operujących na XML. Wtedy nie ma wyboru i trzeba zajrzeć do dokumentacji po właściwy wariant.

Jeżeli natomiast Twój problem brzmi „muszę podpisać umowę z kontrahentem i chcę, żeby to trwało minutę”, właściwym rozwiązaniem jest jeden plik PDF, link do podpisu i ślad audytowy w komplecie. Nikt nie musi wtedy wiedzieć, czym jest enveloping, a dokument otworzy się wszędzie. Więcej o tym, jaką moc ma taki podpis, znajdziesz na stronie o mocy prawnej podpisu elektronicznego.

Jeżeli dostałeś taki plik od kontrahenta i chcesz najpierw sprawdzić, czy podpis się broni, wgraj oba pliki naraz do walidatora obsługującego XAdES. Które narzędzia robią to bezpłatnie i jak odczytać ich raport, zebraliśmy na stronie o weryfikacji podpisu elektronicznego.