Najbardziej mnie bawią te radosne druki z ZUSu (nota bene, nie można ich wydrukować samemu co uważam za totalny absurd), kiedyś wypełniłem wszystkie okienka i mnie odesłali, bo “za dużo danych i niezgodnie z instrukcją”. Instrukcja jest taka: “Wpisać NIP i REGON, a w razie gdy płatnikowi składek nie nadano tych numerów lub jednego z nich - numer PESEL; jeśli płatnikowi nie nadano również numeru PESEL - serię i numer dowodu osobistego albo paszportu. Tym samym numer PESEL, seria i numer dowodu osobistego albo paszportu powinny być podawane jedynie wówczas, gdy płatnik nie posiada identyfikatorów NIP i REGON lub jednego z nich”… Po prostu piękne.

A co do ustawy, to pewnie największy problem z propozycją Patrysa byłby w pogodzeniu jej z ustawą o ochoronie danych. Nie dotarłem wprawdzie do tego jak jest teraz, ale w/g pomyłu Patrysa wszyscy dostają przynajmniej interfejs do tłumaczenia klucz publiczny -> imie i nazwisko + pewnie jeszcze jaką informacja, bo np. Janów Kowalskich to trochę jest. Pewnie lepszym rozwiązaniem byłoby api w stylu klucz + imie + nazwisko + pesel/nr. dowodu/cokolwiek -> weryfikacja zgodności (tu dochodzi konieczność zmiany klucza przy zmianie innych danych). No bo na wprowadzenie jednego numeru na chipie w dowodzie liczyć w najbliższej przyszłości nie można.

I podzielam zdanie Budynia — ograniczyć burdel robiąc jeden identyfikator — mikrochipowy dowód osobisty, który jednocześnie byłby elektronicznym sygnetem, a przy okazji może nawet dałoby się jakoś e-voting na tym oprzeć i ustrzelić dwa ptaki jednym strzałem? (choć to już całkiem insza inszość).

Z czym zostanie połączony klucz to jedna kwestia. Mi chodzi bardziej o to, że PGP nadaje się do składania podpisów, ma dużo szersze zastosowania niż kwalifikowane certyfikaty i przede wszystkim dużo prościej jest taki klucz unieważnić i wymienić.

Gdzie niby ta Pani ma wpisać ‘truncate’ ? To się na na poziomie MySQL/phpMyAdmin wyłączyć (nie wierzę, że tego nie wiesz), poza tym Pani nie będzie miała dostępu do RDBMSa, tylko do ładnego GUI do procedur składowanych i tyle… poza tym - wierz lub nie - ale administracja ma do dyspozycji naprawdę dobrych specjalistów; dość, by to co opisał Patrys wdrożyć. Tylko że fatalnie z nich korzysta, a poza tym w takim układzie nie zarobiłby żadnen Prokom - więc sprawa nie przejdzie. W Polsce to nie technika, ani nawet nie kapitał są barierami - tyklo mentalność i KULTURA ORGANIZACYJNA. I tak w Polsce jedną prostą korwetę buduje się tyle, co we Francji atomowy okręt podwodny, a w rok naprawia tyle torów kolejowych, ile Brytyjczycy wymieniają w weekend.

@Patrys

Informatyzacja to nie jest przenoszenie istniejącego bałaganu do komputerów, ew. tworzenie nowego… problem polega na tym, że w Polsce NIPów, PESELi (a jak masz działalność, to i REGONów) masz stanowczo za dużo. Wystarczyłby, po amerykańsku jeden identyfikator jawny (np. PESEL(2)) i jeden klucz, zapisany na JEDNYM dokumencie którym byłby dowód osobisty w postaci karty mikroprocesorowej. Zauważ, że poręczny kod kreskowy mógłby być indentyfikatorem jawnym - służącym tylko do wskazania lokalizacji / nazwy klucza w systemie. Takie narodowe OpenID…

Mój klucz publiczny jest powszechnie dostępny, nie trzeba go chronić. Do podpisania potrzebny jest klucz prywatny, którego nie zamierzam rządowi nigdy pokazywać (na tym polega cała idea PGP).

Ale trzeba pamiętać o specyfice użytkowników. To powinno być coś fizycznego, jak dowód osobisty czy karta kredytowa. To komplikuje oczywiście cały proces i podnosi koszt, ale trzeba pamiętać, że potencjalni użytkownicy będą przypominać raczej klientów naszej-klasy niż czytelników tego bloga.

A wychodzę z założenia, że statystyczny Polak łatwiej zabezpieczy przed kradzieżą kartę w swoim portfelu niż plik na swoim dysku.

Z tego samego powodu, jeśli trzymać się PGP, od razu musiałbyś mieć kryteria określające “dostatecznie mocne” hasło i nie pozwalające użyć kluczy słabo zabezpieczonych (względnie proste jeśli klucz przechowywany jest na karcie chipowej, trudniejsze jeśli utrzymujesz go w postaci pliku na prywatnym komputerze) . Inaczej użytkownicy pójdą po najmniejszej linii oporu i nie zabezpieczą hasłem w ogóle, lub użyją hasła ze słownika. I założenie “nikt nie będzie kradł kluczy, bo nie wystarczy mu mocy na łamanie haseł” stanie się fantazją.

Niestety nie można tu powiedzieć “jak się nie zabezpieczysz odpowiednio to sam sobie jesteś winien”, bo system implementowany na taką skalę powinien jednak wymuszać pewien minimalny poziom bezpieczeństwa.

“Przenośne implementacje PGP z w pełni otwartym kodem istnieją od dawna”

Pewnie, że tak. Kryptografia też stoi mocno, mamy nawet w Polsce masę ludzi którzy się naprawdę na tym znają. Problem w tym, że nie ma odpowiedniego nasycenia fachowcami w tych warstwach, które podejmują decyzje, hmm, “administracyjne”. Myślę, że w takich projektach większy udział powinny brać ośrodki akademickie. Może nawet na zasadzie opracowywania konkurencyjnych rozwiązań (Kraków kontra Warszawa kontra Wrocław…). Oczywiście bez dodatkowych dotacji ze skarbu państwa, dla samego prestiżu. No, zwycięzca mógłby dostać jakiś grant uznaniowy.

Implementację może już potem robić firma z przetargu, ale architekturę powinni opracowywać naukowcy i specjaliści z danej dziedziny (i oczywiście API/protokoły powinny być jawne).

“są też w powszechnym użyciu w innych aplikacjach (klient e-mail, komunikator)”

W powszechnym użyciu jest też SMTP, a wiadomo jakie są z nim problemy… ;)

- klucz przechowywany nie wiadomo gdzie, bo raz na USB, raz na karcie chipowej, raz w katalogu z pr0nem a raz … etc
- 1337 dostępnych programów obsługujących kodowanie za pomocą klucza

lub

- jeden z 4rech programów każdy powiązany ze specyficznym kluczem używanym w określonych momentach

i jeśli pamiętać, że przeciętny ZU jest fanem przechowywania wirusów, trojanów i keyloggerów w swoim komputerze to … rozwiązanie Patrysa wcale nie wydaje mi się mniej bezpieczne.