OpenDocument bez podpisu elektronicznego

Do niedawna byłem święcie przekonany, że podpis elektroniczny w formacie XML-DSig jest integralną częścią OASIS OpenDocument Format. W trakcie dyskusji na liście ISOC-PL zajrzałem do specyfikacji ODF i okazało się... że podpisu elektronicznego nie ma tam wcale. Jest kontener ZIP, jest szyfrowanie - a podpisu elektronicznego nie ma.

Ani ODF 1.0 ani 1.1 nie zawiera definicji podpisu elektronicznego. Jak to zatem możliwe, że OpenOffice składanie takiego podpisu umożliwia? Jak wynika ze strony OpenOffice standard XML-DSig został zaimplementowany w tym programie dodatkowo, jako uzupełnienie do standardu ODF.

Podpis elektroniczny jest więc dodatkowym, specyficznym dla tej konkretnej aplikacji rozszerzeniem a nie elementem formatu ODF. Ale już na przykład aplikacja KOffice również zapisująca dokumenty w formacie ODF nie posiada funkcji podpisu elektronicznego.

Czy to źle? Na pewno nie za dobrze. Po pierwsze ta luka w ODF osłabia argument przeciwników OpenXML, że jest to format, który zawiera różne specyficzne dla aplikacji Microsoftu rozszerzenia - bo czymże jest w OpenOffice podpis elektroniczny jak niestandardowym rozszerzeniem. Dla wyjaśnienia - XML-DSig to standard, ale w konkretnym formacie pliku zaimplementować go można na wiele sposobów. Tymczasem OpenXML zawiera precyzyjną definicję użycia XML-DSig w dokumentach OpenXML i jest to część standardu OpenXML (ECMA 376).

Dlaczego standard ODF (ISO 26300) nie definiuje sposobu użycia XML-DSig w dokumentach ODF? Wydaje mi się, że to dość poważny brak, zwłaszcza jeśli mówimy o wykorzystaniu ODF do poważniejszych zastosowań takich jak publikacja aktów normatywnych czy elektroniczna wymiana dokumentów.

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.

Wszyscy widzą w standardach ODF 1.0 i 1.1 duży brak, ale odpowiedzcie gdzie w polskiej administracji wykorzystywany jest podpis elektroniczny na większą skalę. Polskie organy państwowe od wielu lat starają się, opóźnić wprowadzenie podpisu elektronicznego. Przytoczono w artykule tezę, jako by ODF w tych wersjach miał bardzo poważną wadę, ale ja jako użytkownik tego nie widzę. Dziś XML-DSig nie ma większego znaczenia, a przyszłe wersje standardu jak zauważono, rozwiążą ten mankament. Na dziś na polskim rynku nie ma natywnego wsparcia firm certyfikujących dla systemów alternatywnych, oprogramowania dla nich czy urządzeń dedykowanych. Pewnie to się zmieni, ale to poważna wada i nikt nie podnosi takiego lamentu. W wersji ODF 1.3 zostaną rozszerzone funkcje definiujące ułatwienia dla osób upośledzonych, standard OpenXML (ECMA 376) to posiada czy to jednak tak poważna wada. OpenXML ma poparcie kapitału i dorobku MS, ale to nie gwarantuje otwartości i multiplatformości. Specyfikacja tego formatu ma też wiele wad, standardem bym tego nie nazwał. Novell wprowadza do swojego pakietu OpenOffice OpenXML i wiem z autopsji, że ta implementacja natrafia na poważne trudności. Dokumenty otwarte w OO nie zachowują formatowania. To oznacza, że nie warto go popierać, jeżeli są takie problemy teraz mimo współpracy tych dwóch firm. ODF jest pod tym względem lepszy, Koffice a nawet WordPerfect go nieźle interpretują. Z bloga jednego z programistów OpenXML w WordPerfect jest nadal w fazie testów (nie mogę znaleźć tego adresu), ale podkreśla, że niektórych funkcji nie da się zaimplementować. OOXML zawiera także wiele błędów by być zgodny z MS Office, pytanie czy tak powinno być w standarcie. Ja uważam, że to śmieszne, produkt powinien być pozbawiany błędów. Firma uzasadnia to zgodnością wsteczną, ale dodatek do MS Office 2000 źle interpretuje ten format pomimo tych jakże koniecznych błędów, więc gdzie tu standaryzacja.

To czego przede wszystkim brakuje to rzetelne porównanie obu formatów, zarówno pod względem prawnym jak i technicznym. To co istnieje dzisiaj to krytyka OpenXML wychodzące a priori z założenia, że OpenXML jest zły bo został stworzony przez Microsoft. Fakty dopasowuje się do tej tezy. Równocześnie promuje się ODF w oparciu o równie aprioryczne założenie, że nawet jeśli jest on zły to i tak jest dobry bo nie został napisany przez Microsoft.

Przykładem niech będzie jeden z punktów listy zarzutów opublikowanych na GrokDoc i dotyczący funkcji skrótów. Krytykuje się tam OpenXML za rzekome "proponowanie własnych haszy, które prawie na pewno są dziurawe". Polecam najpierw lekturę tego punktu w GrokDoc Sprawdziłem to i co się okazało:

  • nie jest to żadna propozycja czy fragment standardu, tylko przykład kodu,
  • przykład jest użyty w zastosowaniu, które z bezpieczeństwem nie ma wiele wspólnego - chodzi o zabezpieczenie hasłem komórki arkusza kalkulacyjnego - komórki, której wartość i tak jest dostępna otwartym tekstem jeśli podejrzy się źródło dokumentu,
  • funkcja ta jest opcjonalna.

Ton zarzutów z GrokDoc jest w tym konktekście zwyczajnie rozdęty i przesadzony. Z drugiej strony OpenXML krytykuje się za niedopracowanie i niekompletność dokumentacji. To również postanowiłem sprawdzić i co się okazało:

  • ODF identycznej jak wyżej funkcji poświęca jeden akapit na 1/4 strony - jej opis w specyfikacji OpenXML zajmuje dwie strony,
  • ODF lakonicznie wspomina na końcu zdania, że do sprawdzania hasła można wykorzystać hasz - OpenXML opisuje to szczegółowo z opisem parametrów i przykładem kodu - tym samym, który wzbudził zarzut o "proponowanie nowego hasza".

W tym kontekście kolejny zarzut - czyli że dokumentacja OpenXML ma 6 tys. stron brzmi cokolwiek absurdalnie. Tym bardziej, że opisuje funkcje, których brak w ODF - takie jak podpis elektroniczny - a pozostałe opisuje bardzo szczegółowo niż ODF. Przypomina to nieco biblijną przypowieść o belce w oku :)

Bardzo rozbawiła mnie jakaś "niezależna analiza" sporządzona na zamówienie duńskiego rządu, okraszona stwierdzeniami w rodzaju "powszechnie uważa się, że OpenXML" - i tutaj następowały argumenty takie jak te przytoczone wyżej. Jeśli Duńczycy wydają publiczne pieniądze na podstawie takich analiz to życzę powodzenia.

Nie znaczy to bynajmniej, że popieram każdą decyzję o wdrożeniu czy aktualizacji softu Microsoftu w polskiej administracji publicznej. To co się działo wokół informatyzacji ZUS przez ostatnie 8 lat wskazuje, że decyzje mogły tam być podejmowane w oparciu o argumenty pozamerytoryczne, delikatnie rzecz ujmując. Nie znaczy to jednak, że każde takie wdrożenie jest z zasady złe i nieracjonalne (chociaż słysząc o planach wdrożenia Visty w ZUS mam wątpliwości).

Wstyd ze nie dali tego jako standardu. Obecnie podpis elektroniczny jest bardzo wazny, jak podkreslil to nawet sam autor artykulu. Przez to ODF w tej wersji jest archaiczny i nie zdziwilbym sie jakby przyjeli OpenXML jako kolejny standard. Dziwi mnie tylko jak ludzie moga byc glupi zeby zrobic taki blad?

W en.wiki napisali:
ODF 1.2 will incorporate XML-DSig, exactly the same as in OpenOffice.org

Świetniem tutaj jest dokładny link do tej propozycji:

http://lists.oasis-open.org/archives/office/200702/msg00085.html

Witam!

Jest to brak i to poważny ale nie jest to niezbędne do tego aby ten format stał się wiodącym formatem formularza elektronicznego.
Na bazie tego formatu można na prawdę bardzo wiele osiągnąć.
Nie upatrywał bym tu zagrożenia dla ODF gdyż zawsze specyfikacja tego formatu może zostać dostosowana do wymagań i potrzeb rynku - może należało by się zastanowić czy nie zgłosić tego do Oasis ..

Główny problem jest taki, że ODF miał być kompletną i otwartą alternatywą dla DOC i OpenXML. Sens stosowania takiego formatu polega na tym, że jest on kompletny i nie trzeba robić do niego lokalnych aneksów. W momencie kiedy pojawiają się rozszerzenia tracony jest cały sens standardu jako wspólnej i jednolitej platformy wymiany podpisanych dokumentów.

no nie zgodził bym się - na podobnej zasadzie działa specyfikacja OpenGL. Najpierw określono standard pisania sterowników zgodnych z OpenGL, a później producenci kart graficznych dodawali swoje rozszerzenia do tego standardu. Kiedy rozszerzenie wydaje się sensowne i jest popierane przez potrzeby rynku oraz przez OpenGL ARB (architecture review board), to staje się on standardową cechą nowej wersji specyfikacji OpenGL.
Jeśli jakiś producent sprzętu graficznego chce, by jego produkt był zgodny z najnowszą wersją specyfikacji OpenGL, to musi rozszerzyć możliwości swojego sprzętu.

Analogia do standardu ODF jest taka - twórca jakiegoś pakietu biurowego rozszerza możliwości swojego programu i dodaje to rozszerzenie do formatu ODF. Nic nie stoi na przeszkodzie aby to rozszerzenie włączyć do standardu w następnej jego wersji, jeśli zajdzie taka potrzeba.

Nie można zakładać, że raz ustanowiony standard będzie dobry zawsze. Więc trzeba go co jakiś czas rozwijać.

Taki model rozwoju, oparty na rozszerzeniach, które dodają podmioty zainteresowane w wykorzystaniu standardu, bardzo dobrze się sprawdził w przypadku OpenGL i jestem pewien, że podobnie będzie w przypadku ODF.

OpenGL i jego rozszerzenia to bardzo zły przykład. To właśnie dziesiątki wzajemnie dublujących się i niekompatybilnych rozszerzeń w OpenGL-u sprawiło, że twórcy (pod przewodnictwem 3Dlabs) postanowili zweryfikować swoje podejście do tego zagadnienia i stworzyć nową linię 2.0, która z założenia miała ograniczyć konieczność ich tworzenia do minimum. Osiągnięto to głównie dzięki wsprowadzeniu programowalnego potoku graficznego przez shadery oraz dodaniu (niestety wciąż nie będących częścią oficjalnej specyfikacji) obiektów bufora ramki (FBO).
To nie koniec zmian w OpenGL, najnowsze prace zupełnie zmieniają podejście do obiektów w tej bibliotece, do tego stopnia, że pranowane jest wprowadzenie odrębnego kontekstu do ich obsługi.

Do prawdy nie wyobrażam sobie, aby tuż po niedawnym ogłoszeniu ODF 1 wprowadzano zupełnie nowy standard ODF 2, bo setki wzajemnie niekomatybilych rozszerzeń sprawiły, że ten format przestał być interoperatywny w praktyce.

hmm... z tego co wiem to GLSL jest raczej wynikiem obecnej tendencji w rozwoju rynku kart graficznych, a nie powodem niesprawdzenia się systemu rozszerzeń. Ale spierał się nie będę - nie jestem ekspertem w tej dziedzinie.

A co do ODF to jest on rozwijany - obecna wersja to 1.1 i, jak już wcześniej w komentarzach wspomniano, niedługo wyjdzie wersja 1.2 dodająca do standardu podpis cyfrowy. Co więcej, szukając w necie można dowiedzieć się, że (chyba) KOffice w wersji 2.0 będzie wspierał wersję 1.2 standardu ODF, a tym samym przechowywanie w dokumentach podpisu cyfrowego.

Nie rozumiem czemu niektórzy są tak negatywnie nastawieni do rozwijania standardów. Czasem trzeba zmienić co nieco, żeby standard był sensowny w obecnych realiach. A że kompatybilność wsteczna jest zachowywana, to nie stanowi to żadnej uciążliwości dla użytkowników (w przeciwieństwie do niektórych nieregulowanych formatów zapisu dokumentów).

> hmm... z tego co wiem to GLSL jest raczej wynikiem obecnej tendencji w
> rozwoju rynku kart graficznych, a nie powodem niesprawdzenia się systemu
> rozszerzeń.

Też, ale nie tylko, jednym z głównych powodów stagnacji linii 1.x były problemy z zapanowaniem nad wykorzystywanycmi rozszerzeniami. Z jednej strony ARB funkcjonowało dość ospale, z drugiej każdy z producentów wprowadzał różne rozwiązania na własną rękę, nie bacząc na rozwiązania innych, i tworzył się coraz większy chaos, do tego stopnia, że z czasem twórcy gier chcący wykorzystywać w OpenGL-u zaawansowane możliwośći kart graficznych, musieli tworzyć odrębny kod dla każdego producenta.
Dość wspomnieć, że opis samych rozszerzeń NVIDII zajmuje ponad 500 stron,
więcej niż ma sama specyfikacja OpenGL (obecna 2.1 ma niecałe 400)!

Polecam prezentację 3Dlabs opisującą postępy w pracach nad standaryzacją OpenGL 2.0: http://www.13thmonkey.org/documentation/misc/ogl2.pdf

Rozszeżalność standardu nie jest wadą, ale jeśli dojdzie do sytuacji, w której rozszeżenia zaczną odgrywać kluczową rolę (tak było z OpenGL), to sytuacja zaczyna odwracać się przeciw niemu.

dzięki za link do pdf'a! choć dość stary materiał, to pozwolił mi zrozumieć na czym tak na prawdę polega różnica między OGL 1.x a 2.x.
wiedza ta przyda się niezmiernie!

BTW. trochę zeszliśmy z tematu - mam nadzieję, że redakcja się nie obrazi;)

Odpowiedź na tak postawione pytanie jest bardzo prosta - dlatego, że w ten sposób ODF nie jest standardem kompletnym i dopracowanym, co podkreślali jako zaletę ODF jego zwolennicy dla przeciwstawienia go "niedopracowaniu" OpenXML. No i nagle okazuje się, że nie mamy nic takiego jak "jeden ODF czyli ISO 26300" tylko ODF 1.0, ODF 1.1 i ODF 1.2, który na razie jest vaporware.

Co do rozwijania standardów to problem też jest bardzo prosty i bardzo konkretny. Jeśli administracja publiczna zamówi jakiś systemem i w SIWZ (specyfikacja zamówienia) napisze o formacie ISO 26300 czyli ODF to dostanie system zawierający dokładnie to co mówi - na dzień dzisiejszy - standard, i ani linijki kodu więcej. Każda modyfikacja - np. update do ODF 1.2 - systemu wdrożonego w skali 38 mln państwa to ogromne koszty bezpośrednie i pośrednie, wynikające z problemów z kompatybilnością oraz przekleństwa użytkowników.

Paweł Krawczyk

Co do samego standardu ODF to uważam, że jako standard dobrze spełnia swoje zadanie (jest ogólnodostępny dla wszystkich chcących go zaimplementować, a poza tym raczej nie słychać głosów o jakichś brakach w jego specyfikacji, które ograniczałyby możliwości programów go wykorzystujących - nawet jeśli brak w nim czegoś, to można dodać swoje własne rozszerzenia).
Poza tym największymi wadami OOXML jest to, że nie jest zgodny z wieloma istniejącymi standardami ISO (http://www.grokdoc.net/index.php/EOOXML_objections), oraz to, że jest opracowany przez jedną firmę i to przede wszystkim w oparciu o jej własne produkty.

Co do uaktualniania standardów i związanych z tym kosztów ponoszonych przez duże instytucje - tak samo jak w przypadku ODF, zmiany zachodzą w formatach dokumentów Microsoftu. Chcąc (potrzebując?) korzystać z nowych rozwiązań, trzeba zakupić nową wersję pakietu MS Office.
I jestem przekonany, że gdyby OOXML stał się standardem, to też by się rozwijał i byłby modyfikowany.
No i ponoszone koszty - nie sądzę, żeby aktualizacja jakiegoś niemicrosoftowego (czyli czasem nawet darmowego) pakietu biurowego wiązać się mogła z większymi kosztami niż zakup nowej wersji MS Office (od czasu do czasu wiąże się z koniecznością zakupu nowej wersji systemu operacyjnego, co w przypadku rozwiązań Microsoftu zwykle pociąga za sobą także konieczność wymiany sprzętu).
Do tego trzeba opłacić ludzi którzy zrealizują całe przedsięwzięcie.
W przypadku oprogramowania wspierającego standard ODF (które nie jest tworzone przez firmy praktykujące monopol) koszty aktualizacji to w wielu przypadkach co najwyżej koszty zainstalowania nowej wersji pakietu biurowego (tylko w przypadku kilku niewolnych pakietów dochodzą koszty zakupu). Poza tym taka aktualizacja niezmiernie rzadko wiąże się z wymianą systemu operacyjnego bądź to sprzętu, o czym bardzo dobrze wie każdy użytkownik niemicrosoftowych rozwiązań.
Jeśli nawet taka instytucja jak państwo nie może sobie pozwolić na używanie oprogramowania bez zakupienia wsparcia technicznego (oferowanego zarówno przez twórców darmowego jak i płatnego oprogramowania), to i tak takie koszty są mniejsze niż w przypadku korzystania z rozwiązań firm (w sumie - jednej firmy) niewspierających standardu ODF. Ta różnica w kosztach wsparcia technicznego jest logiczna - monopolista nie wspierający otwartych, zagrażających jego monopolowi, rozwiązań, wykorzystuje swoją monopolistyczną pozycję również w kwestii wsparcia technicznego.

A co do działań i decyzji naszej administracji publicznej, związanych z wyborem oprogramowania biurowego, to polecam poczytać czasem komentarze zamieszczane w internecie przez pracowników urzędów. Można się tam dowiedzieć z pierwszej ręki czym tak na prawdę kierują się osoby odpowiedzialne za przetargi na oprogramowanie.