On Wed, 12 Mar 2014, antoszka wrote:
Tako rzecze Leszek Jakubowski (2014-03-11, 21:34):
Nie kwalifikowany, bo to jedno z gorszych rozwiązań w UE.
Czemu? (Serio pytam.)
Nawiązując do nieszczęsnego wątku o zamkniętej liście: nie wiem, czy możesz mi zaufać - ale moim zdaniem:
1. Problemy z natury rzeczy (X.509):
- Europejski podpis elektroniczny jest oparty o ceryfikaty X.509, które charakteryzują się hierarchicznym modelem zaufania, czyli mamy zaufany "root" a potem mamy jego "dzieci" a potem "wnuki" itp.
- "root" musi być a priori znany wszystkim użytkownikom
- "root" jest święty - nieautoryzowany dostęp do kluczy roota, czy też uzyskanie nieautoryzowanego podpisu kompromituje całą hierarchię podpisów (unieważnia wszystkie dokumenty?)
- znane są przypadki kompromitacji całego CA (Comodo, DigiNotar)
- X.509 zostało zaprojektowane do offline weryfikacji podpisu, w związku z czym korzysta się z tzw. CRL-i do ich sprawdzenia (kto z Was na bierząco aktualizuje swoje CRL-ki?); zostało to trochę załatane przez OCSP
- nie wiadomo jaki jest długoterminowy status prawny dokumentu podpisanego - co jeśli CA umrze albo po drodze padną jakieś serwery do weryfikacji?
(Polska ustawa o podpisie elektronicznym została uroczyście podpisana przez prezydenta Kwaśniewskiego certyfikatem firmy Signet, która potem została zlikwidowana i certyfikat główny Signetu został nieważniony - czy to znaczy, że dokument jest już nieważny? - szczegóły w CRL na http://nccert.pl/crl.htm)
- Nikt do tej pory nie wykazał, że hierarchia jest potrzebna (typu krajowy root - CA akredytowany przez państwo). Zaufanie do CA jest ostatnio dość wątpliwe i wcale nie jest pewne, czy CA jest pewniejszy od jakiegoś znanego nam kontrahenta biznesowego (całe istnienie CA jest potrzebne, aby weryfikować tożsamość kogoś nam wcześniej nieznanego).
- Mojego zaufania nie poprawia w ogóle, że niektóre CA mają gdzieś wersjonowanie dokumentu zwanego polityką certyfikacji, w ogóle bardzo ciężko dotrzeć do tego dokumentu (który mówi, "co i dlaczego podpisujemy") na podstawie nadanego OID (Zadanie domowe - pobrać dowolny certyfikat Sigillum i zobaczyć, czy da się programowo określić, jaka polityka ma zastosowanie).
2. Problemy wynikające z "zaufanego urządzenia"
Przepisy wymagają stosowania "zaufanego urządzenia" i wchodzi w to oprogramowanie do generowania i weryfikacji podpisu. W praktyce wygląda to tak, że każdy CA sprzedaje swoje karty procesorowe i oprogramowanie do nich. Jest bardzo trudne wykonanie podpisu taką kartą własnym oprogramowaniem (SDK do kart są zwykle bardzo drogie, a oprogramowanie przez siebie napisane nie będzie już "zaufane").
Praktycznie nie ma możliwości użycia karty CA numer 1 z oprogramowaniem CA numer 2 (wiem co mówię, bo posiadam dwie karty z podpisami kwalifikowanymi od dwóch CA).
W ten sposób o jakikolwiem free software do podpisu można zapomnieć; moim zdaniem jest to też powód, dla którego nikt nie akceptuje podpisu nigdzie - bo zaimplementowanie weryfikacji tożsamości np. w sklepie internetowym to jakaś masakra.
Praktycznie nie ma możliwości przechowywania podpisu kwalifikowanego w tokenach software'owych, potrzebna jest karta procesorowa lub tzw. HSM (sprzętowe kryptowadełko).
Do tego dochodzą problemy z certyfikatem instytucji (nie osoby fizycznej jej reprezentującej) - w praktyce jest tak, że pracownicy podpisują kartą pana dyrektora, który jest niejako "zakładnikiem" ustawy i pracowników. Albo podpisuje sam pracownik - zobaczcie, kto podpisuje Dzienniki Ustaw. Co będzie, gdy podpis pana Paczkowskiego zostanie unieważniony, bo urzędnik przestanie być urzędnikiem?
3. Kompletny brak interoperability między CA i krajami
Z powyższych powodów (zamknięty soft i hardware) oraz z ogromnych różnic między krajowymi CA nie da się użyć karty z kluczem z jednego kraju do podpisu w drugim. Sprawdziłem. Praktycznie każdy podmiot musi nauczyć się rozpoznawać każdy z "akceptowanych" CA - czyli polskie urzędy przyjmują polskie CA itp. To jest związane m. in. z konieczością określenia zaufanego roota. (Niemcy np. mają wszystkie CA w "zaufanym" katalogu LDAP, a nie w jednym pliku .crt jak u nas).
4. Europejski podpis kwalifikowany jako zabawka
Europejski podpis został skonstruowany jako "niewielkie" rozszerzenie do X.509, więc istniejący software ma niejakie problemy z wykorzystaniem tych certyfikatów. Moją ulubioną cechą jest to, że dodaje się w polskich certyfikatach ograniczenie użycia klucza (KeyUsage) z wartością ustawioną na nonRepudation, co powoduje, że oprogramowanie takie jak NSS nie rozpoznaje tych certyfikatów jako ważnych do podpisu np. zwykłego emaila. Gdzieś czytałem zresztą, że tak ma być, bo szlachetny certyfikat kwalifikowany ma być używany do szlachetnych celów, a nie np. na co dzień do podpisywania maili. (polskie CA sprzedają tzw. certyfikat zwykły, który do maili się nadaje, ale nie jest kwalifikowany).
Tu jest opis dodatkowych cech podpisu kwalifikowanego:
http://www.etsi.org/deliver/etsi_ts/101800_101899/101862/01.03.01_60/ts_1018...
Praktycznie sprowadza się to do dodania jednego atrybutu (OID 0.4.0.1862.1.1), który znaczy "uwaga, jestem kwalifikowany". Certyfikat może opcjonalnie zawierać ograniczenie kwoty podpisywanej transakcji, jednak nikt nie wie, jak taką kwotę się wylicza ani jak to kontrolować.
Skutek dodania tego artybutu - "embrace and extend" - jest taki, że nie podpiszemy kwalifikowanym zwykłego maila (patrz uwagi wyżej co do NSS i Mozilli) ani dokumentu w OpenOffice, który umożliwia złożenie podpisu elektronicznego w .odt (i nawet fajnie do działa, sprawdziłem!), ale to będzie normalny podpis XmlDSig, bez europejskich kwalifikowanych (i bezużytecznych) dodatków zdefiniowanych dopiero w standardach ETSI jak np. XADES http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_1019...
A na koniec należy dodać, że w ogóle milczy się o podstawowym zastosowaniu kryptografii klucza publicznego, czyli o szyfrowaniu dokumentu - dzięki atrybutowi "nonRepudiation" oprogramowanie nie powinno nam pozwolić zaszyfrować dokument w postaci do odczytania przez posiadacza podpisu kwalifikowanego.
Po latach zajmowania się podpiselem doszedłem do wniosku, że podpisywanie czegoś offline jako dokumentu jest użyteczne tylko do potwierdzenia, że nie został on później zmodyfikowany (w ten sposób podpisywałem niektóre dokumenty ODT).
Kryptografia klucza publicznego jest super do zabezpieczenia "tu i teraz" - czyli podczas transmisji, do autoryzacji jednego połączenia (SSH, HTTPS, ...) ale nie do przechowywania elektronicznych dokumentów z X.509 na długie lata.
[ Jak ktoś chce więcej pointerów, to jako ISOC Polska opublikowaliśmy w 2006 r stanowisko http://www.isoc.org.pl/bariery_podpisu_elektronicznego ]
//Marcin