Kompatybilność formatów podpisu elektronicznego w Polsce bliska zeru

W 2005 roku na łamach tygodnika Computerworld opisywałem potencjalne zamieszanie jakie może wywołać wybór czterech różnych formatów podpisu elektronicznego przez cztery polskie kwalifikowane centra certyfikacji (QCA). Były to formaty wybrane arbitralnie przez centra na podstawie rozporządzenia o warunkach technicznych i stosowane w dostarczanych klientom aplikacjach "do podpisu kwalifikowanego". W 2005 roku działały one (z jednym wyjątkiem) w ten sam sposób - to znaczy podpisywany dokument traktowały jako ciąg bitowy i enkapsulowały w przyjętym przez producenta formacie.

Wówczas były to trzy kontenery, stanowiąc bezpośrednio struktury w formatach dopuszczonych przez rozporządzenie - PKCS#7 (KIR), CMS (Certum) i XAdES (Signet). Aplikacje te były programami "do wszystkiego" czyli w praktyce o niewielkiej przydatności i dość topornymi, za to realizującymi dosłownie wymagania rozporządzenia.

Każde z centrów miało wówczas wcale racjonalne argumenty za wyborem swojego formatu, natomiast żadne z nich nie dostrzegło prostej prawdy - że konsumenta wcale nie interesują różnice między PKCS#7 i CMS, natomiast jak najbardziej interesuje go by plik podpisany "programem X" otwierał się w "programie Y" i tak dalej.

Niestety, tej interoperacyjności centra nie potrafiły - lub nie chciały - zapewnić, składając równocześnie wspólne deklaracje o niezwyklej łatwości stosowania podpisu kwalifikowanego.

Wina leży także po stronie administracji publicznej, która stworzyła mętne i niespójne regulacje w postaci ustawy o informatyzacji i rozporządzeń do niej, nie mówiąc już o dalszych rozporządzeniach Ministerstwa Sprawiedliwości czy Ministerstwa Zdrowia.

Jeśli ustawodawca nie powiedział urzędnikom konkretnie co mają zamawiać i czego mają po gotowym produkcie oczekiwać to trudno się dziwić praktyce pisania Specyfikacji Istotnych Warunków Zamówienia (SIWZ) przez integratorów i wciskaniu urzędom produktów kompletnie nie nadających się do użytku, ale formalnie spełniajacych wymagania którejś z ustaw.

W tym wszystkim kompletnie zignorowano interes końcowych użytkowników czyli tych, dla których cały ten interes formalnie działa. W ciągu trzech lat, jakie minęły od publikacji tamtego artykułu mieliśmy do czynienia z powolnym rozwojem usług skrzynek podawczych a co za tym idzie ponowną koniecznością wybrania formatów akceptowanych przez skrzynki - oraz formatów generowanych przez nie UPO.

Niestety, zamiast wykorzystać tę szansę do uporządkowania rynku producenci tych rozwiązań - głównie QCA - tylko pogłębili chaos w tym względzie, okopując się niejako w bastionach wzajemnej niekompatybilności. Jest to tym bardziej zaskakujące, że w 2006 roku trzy centra zgodnie ogłosiły że rozpoczynają współpracę nad unifikacją formatów z pożytkiem dla wszystkich.

Jaki jest obecnie stan faktyczny? Skrzynki podawcze oferowane przez polskie centra i producentów zewnętrznych, oraz oferowane przez nich aplikacje, nadal posługują się odmiennymi formatami, nawet w podobnych lub identycznych zastosowaniach. Ale już zupełnie niezrozumiałe jest to, że część aplikacji oferowanych przez centra nawet jeśli posługuje się tym samym formatem to używa... innych rozszerzeń! To posunięcie zamyka drogę do jakiejkolwiek kompatybilności i interoperacyjności z punktu widzenia konsumenta.

Jak daleko posunęliśmy się w absurdzie niech świadczy fakt, że z czterech formatów z 2005 roku do dzis wypączkowało około czternastu. Oczywiście, nie wszystkie z nich są równoważne. Część z nich - jak twierdzą centra - została wycofana "z obiegu". Niestety, aplikacje które wcisnęli urzędom w ciągu ostatnich lat nadal tam są, ponieważ urzędnicy uwierzyli w zapewnienia o ich przydatności i łatwości użycia.

Przykład skrzynki podawczej Urzędu Miasta Krakowa jest znamienny - urząd, który wysyła odpowiedzi w jednym formacie, ale tego samego formatu nie przyjmuje to żywy pomnik arogancji integratorów, którzy na "starą" skrzynkę sprzedali zapewne urzędowi "nowe" aplikacje z certyfikatami i zadowoleni zainkasowali pieniądze. Ale także ignorancji urzędu, który takie rozwiązanie zamówił, odebrał i za nie zapłacił.

Aktualna tabela stosowanych w Polsce formatów podpisu elektronicznego znajduje się poniżej:

Tabela jest zapewne niekompletna. Będzie rozbudowywana w miarę jak dostanę do rąk produkcyjne aplikacje QCA z zamówionymi certyfikatami.

Parę miesięcy temu łza mi się w oku zakręciła, kiedy austriackim programem trustDesk bez problemu otwarłem plik z rozszerzeniem P7M (PKCS#7) wygenerowany przez inny austriacki program (A-Trust). Ale moje zdumienie nie miało granic, kiedy taki podobny plik P7M znalazłem na stronie włoskiej agencji CNIPA i... obydwa programy też go otwarły.

Tymczasem w Polsce trafiajac na plik o rozszerzeniu SIG, trzeba praktycznie zgadywać (albo użyć hexedytora) czy jest to plik w formacie CMS (Sigillum, Certum), czy PKCS#7 ("stary" KIR) czy też może XAdES (itBCG/Sigillum). Kpiną ze zdrowego rozsądku jest oczekiwanie, że klient zainstaluje oddzielną aplikację tylko po to by odczytać format ZSI (zwykły XML) jaki był łaskaw wymyśleć sobie dla UPO producent skrzynki podawczej UMK (prawdopodobnie Zeto Białystok). Równie naiwne jest oczekiwanie, że klient otrzymujący fakturę od TPSA w postaci dwóch plików (PDF i XML.SIG) będzie otwierał ją dwoma aplikacjami.

Podsumowując, dostarczenie na rynek kompletnie nieużywalnych narzędzi, a następnie wylewanie krokodylich łez że nikt nie chce ich stosować zakrawa na ponury żart. Domaganie się w tej sytuacji przymusu administracyjnego dla "popularyzacji podpisu" to już cynizm i nieudolna próba maskowania własnej niekompetencji przez firmy, które o to lobbują.

Anarchia w zakresie interoperacyjności powinna być dla administacji sygnałem ostrzegawczym, że na centra nie można liczyć w zakresie dostarczenia produktów podpisu elektronicznego w formie nadającej się do użytku w skali państwa. A nie w skali salki w której potencjalny dostawca na slajdach pokazuje jak fajnie to działa.

Obecny stan kompromituje niestety polskie centra jako odpowiedzialnych i skutecznych kreatorów rynku podpisu elektronicznego
i skłania do smutnego wniosku, że swoboda wyboru jaką ustawodawca pozostawił w kolejnych rozporządzeniach została nadużyta do nieodpowiedzialnego niszczenia rynku podpisu elektronicznego w Polsce, czego dowodzą wszystkie możliwe statystyki.

Nie można wciąż zwalać winy na rzekome "fobie przedsiębiorców przed nowymi technologiami". Przedsiębiorcy od dawna wysyłają sobie faktury w formie elektronicznej, ignorując te rozwiązania, które dla nich przygotowała administracja. Nie dlatego, że się ich "boją", tylko dlatego że są one nieużywalne.

Trackback URL for this post:

http://ipsec.pl/trackback/244

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.

Od miesiąca męczę się z podpisem kwalifikowanym MobiTrust. Niestety nie działa z elektroniczną skrzynką podawczą Sputnik Software. Nie można też zweryfikować tego podpisu oprogramowaniem Krajowej Izby Rozliczeniowej, mimo, że podpis wystawiony jest przez KIR. Używanie kwalifikowanego podpisu elektronicznego do innych celów niż Płatnik to farsa w naszym kraju.

Co do Mobitrust to prawdopodobnie skrzynka nie ma zaimportowanego certyfikatu root, bo jest to nowe centrum. Z KIR może być podobny problem, bo o ile pamiętam zmieniali roota w międzyczasie i skrzynka może nie mieć nowego. Identyczny problem był do niedawna w ePUAPie ale zgłosiłem do supportu i dodali w ciągu kilku dni.

Link do tabeli kompatybilności nie działa

Link do pdf nie diała.

Już powinno być OK.

Link do PDF-a z tabelą kompatybilności nie działa.

-

Jako ciekawostka, XAdES-T i XAdES-BES składany przez aplikację itBCG jest weryfikowalny nie tylko za pomocą "natywnej" aplikacji Sigillum, własnej aplikacji itBCG ale również za pomocą zupełnie niezależnej aplikacji PEMI.
Nie widzę żadnego problemu ze stworzeniem aplikacji która będzie weryfikować każdy z praktycznie używalnych typów podpisu (PKCS, XADES, CMC) i warto powiedzieć o tym że tym rządzi rynek a nie Centra, MG, MSWIA czy ktokolwiek jeszcze. Jeżeli będzie to problemem dla rynku, to rynek ten problem naprawde szybko rozwiąże.
Myślę że podstawowym problemem z którym jeszcze się spotkamy będzie rozdzelenie ról Centra certyfikacji i producenta oprogramowania. Z racji doświadczeń które są tu prezentowane, polskim centram certyfikacji po prostu nie wychodzi pisać DOBRE oprogramowanie. Moje doświadczenie podpowiada mi że jak tylko rynek związany z podpisem trochę się rozwinie to pojawi się kompatybilność, ergonomia, łatwość uzytkowania.
Jeżeli chodzi o technologie formularzów(a jest z tym poważny problem, który dopiero zaczyna wychodzić) to faktycznie, oferta Adobe jest naprawdę warta uwagi. Przy czym nie należy sugerować się polityką cenową Adobe, która średnio odpowiada polskiej rzeczywistości, przecież istnieje wiele innych często darmowych i rozwiniętych bibliotek pozwalających tworzyc formularze Adobe, chociażby iText.

Obecna sytuacja jest częściowo wynikiem fobii przed wystawianiem deklaracji zgodności, z którą to fobią skutecznie zmierzył się tylko ebStream, zaś większość firm woli kupować komponenty od centrów. Potem wychodzi im to co wychodzi, bo jak Pan zauważył centrom niespecjalnie udaje się pisanie dobrego oprogramowania :)

Z drugiej strony nie każda firma biegła w pisaniu oprogramowania czuje się na siłach by samodzielnie przeprowadzić ocenę zgodności z ustawą lub ma środki by to zlecić na zewnątrz. 

Technologii na których można byłoby się oprzeć jest więcej - Microsoft ma InfoPath, OpenOffice ma ebXML, a Adobe ma XFA.  Jest więc z czego wybierać, tylko że każdy z tych systemów musiałby znaleźć odważnego, który wystawiłby dla niego deklarację zgodności.

Nie rozwiązuje to też problemu e-faktur, których wystawianie zgodnie z obowiązującą ustawą jest cokolwiek przeciwskuteczne, o czym się zapewne sami przekonaliście. 

Swoją drogą, te PDFy z fakturą możnaby choćby podpisać certyfikatem niekwalifikowanym Thawte czy innym, tak jak to robią bank, żeby się ludziom weryfikowało w Readerze, a ten XML.SIG niech sobie będzie obok dla zgodności z ustawą...

Przed chwilą testowałem podpis złożony aplikację SZAFIR (KIR) do formatu PKCS#7 (.SIG) oraz próbę otwarcia go przy pomocy Sigillum Sign Pro. Wynik - negatywny. Sigillum oczekuje zapewne, że będzie to CMS bo samo w rozszerzeniu .SIG taki format zapisuje. Totalne lamerstwo...


Parę miesięcy temu łza mi się w oku zakręciła, kiedy austriackim programem trustDesk bez problemu otwarłem plik z rozszerzeniem P7M (PKCS#7) wygenerowany przez inny austriacki program (A-Trust). Ale moje zdumienie nie miało granic, kiedy taki podobny plik P7M znalazłem na stronie włoskiej agencji CNIPA i... obydwa programy też go otwarły.

Wszystko dzięki temu że standard PKCS#7 jest dobrze zdefiniowany. Całe to zamieszanie z podpisami XML-owymi wydaje mi się ślepą gałęzią ewolucji. Przez swoją zasobożerność i możliwości interpretacji jest to zupełnie nieużyteczne. Kwiatek z ostatnich badań:
Wspaniały program produkcji KIR fakt że demo potrafi wygenerować plik XAdES-owy z osadzonym dokumentem o wielkości 12MB ale próba weryfikacji w tymże programie kończy się w zależności od pogody błędem OutOfMemory lub NullPointerExeption.

swoją drogą to przydał by się im ktoś od ergonomii interfejsu użytkownika... ale cóż jak się bierze NetBeans za podstawę GUI to może się nie da

Link do tabeli kompatybilności nie działa

Dziękuję, poprawione.

Poprawione - polskie znaki w nazwie pliku były w CP1250, a w linku na stronie - w Unicode. Swoją drogą 26 standardów kodowania polskich znaków to jeszcze jeden przypadek źle pojętej innowacyjności :)

Dlaczego format EBF nie należy do grupy formatów "między którymi mogłaby zachodzić kompatybilność, ale różniące się rozszerzeniami"?

Przecież jest to XAdES i to całkiem dobrze opracowany? Z PDFem się zgadzam, czy w ogóle pomylonym SDOCkiem... Byłbym widzięczny za rozwinięcie tej myśli zwłąszcza, że uważam ten format za całkiem sensowny i zgodny ze specifikacją ETSI. Chciałbym dowiedzieć się jakie argumenty kazały w taki sposób zakwalifikować ten format.

Kryterium "mogłaby zachodzić kompatybilność" jest bardzo proste - możliwość bezpośredniego odczytania danego formatu przez inną aplikację np. po zmianie rozszerzenia.

W przypadku EBF ten warunek nie jest spełniony. Proszę zauważyć, że wszystkie w/w formaty są sparowane to znaczy kolorami wskazane są dwie (lub więcej) aplikacji, które mogłyby wzajemnie czytać swoje formaty.

W przypadku EBF trudno byłoby mi taką inną aplikację wskazać, bo EBF jest o ile wiem oparty o prywatną schemę stworzoną przez ebStream.

Moja prywatna opinia jest taka, że ebCommunicator jest jedną z najbardziej używalnych i sensownie zbudowanych aplikacji dostępnych na polskim rynku podpisu kwalifikowanego. Natomiast pod względem interoperacyjności idzie nieco pod prąd.

Co do SDOC to nie tyle ułomny jest sam format, co jego zastosowanie parę lat temu. SDOC jest bardzo bezpiecznym formatem archiwalnym, więc błędem było promowanie go jako uniwersalnego formatu dla dokumentów z podpisem kwalifikowanym, zwłaszcza że był on jedynym jaki Sigillum promowało w 2005 roku.

Nie spotkałem się na naszym rynku z lepszym rozwiązaniem niż te zaproponowane przez ebStream. Nie wiem czy faktycznie jest najczęściej stosowane, ale zgodzę się co do dużej niezawodności tej aplikacji jak również innych rozwiązań w tym ESP.

Faktycznie jest tak, że schema jest autorstwa ebStreamu. Rozumiem, też Pana punkt widzenia. I tłumaczę sobie go w następujący sposób: Skoro istnieje już kilka rozwiązań na rynku to sprawdźmy, które potrafią ze sobą współpracować. Stąd tabelka. Na jej podstawie można wyłonić małe grupy, które przydało by się połączyć, aby każdy mógł używać jednej aplikacji do otwierania dokumentów. Ja natomiast uważam, że nie tędy droga.

Ponieważ rozwiązania te są dalekie od choćby poprawności nie warto ich łączyć. Choć to mało realne wolałbym ustanowić scheme ebStreamu za jedyną słuszną w Polsce, bo jest dobrze przygotowana. Uważam też, że taka mała firma jak ebStream, pośród większej i nieudolnej zarazem konkurencji, próbując wytaczać drogę wydaje się iść pod prąd. Poza tym wszystkie rozwiązania są autorskie. Nikt nie wypracował w tej kwestii standardu. To też można powiedzieć, że nikt po prostu jeszcze nie wszedł w współpracę z firmą ebStream (wzajemna kompatybilność).

Brak standardu jest kulą u nogi całego procesu informatyzacji. Brak jednej wspólnej postaci dokumentu elektronicznego jest niekompetencją ustawodawcy. W tym wszystkim, firmy też się nie porozumiały i nie wypracowały wspólnego standardu. Obecnie funkcjonuje rozporządzenie o wzorach dokumentów elektronicznych, który nareszcie określa technologię - brak jednak wciąż standardu (wzoru). UE opracowało jakiś czas temu raport o wdrążaniu podpisu cyfrowego w państwach członkowskich. Większość z nich nie potrafi w własnych granicach zapewnić kompatybilności (wyjątek np. Dania) w tym oczywiście Polska. Moim zdaniem w przypadku standaryzacji wzoru jak i mając na uwadze plany UE co do wzajemnej współpracy wszystkich państw członkowskich w tym zakresie powinno się opracować taki standard właśnie na szczeblu unijnym. Puki co jest to bardzo trudne, a wręcz niemożliwe skoro pojedyncze państwo nie potrafi sprostać takiemu zadaniu w obrębie swoich granic.

Moim zdaniem tabelka prezentuje dane w niewłaściwy sposób. Pokazuje wspólne cechy. Wynika z niej jednak złudne przeświadczenie, że istnieją wzajemne relacje pomiędzy produktami. Było by to całkiem słuszne, gdyby te rozwiązania były dobre i opierały się o jakiś nie własny standard. Ale go nie ma. Nikomu teraz nie w smak opracować standard, bo oznaczało by to powalenie na łopatki nie jednego rozwiązania, a na to przecież te firmy sobie nie mogą pozwolić. Myślę, że tu właśnie jest sedno problemu. Próba łączenia tych rozwiązań to po prostu protetyka.

Ponieważ uważam rozwiązanie ebStreamu za bardzo dobre i na tle konkurencji wręcz niezawodne (a z pewnością najlepiej dopracowane) tabelka ta nie pokazuje prawdy, a jedynie wybiórcze rozumienie problemu lub na zasadzie: dobrze skoro już powstały te rozwiązania to znajdźmy teraz jakąkolwiek drogę wyjścia i zapewnijmy współpracę pokazując, kto już to zrobił. Moim zdaniem nie ma tu faworytów. Najpierw standard, a potem nie wygra najlepszy, czyli ten który będzie wstanie przekształcić swoje rozwiązanie do zgodnego z standardem. Dopiero wówczas tabelka ta miałaby mocne fundamenty.

Co Pan sądzi o takim rozumieniu sprawy?

Co do formatu SDOC. Nie mogę się zgodzić się zgodzić, że jest archiwalny, a powinien taki być. Tym samym można powiedzieć, że mało jest zaufany - bezpieczny tak - tylko nie w rozumieniu zwykłego użytkownika. XAdES-A nie jest nowością. SDOC nie ma o tym pojęcia. Jakie są tego konsekwencje? Proszę podpisać dokument podpisem kwalifikowanym za pomocą Sigillum Sign. Następnie zmienić datę w systemie na starszą, tak aby wykraczała poza ważność Pana certyfikatu. Teraz otworzy Pan ponownie Sigillum Sign i spróbuje zweryfikować podpis. Jak już zauważy Pan, że się nie weryfikuje to proponuję zadzwonić do Sigillum i zapytać co oni na to - odpowiedź powinna Pana zaskoczyć (albo wprost przeciwnie:)). Przestawienie daty w systemie to taka symulacja naturalnego wygaśnięcia certyfikatu. Pytanie oczywiste - dlaczego data pobierana jest z systemu? Drugie pytanie - co z ważnością dokumentu (jak sprawa będzie wyglądać przed sądem)? i tu się kłania XAdES-A. Ustawodawca nie był zbytnio precyzyjny, a architekt rozwiązania przewidujący - nie odrobił lekcji, nie sprawdził jak to funkcjonuje w innych krajach i nie ma co tu bronić, że to początki i pierwsze kroki - komuś się czytać nie chciało. A nie było to specjalnie trudne do odgadnięcia.

pozdrawiam.

Co do tabelki, to ma raczej ona pokazać jak blisko były centra od osiągnięcia pewnej kompatybilności. EBF jest tam raczej dla kompletności "katalogu", a nie w celach porównawczych.

Przyznam, że całkowicie nie rozumiem dlaczego mimo wszystko pogłębiły niekompatybilność - przecież równocześnie wykonały kupę roboty wprowadzając do swoich produktów np. XAdES. Ale ta niekompatybilność nie daje im żadnej przewagi rynkowej, a tylko zniechęca klientów, na czym tracą przede wszystkim centra. Kompletnie tego nie rozumiem... 

Żeby wprowadzić nową schemę na rynek nie wystarczy by była ona dobra - historia IT zna przecież dziesiątki dobrych produktów, które wyleciały z rynku. Żeby to się udało musi być spełniony co najmniej jeden z warunków:

  • pusty rynek, co pozwala szybko zająć pozycję monopolisty i dyktować warunki innym,
  • pozycja giganta, jak Microsoft z OpenXML,
  • posiadanie ogromnych nakładów na promocję i lobbing.

W przypadku EBF żaden nie jest spełniony - producent tego rodzaju jak ebStream może wejść na rynek jedynie wykorzystując wady istniejących produktów, ale w kwestii interoperacyjności musi się dostosować do tego co istnieje.

Przecież coś bardzo podobnego jak EBF zapewnia standard XFA z językiem FormCalc, coś co jest promowane od prawie dekady przez Adobe. Na tym rynku ebStream nie ma szans konkurować innym formatem - ale gdyby oprzeć tak fajną aplikację jak ebCommunicator właśnie o XFA/FormCalc to taki produkt byłby pod wieloma względami bardziej konkurencyjny od "korporacyjnie sztywnego" Adobe dla pewnego segmentu rynku.

Witam,

„Przed chwilą testowałem
Paweł Krawczyk, pt., 2008-03-21 13:06
Przed chwilą testowałem podpis złożony aplikację SZAFIR (KIR) do formatu PKCS#7 (.SIG) oraz próbę otwarcia go przy pomocy Sigillum Sign Pro. Wynik - negatywny. Sigillum oczekuje zapewne, że będzie to CMS bo samo w rozszerzeniu .SIG taki format zapisuje. Totalne lamerstwo...”

Hmm z tego co mi wiadomo Sigillum Sign Pro nie rozpoznaje formatu podpisu po rozszerzeniu a po „strukturze” podpisu i jest wstanie rozpoznać PKCS#7, CMS, XAdES-BES oraz XAdES-T. A fakt błędnej weryfikacji podpisu wygenerowanego przez aplikację SZAFIR może mieć różne „źródła”…

Wracając do sedna tematu, uważam podobnie jak kolega Herman, że najlepszym regulatorem rynku podpisu elektronicznego jest sam rynek. Trudno mi wyobrazić sobie aby MSWiA narzuciło jedynie słuszny format, tym bardziej, że wtedy powstanie problem z ważnością „starszych” podpisów…

Wydaję się, że najlepszym wyjściem jest „dogadanie” się centrów głównie w kwestii XAdES’a bo na poziomie CMS i PKCS#7 raczej są kompatybilne. Problem z XAdES’em w dużej mierze polega na braku standardu np. co do kontrasygnowania podpisów, przechowywania danych (eneveloping, enveloped, detached). Proszę zwrócić uwagę, że nawet na poziomie kanonikalziacji mogą zachodzić różnice np. .NET Framework doprowadza do postaci kanonicznej podpis inaczej niż libxml2…

Kończą myślę, że centra mają wolę stworzyć standard XAdES bo przecież głównie zarabiają na sprzedaży certyfikatów a nie softu do podpisu.

Pozdrawiam,
Dachi

Rząd nie powinien narzucać standardu podpisanego dokumentu "w ogóle", tylko standard podpisanego dokumentu do kontaktów ze sobą. Pewną tego formą będzie e-PUAP, i bardzo słusznie.

Bo obecna sytuacja, w której co aplikacja to format generuje problemy dla petenta ale tym bardziej dla urzędu. Urząd pisząc SIWZ musi wskazać jakieś formaty - zapewnienie obsługi wszystkich dostępnych na rynku to wyrzucanie pieniędzy w błoto, zwłaszcza że część z nich to formaty prywatne.

Na dogadanie się centrów bym nie liczył. Mieli na to kilka lat i jest jeszcze gorzej.

Zgodność XAdESa jest problemem bo jest to format stosunkowo młody i mało w praktyce wykorzystywany. Pisanie w rozporządzeniu o "zgodności z ETSI TS 101 903" ma taki sens jak pisanie "zgodny z X.509" czyli żaden, bo dostaniemy 10 produktów zgodny z normą w jakimś zakresie, ale niezgodnych ze sobą nawzajem.

Administracja powinna wskazać dokładnie profil XAdESa, wymagane metody kanonizacji itd wraz z przykładami na których można weryfikować kompatybilność.  Proszę popatrzyć zresztą na specyfikację wejścia/wyjścia e-Deklaracji, są schemy i szczegółowy opis kanonizacji i podpisywania.