Czy nie należy odesłać DER na emeryturę?

in

Czy dzisiaj, wobec dominacji XML wśród formatów dokumentu elektronicznego i protokołów sieciowych, nie należałoby stopniowo odchodzić od pochodzących z innego świata wtrąceń kodowanych w DER?

Mamy OOXML, ODF. Mamy też XAdES i XML-DSig, na którym wszystkie w/w się opierają. We wszystkich tych formatach występuje ciekawa zaszłość historyczna czyli element X509Data. Jest to kontener, który w drzewie XML przechowuje certyfikat X.509 jako plik w formacie DER zakodowany jako BASE64. Przykład:

W strukturze XML pole X509Data to wtręt z innego świata i z punktu widzenia aplikacji przetwarzającej dokument jest to struktura nieprzezroczysta. Żeby trochę ułatwić aplikacji wgląd w tę strukturę do drzewa XML skopiowane zostało kilka pól z certyfikatu (X509IssuerSerial, X509SubjectName itd) ale to tylko półśrodek.

Wgląd w pozostałe pola certyfikatu jest możliwy tylko w jeden sposób - przez odtworzenie takiego bloba i zdekodowanie DER. Wady takiego podejścia są następujące:

  • niższa efektywność - aplikacja przetwarzając drzewo XML musi uruchamiać dodatkowy dekoder DER
  • większa złożoność - poza jednym modułem do przetwarzania XML aplikacja musi używać drugiego - do DER; złożoność ma konsekwencje dla bezpieczeństwa - zamiast jednej dziury w parserze XML aplikacja będzie mieć ich dwie - drugą w parserze DER; oba dekodery są bardzo złożone, mają inną filozofię, inne standardy, API itd.
  • mniejsza funkcjonalność - ponieważ certyfikat nie jest integralną częścią drzewa XML, nie jest możliwe przeszukiwanie go za pomocą XPath i inne formy szybkiego przetwarzania

W jakim kierunku powinna pójść zatem ewolucja standardów elektronicznej tożsamości i podpisu elektronicznego?

Teoretycznie nic nie stoi na przeszkodzie by X.509 kodować jako XML, bo standard wyraźnie oddziela opis struktur (ASN.1) od kodowania (BER, DER). Istnieje nawet mało znane kodowanie XML Encoding Rules - XER (X.693) lub nowsze Robust XML Encoding Rules - RXER (RFC 4910), które można zastosować do zapisania certyfikatu X.509 jako struktury XML. Zachowują one jednak filozofię X.509.

W nieco szerszej perspektywie wydaje mi się jednak, że czas X.509 powoli przemija. Architektura X.509 ma wiele wad, z których głównymi są hermetyczność standardów, monumentalizm architektury oraz ograniczona funkcjonalność, łatana później za pomocą certyfikatów atrybutów i innych dodatków.

Być może rozwiązaniem byłaby filozofia SPKI/SDSI, opakowana w XML zamiast nieco archaicznych s-wyrażeń i pozbawiona niektórych wad XML-DSig?

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.

Praktyczne problemy powstające podczas obsługi dokumentów XML na styku z mechanizmem skrótu i podpisu pokazują, że sprawa zastąpienia blobów binarnych (np. certyfikatu w DER) obiektami XML nie jest w cale taka jednoznaczna. Wszędzie gdzie mamy skrót->podpis->weryfikację pojawia się wymaganie idealnie jednoznacznej reprezentacji dokumentów/obiektu, z którego wyliczany jest skrót do podpisu a później skrót do weryfikacji tego podpisu. Niestety reguły reprezentacji w XML są w paru miejscach "zbyt elastyczne" i dokument XML przechodząc przez kilka parserów, które coś w nim grzebią i "wydaje im się", że kodują ponownie nie zmieniając zawartości XML... mają tylko częściowo rację gdyż z punktu widzenia dokumentu XML faktycznie nic się nie zmienia ale binarnie dokument czasami ulega drobnym zmianom.

Jakie są skutki usunięcia (np) "nieznaczącej spacji" czy jakiś konsekwencji zagnieżdżeń obiektów, namespace itd itp. dla liczenia skrótu można sie domyśleć :)

Dlatego, na dzisiaj zwykle zaleca się częste sprowadzanie do postaci bloba tego co jest poddawane mechanizmom integralności/podpisu by właśnie uniknąć takich różnych pułapek.

Certyfikat to też pewien dokument podpisany wewnętrznie, jeśli byśmy bo zbudowali w postaci XML to będzie się bronił w miarę skutecznie do czasu gdy będzie samodzielnym dokumentem. Ale jak zaczniemy go zagnieżdżać i poddawać różnym transformacjom i kaskadowym przetwarzaniom w różnych warstwach (np. podpisany dokument XML wewnątrz protokołu WebService jakiegoś) czy aplikacjach, to prosimy się o ryzyko, że podpisany dokument/obiekt ulegnie minimalnej modyfikacji wynikającej z dopuszczalnych reguł manipulowania dokumentem XML, które niestety nie są dopuszczalne z punktu widzenia skrótu z treści binarnej.

Nie twierdzę, że "nie da się" tego uniknąć, ale praktyka pokazuje iż dzisiejsze aplikacje i narzędzia manipulujące dokumentami XML często "dodają coś od siebie" do dokumentów lub reguł ich parsowania pochodzących z niby tych samych standardów... a jednak czasami co innego różni autorzy z nich wyczytują lub po prostu popełniają błędy.

A z błędami jest tak, że często są weryfikowane na wysokim poziomi i do czasu gdy funkcjonalność działa to nikt nie wnika czy poniżej coś jest robione dokładnie w zgodzie ze standardem ;) I jeśli dokument XML zbudowany przez aplikację A jest poprawnie wczytany przez aplikację B to system idzie do produkcyjnego używania... ale gdy nagle ktoś do systemu wpuści dokumenty XML z podpisywaną zawartością to często wychodzą te różne nonszalanckie manipulacje na dokumentach XML i... podpisy przestają się weryfikować tylko po przesłaniu dokumentu przez kilka warstw (np. w środowisku SOA i WebService).

Pytanie czy uda się szybko poprawić jednoznaczność kodowania i transformacji dokumentów XML tak by można było szybko wprowadzić do nich bardziej eleganckie od blobów binarnych struktury XML? Na razie sprawdza się praktyka hybrydowa i pewnie długo jeszcze będzie trzeba z nią żyć, ale zgadzam się z autorem, że kierunek powinien być stopniowej migracji do "czystego XML" :)

Te problemy z XML też wiele mówią o dojrzałości technologii i standardów, na bazie których chcemy budować rozwiązania o tak wysokim poziomie złożoności jak podpis elektroniczny :)