Przy próbie podpisania dokumentu certyfikatem z e-dowodu w formacie XAdES pojawia się błąd i komunikat “rsa key data expected”. Po wybraniu PAdES podpis certyfikatem z e-dowodu przebiega prawidłowo. Analogicznie wygląda sytuacja z podpisem certyfikatami EC (podobnie jak na e-dowodzie, szyfrowane krzywymi eliptycznymi) na kartach. Starszego typu certyfikaty RSA działają poprawnie zarówno dla PAdES jak i dla XAdES. Wygląda na to że w aplikacji NaskDESK do obsługi PAdES zaimplementowano zarówno RSA jak i EC a dla XAdES tylko RSA.
Zgadza się. To samo jest w przypadku EZD PUW.
Informacja z linii wsparcia PWPW dla e-dowodu osobistego w sprawie „rsa key data expected”:
Dzień dobry,
Komunikat nie pochodzi z naszej biblioteki i sugeruje, że wymagany jest certyfikat RSA, a certyfikaty na e-dowodzie są certyfikatami EC.Podsumowując zgłoszenie :
- nie jest to wina biblioteki PKCS#11,
- biblioteka zachowuje się prawidłowo,
- rodzaj pliku oraz podpisu nie ma wpływu na działanie biblioteki,
- na edowodzie certyfikaty rządowe są wydane na krzywych eliptycznych, certyfikaty kwalifikowane na edowodzie oraz na kartach CUZ standardowo wydawane są na kluczach RSA,
- oprogramowanie NASK dla formatu PAdES potrafi obsłużyć klucze na krzywych eliptycznych oraz RSA dlatego podpis wykonuje się prawidłowo w obu przypadkach,
- oprogramowanie NASK dla formatu XAdES nie potrafi obsłużyć kluczy na krzywych eliptycznych i oczekuje kluczy RSA, dlatego podpis certyfikatem rządowym się nie udaje, a podpis certyfikatem kwalifikowanym się udaje.
Z naszej strony zalecalibyśmy kontakt z NASK i poproszenie o dodania wsparcia w ich oprogramowaniu dla kluczy na krzywych eliptycznych dla formatu XAdES analogicznie jak robią to dla formatu PAdES.
Pozdrawiamy, Zespół eDO
1 polubienie
Ze swojej strony zgłosiłem ten problem i potrzebę naprawy do CRM EZD PUW.
Jeśli macie dostęp do wsparcia NASK-u dla EZD RP to zgłoście analogiczną potrzebę naprawy.
Bo to naprawdę nie jest jakieś rocket science dodanie obsług certyfikatów EC.
Sam wczoraj przy wsparciu AI napisałem aplikację w Pythonie, która mi podpisuje PAdES, XAdES za pomocą certyfikatów EC (e-dowód osobisty) i RSA (Sigillum karta BLUE) przy wsparciu DSS Demonstration WebApp (tworzy poprawną strukturę wyjściową podpisanych danych).
1 polubienie
Otrzymałem zaiste ekscytującą odpowiedź na moje zgłoszenie o potrzebie dodania obsługi EC w EZD PUW:
„Addin wymaga certyfikatów RSA. W tym momencie prace które miały by na celu rozszerzenie możliwość podpisywania o certyfikaty EC nie są prowadzone.
Możliwe, że będzie to jeszcze zaplanowane.
W tym momencie proszę korzystać z certyfikatów kwalifikowanych.
Zamykam zgłoszenie.”
Czyli tak:
- nie ma obsługi bezpłatnych podpisów osobistych
- dodatki EZD AddIn oraz Nask Desk (bliźniacze aplikacje - z tymi samym problemami) nie mają wersji dla systemów Linux oraz MacOS. Wymuszenie korzystania z Windows.
Ciekawie to wygląda w kontekście obowiązku zapewniania przez Państwo neutralności technologicznej w systemach rozwijanych z pieniądze z budżetu państwa.
Przypominam przepis z ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne:
neutralność technologiczna - zasada równego traktowania przez władze publiczne technologii teleinformatycznych i tworzenia warunków do ich uczciwej konkurencji, w tym zapobiegania możliwości eliminacji technologii konkurencyjnych przy rozbudowie i modyfikacji eksploatowanych systemów teleinformatycznych lub przy tworzeniu konkurencyjnych produktów i rozwiązań;
Pięknie to współbrzmi z tym:
Analiza Fundacji Instrat wskazuje, że 99% przeanalizowanych zamówień publicznych bezpośrednio lub pośrednio wyklucza produkty inne niż oferowane przez Microsoft. Do zamówień wprost wykluczających konkurencję eksperci zaliczyli aż 20% zamówień. Prawie cała reszta zawierała zapisy, które wykluczały konkurencję na inne sposoby, np. wymagając, by interfejs zawierał elementy 3D. Tylko jedno postępowanie zaklasyfikowano jako nie preferujące Microsoftu – przeprowadził je Narodowy Instytut Fryderyka Chopina.
1 polubienie