“Der Acrobat Reader ist eine proprietäre Software und nicht auf allen Plattformen verfügbar. Im Sinne einer allgemeinen Verfügbarkeit ist das großer Nachteil.
Das gleiche gilt für Secsigner, soweit ich weiß.”
Allgemeine Verfügbarkeit bedeutet für die nichttechnische Allgemeinheit: Windows. Die “allgemeine Verfügbarkeit”, die man in der Linux-Blase gerne meint, ist nichts anderes als faktische Nicht-Verfügbarkeit bzw. Nicht-Nutzbarkeit ohne Klimmzüge.
Der Secsigner ist übrigens für Windows, Apple, Linux und pures Java verfügbar.
Nicht nur Acrobat Reader, sondern auch andere PDF-Anwendungen wie PDF XChange zeigen qualifizierte Signaturen standardmäßig an - nur eben leider keine abgetrennten Signaturen.
Was die EU-Seite angeht: dort gibt es die Option “Send original file(s) as…” (Hash). Damit sollte eigentlich ein Übertragen der Originaldatei vermieden werden. Technisch wird jedenfalls nur der Hashwert der PDF-Datei benötigt, den auch der Browser lokal generieren und übertragen kann.
Ja, eigentlich sind detached signaturen ja auch das coolere (So wie es GnuPG ja standardmässig macht) weil man dann verifizieren kann bevor man ein möglicherweise schädliches Dokument öffnet.
Was wir mit Okular machen sind aber tatsächlich dann die sog. PDFSIG signaturen also die eingebauten zu erstellen und zu verifizieren, das ist halt eher das gebräuchliche und nach EIDAS auch das rechtsverbindliche.
grob habe ich eine Idee davon, was Du mit “Linux-Blase” meinst.
Unschön finde ich die Abwertung die ich da herauslese.
Ich denke es ist wichtig, das wir bei zentraler Infrastruktur die Möglichkeiten der demokratischen Kontrolle haben, welche Freie Software bietet und die Möglichkeit,
notwendige Software auf Hardware der eigenen Wahl zu betreiben.
Es ist gut, wenn es den SecSigner plattformunabhängig gibt, von https://seccommerce.com/download-secsigner-secsign-id/ Danke für den Hinweis! Besser als die Situation beim Acrobat Reader (als ich das letzte Mal geschaut habe), den bekomme ich wohl auf einem ARM Rechner wie einem Rasperry Pi 4 nicht ans laufen.
Die Code-Kontrolle durch Dritte scheint der Secsigner noch nicht zu ermöglichen.
das ist keine Abwertung, nur Frust über die tatsächliche Wertlosigkeit vieler Linux-Lösungen für die tägliche Arbeit.
Funktionierende PDF-Software auf einem Client ist keine “zentrale Infrastruktur”, und unter Linux mangelt es hier an allen Ecken. Betrachten geht vielleicht noch, aber Ordnen, Drehen, Aussortieren, Stempeln oder eben Signieren: da wird es leider düster.
Ich weiß auch nicht, was “demokratische Kontrolle” bringen soll, wenn etwas nicht funktioniert. Und ich habe wirklich über Jahre mehrfach versucht, mit meinem Client auf Linux zu wechseln und habe jedesmal frustriert aufgegeben, weil viele wichtige Anwendungen einfach nicht vorhanden sind.
Übrigens: “Okular” … als PDF reader mit voller GnuPG anbindung zur überprüfung und erstellung von signierten PDFs? Wird denn eine der handelsüblichen qualifizierten Signaturkarten auch von GPG erkannt werden? Das wäre nämlich die Grundvoraussetzung für qualifiziertes Signieren.
Klar, ob telesec oder D-Trust (Bundesdruckerei). Nenn mir lieber eine die nicht anerkannt wird, dann schauen wir uns die an.
Personalausweis ist leider ein ganz eigenes Thema. Da habe ich pläne für aber die sind noch im bereich der “Vision”. Da muss man leider unserer Regierung danken das die nicht einfach einen Handelsüblichen Krypto chip auf die Ausweise gemacht hat sondern was tolles eigenes brauchte. Wär ja auch zu schön wenn jeder mit seinem Ausweis mails entschlüsseln und signieren kann
ach, der Personalausweis könnte das, die Hardware ist nicht das Problem. Es gibt nur leider keinen Dienstleister (mehr), der diese Nachladesignaturen verkauft. Aber es gibt ja zum Trost noch Krankenversicherungs-Chipkarten, die auch fast jeder hat, und SIM-Karten im Handy, Volksverschlüsselung und DeMail, da ist für jeden was dabei - nur nichts Funktionierendes.
Angeblich kommt ja von der EU demnächst eine “europäische digitale Identität”.
Kann es sein, daß du “erkennen” und “anerkennen” durcheinanderbringst? “Anerkennen” braucht nicht viel, um Signaturen zu prüfen. Angeblich kann Okular ja aber signieren, dazu muß Okular den Signaturschlüssel erkennen, um ihn anwenden zu können.
Laut Hilfe sucht Okular hier nach Schlüsseln:
Zurzeit versucht Poppler, einen der folgenden NSS-Zertifikatsspeicher der Reihe nach zu benutzen und verwendet den ersten gefundenen Zertifikatsspeicher:
Der Zertifikatsspeicher des aktuellen Firefox-Benutzers.
Den systemweiten Zertifikatsspeicher /etc/pki/nssdb.
Die Datei $HOME/.pki/nssdb des aktuellen Benutzers
Wenn Sie einen benutzerdefinierten Zertifikatspeicher verwenden möchten, können Sie diesen im Abschnitt PDF-Anzeigemodul im Dialog Anzeigemodule einrichten … einstellen.
Es gibt aber wohl keinen QES-Anbieter, der dort seine Schlüssel hinterlegt. Der Signaturschlüssel ist entweder auf einer Smartcard hinterlegt oder bei Fernsignatur beim QES-Anbieter. Folgerichtig erkennt Okular auch weder eine DGN-QES-Karte noch eine DATEV-Signaturkarte (die noch nicht einmal QES bietet).
Da ist die Dokumentation noch veraltet, wir haben das GnuPG Backend ja gerade erst frisch eingebaut. Früher gab es da nur das NSS backend, unter Linux kannst du zwischen NSS und GPG wählen, und in der Gpg4win Version von Okular ist halt GnuPG jetzt voreingestellt. Du solltest mit allen Karten / Zertifikaten signieren können die Kleopatra dir auch anzeigt bzw erkennt.
Wenn du unter tools configure backends gehst siehst du jetzt sowas:
Das Okular in Gpg4win verwendet GnuPG als Krypto-Backend und sucht dann dort nach den öffentlichen Schlüsseln (aka Zertifikate) und den privaten. Deshalb musst Du in die GnuPG Dokumentation schauen.
Aber: Wie oben schon gesagt. Es ist zur Zeit leider schwer zu konfigurieren.
Dann kann es der Krypto-Motor drunter auch nicht. Der nächste Schritt wäre, da mehr Diagnose-Ausgabe einzuschalten, um herauszubekommen, was das genau für Karten und Kartenlesegeräte sind.
Das mit dem “stärker hervorheben” in Verbindung mit dem Screenshot verstehe ich nicht. Auf den ersten Blick ist keines der dort aufgelisteten Zertifikate ein qualifiziertes.
Die beiden Karten sind handelsübliche, aktuelle, funktionierende Signaturkarten, wie sie die Anbieter eben so anbieten. Ich kann von einem QES-Anbieter nicht verlangen, die Zertifikate auf einer GnuPG-Karte auszuliefern.
Also ist das Ergebnis zur Zeit: Okular/GnuPG/GPG4Win können nicht qualifiziert signieren. Und ich wage die Prognose: das wird auch in 10 Jahren noch so sein.
Das ist unfug. Wir können mit D-Trust und Telesec karten umgehen. Das das bei dir nicht klappt, weiß ich nicht warum. Das wäre dann Support. Eventuell mal pcsc-shared in deine %APPDATA%\gnupg\scdaemon.conf schreiben. Falls da eine andere Anwendung bei dir auch noch drauf zu greift.
Wir und unsere Kunden erstellen jetzt schon Qualifizierte Elektronische Signaturen mit GnuPG.
Oder schau dir mal an was gpgsm --learn-card auf der kommandozeile ausgibt.
Ich habe gerade keine Liste welche von den Karten in Deutschland noch nicht funktioniert, aber die gebräuchlichste ist ja wohl die D-Trust Karte von der Bundesdruckerei und die unterstützen wir.
@alant obwohl es bei Dir nicht geht, kann es ja bei anderen gehen. Es lohnt sich dann aber nicht die Situation ins Falsche zu verkürzen und zu behaupten, es würde überhaupt nicht gehen.
Es ist aber auch nicht fair, immer gleich abschätzig über “proprietäre” Software zu urteilen, und gleichzeitig selbst nur halbgare Lösungen anzubieten, die nur gegen kostenpflichtigen (oder zeitaufwendigen eigenen) Support zum Laufen zu bekommen sind.
Das ist schön für euch und eure Kunden, aber als Privatmensch, der funktionierend qualifiziert signieren will, ist der Secsigner dann bestimmt die preiswertere Lösung, selbst wenn ich dort eine Lizenz kaufe. Oder was kostet dieser “Support”, wenn es eine lauffähige Installation sein soll?
Da bin ich offen: Noch ist die Kombination Okular/GnuPG für qualifizierte Signaturen nicht leicht einsetzbar. Aber sie existiert und wird einsetzbarer. Für manche Nutzenden geht das leichter, für andere schwerer.
Die allgemeinen Nachteile von proprietärer Software bleiben jedoch - davon unberührt - bestehen. Deshalb arbeiten wir ja daran (mit den uns verfügbaren Mitteln) die Freie Software-Lösungen zu verbesseren, was allen zu Gute kommt.
Ja komm dann lass uns doch mal herausfinden warum das bei dir nicht geht.
Also support in der Hoffnung das wir unsere defaults so ändern können das das in Zukunft nicht notwendig ist.
Also als erstes mal unter %APPDATA%\gnupg\scdaemon.conf
pcsc-shared
eintragen.
C:\Users\user>gpgconf --kill all
C:\Users\user>gpgsm --learn-card
gpgsm: error learning card: No such device
C:\Users\user>gpgsm --learn-card
C:\Users\user>gpgconf --kill all
C:\Users\user>gpgsm --learn-card
C:\Users\user>
Da fehlt wohl noch irgendwas. Ab dem zweiten “learn-card” war der Kartenleser angeschlossen, Karte steckte. Eine Ausgabe erfolgt nicht.
Oh ok. Da hatte ich dann mit einer Fehlermeldung gerechnet. Weil Kleopatra ja nichts anzeigt. Das scheint dann schonmal funktioniert zu haben.
Mit “gpgsm --list-secret-keys” werden aber nicht die Zertifikate von deiner Karte gelistet und Sie sind auch nicht in Kleopatra vorhanden?
Dann wäre
Dann wäre ich als nächstes mal auf die ausgabe von
“gpg-card” gespannt (so zusammengeschrieben das ist ein eigenes programm)
Da kannst du auch mit “help” dir alle befehle anzeigen lassen und mit “quit” kommst du wieder raus. Mich intressiert die Ausgabe von “list” aber die wird direkt beim start angegeben.
Richtig. Nur zwei in Kleopatra installierte Softzertifikate werden aufgeführt.
C:\Users\user>gpg-card
Reader ...........: REINER SCT cyberJack RFID standard USB 1
Serial number ....: (20stellige Seriennummer)
Application type .: DINSIG
gpg/card>
Nur zur Klarstellung: es steckt während dieser Befehle eine qualifizierte DGN-Signaturkarte. Die hat gegenüber anderen Karten unter Windows die Besonderheit, daß sie keine Middleware braucht. (Aber mit einer DATEV-Karte, die eine Middleware hat, klappt es auch nicht.)
