Vizvary II Istvan wrote:

>> To jest odpowiedz na kolejny post. Coś TPI nie chce mi przyjąć odpowiedz
>> na crosspost. Nie mam czasu, by dochodzić niuanse serwera tpi,
>> więc próbuję tą droga.

Prawdopodobnie TPI w ogóle nie obsługuje tej moderowanej grupy
dyskusyjnej.

>>> A swoją drogą, zauważyłem, że boom zainteresowanie technologią
>>> JavaCard był jakieś 2 lata temu - czy ta technologia czasami nie
>>> wymiera? A może po prostu już nie jest reklamowana, bo toczy się
>>> już własnym pędem (efekt domina)?
>>
>>
>> Tak jest. W zasadzie jest to najbardziej dynamiczny segment rynku
>> SC. w 2001 56% wzrostu (ponad 110 mln kart) mimo spadku na GSM o
>> jakies 11% (chociaż nie wiem ile kart GSM było w technologii Java

Czy możesz podać źródło tych informacji? Przydało by mi się do
opracowania które piszę. Z GSM'em to ciekawa sprawa - niedawno widziałem
promocję na stronach Plusa, oferującą komórki z takimi kartami, tylko że
ich ceny są HORENDALNE.

>>> Z tego co obserwowałem na różnych witrynach internetowych
>>> producentów kart i czytników, to JavaCard jest nadal
>>> supportowana. Tylko nie mogę do końca dojść jak się ma JavaCard
>>> do OpenFramework. Czy to jest to samo?
>>
>>
>> JacaCard to specyfikacja karty wedle Sun. Obecnie karty są
>> dostepne wedle specyfikacji 2.1.2, zapowiadana jest specyfikacja
>> 2.2. Karty wedle 2.1.2 istnieja w wersji kompatybilnej z
>> OpenPlatform (obecnie Global Platform) VISA.

Czyli niezgodne z OP VISA też istnieją?

>> OpenCard Framework to z kolei grupa robocza, która pracuje
>> (pracowała?) nad standardem komunikacji PC-karta w postaci
>> rozbudowanych klas Java. Powstała z inicjatywy Sun i IBM rok po
>> tym, jak razem z MS utworzyły wspólną grupę robocza PC/SC.
>> OpenCard Framework jesienia ubiegłego roku zakończyła działalność
>> (niczym). Podejrzewam, że dlatego, że działała i tak tylko na
>> platformie Microsoftu.

Czyli rozumiem, że:
1. nie istnieje już wspólna grupa Sun, IBM i MS, która zajmujmowała się
standardem PC/SC a OCF jest już historią.
2. VISA dalej utrzymuje swoją wersję OCF, z którą jest kompatybilna
_część_ kart JSC w specyfikacji 2.1.2
3. Istnieje część kart zgodnych _tylko_ ze specyfikacją 2.1.2, która to
specyfikacja zostanie zastąpiona wersją 2.2 i prawdopodobnie znów tylko
część będzie kompatybilna z OCF VISA.

Czy dobrze kombinuję?

>> Jest API w karcie i możesz w PC robic dowolna rzecz z karta więc
>> taka komunikacja jest mozliwa. Ale bezpieczny kanał miedzy czym a
>> czym? Między aplikacja w stacji lokalnej a kartą ?

Oczywiście choidzi o lokalny kanał komunikacji kanał.

>> Ja bym inaczej ujął, bardziej ogólnie. Inteligencja kart zapewnia
>> różne mozliwości, by wyeliminować niektóre grożne w skutkach
>> mankamenty obecnych rozwiązań. Tyle, że jesli zakładamy, że znowu
>> wygoda bedzie wazniejsza niż bezpieczeństwo, to za chwilę wróci
>> stare.

Trudno się nie zgodzić. W ogóle trudno sobie wyobrazić, żeby
pospólstwo w ogóle było w stanie podejmować racjonalne decyzje,
której technologii używać. Spodziewam się, że wygodniejsze
technologie (a za razem mniej bezpieczne) będą do tego tańsze. Wyprą
więc z rynku rozwiązania bezpieczniejsze, ale mniej wygodne i do
tego droższe... I nie ma prostego rozwiązania problemu - bo chcąc
rozpowszechnić technologię i przekonać ludzi do rozwiązań niestety
trzeba iść na ustępstwa w łatwości użytkowania rozwiązań.
Alternatywą byłoby narzucenie przez państwo rozwiązań
bezpieczniejszych, ale prawdopodobnie w ogóle niezrozumiałych dla
przeciętnego śmiertelnika.

>>>> patrz wymienianie się przez dwóch prezydentów KARTAMI !!!! po
podpisaniu
>>>> w miejscu publicznym jakiegoś tam aktu).
>>>
>>>
>>> Hę? To ma niby być gest _zamiast_ wymieniania się teczkami?!?
>>
>>
>> Nie. Tak jak sie kiedys piórami sie wymieniali.

Nie, to dla mnie za skomplikowane. Tam gdzie kończy się rozum, tam
zaczyna się polityka.

>> nie zmieniają ani nawet nie śledzą danych, które przez nich
>> przechodzą.

Tak, wiem.

>> Certyfikacja więc powinno ograniczyć się do tego, by stwierdzić że
>> dany czytnik na prawdę nic nie robi. Podejrzewam, że przepisy
zaprzestana
>> na oświadczeniu producenta lub importera. (Akurat my jestesmy w takiej
>> komfortowej sytuacji, że możemy udostepnić żródła i driverów i
>> mikrokontrolera czytnika, a mimo tego uważam za bezsensowne
>> certyfikacje czytników z przyczyn które uprzednio wymieniłem).

Chyba troche przeholowałem z tym przykładem. Prawdopodobnie
ustawodawcy chodziło o cały procesz podpisywania a w szczególności
NOŚNIKI kluczy kryptograficznych.

>>> Ci kochani prawnicy... ogólnie myślę, że można by przyjąć dość
>>> szeroką definicję dokumentu - jako DANYCH (w odróżnieniu od
>>> PROGRAMU).
>>
>>
>> A ja mysle , że sprawa nie jest taka jednoznaczna. Program tez
>> mozna podpisać (nawet wypada czasami). Czy przestał byc programem
>> ?


Masz rację. Zapomniałem o zapewnianiu autentyczności i niezmienionej
postaci programu.

>> Czy jednak wtedy, gdy dany system ma działac w oparciu o ustawy o
>> podpisie cyfrowym, nie należałoby przynajmniej zastrzec, że dane
>> podpisane musz a mieć jednoznaczą wizualna postać, która ma byc
>> zaprezentowana przed podpisaniem?

Chyba jednak tak - dane moga byc tak zaszyfrowane, ze mozna z nich
przy odpowiednim kluczu wyluskac DOWOLNA wiadomosc.

> A tak na prawde mnie to wszysko nie przekonuje. Dla mnie ważne byłoby
> przede wszystkim by podpisane cyfrowo dokumenty można było PO podpisaniu
> ale przed wysłaniem archiwizować i zweryfikować własnymi narzędziami
> (niezaleznych producentów) , więc by i dokument i podpis były
> generowane w sposób standardowy.

Nie widzę problemu, żeby aplikacja do podpisu mogla tez weryfikowac
podpisany dokument. W gruncie rzeczy wystarczy miec dwa rozne programy,
zeby byc prawie pewnym, ze dokument zostal prawidlowo podpisany.

--
Greetings, -- mailto:m...@p...fm --
Marcin Cenkier "Let's assume that there's only one truth."