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.

> Po prostu. Twoja aplikacja zwolni, inna sobie weżmie. Tak to juz jest. Chyba
> , że nie zwolnisz. To nie wezmie.

>>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.

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