Signaturwert enthält ungültige Zeichen für die BASE64-Kodierung

[germanchiefprogrammer]

Hallo zusammen,

bei einem Kunden meldet die Software des Steuerberaters des Kunden ein Fehler im DEP des Startbons.

Hier das DEP: { "Belege-Gruppe": [ { "Signaturzertifikat": "....", "Zertifizierungsstellen": ["....."], "Belege-kompakt": [ "eyJhbGciOiJFUzI1NiJ9..v4H-crgcTtB6PBbvgvsu3gNaJYa5PgCF4V1mB4XPBi3n6wh3e1IDxk9ur5itQlxFLer64orbyBqOEmyowuP90g" ] } ] }

Die Signatur ist oben im Original angegeben. Lediglich die Base64 Payload Daten wurden "geschwärzt".

Das Prüftool des Steuerberaters meldet in einem XML File:

Bei der Überprüfung des maschinenlesbaren Codes wurde ein Fehler in der BASE64-Kodierung des Signaturwertes festgestellt. Der Signaturwert enthält ungültige Zeichen für die BASE64-Kodierung. Hinweis: wenden Sie sich mit dieser Fehlermeldung an Ihren Kassenhersteller.

Das Prüftool "regkassen-demo-1.0.0" meldet alles in Ordnung!

Hat das Tool des Steuerberaters einen Fehler?

Welche Sonderzeichen sind denn in der Signatur zu ersetzen? Sind die Minus Zeichen zu ersetzen? Aber in der allseits bekannten Detailfragen Doku sind in den Beispielen ebenfalls Minus Zeichen drin.

Viele Grüße C

[germanchiefprogrammer]

Also ich denke das "-" Zeichen ist das Problem, oder? Wenn ich hier https://de.wikipedia.org/wiki/Base64 nachsehe, ist das Minus Zeichen nicht gültig. Ersetzt das irgendjemand hier oder wie macht ihr das? Die Signatur kommt ja genau so von A-Trust zurück.

[florian-aistleithner]

Nein das "-" ist kein Problem. JWS verlangt hier die base64url-Codierung, was im wesentlichen base64 ist nur dass statt "+" das "-" und statt dem "/" der Unterstrich verwendet wird. Das steht auch so im verlinkten Wikipedia-Artikel. Im QR-Code hingegen wäre der Unterstrich ein Problem in der Signatur, weil der als Trennzeichen verwendet wird, deswegen wird dort die "non-url-safe"-Variante verwendet.

[Phoniexk]

Also wenn Sie das gesamte DEP (und nicht die Einzelbelege) mit diesem Prüftool hier auf github prüfen und Sie erhalten überall PASS, dann hätte ich mal gesagt dass die Software vom Steuerberater fehlerhaft ist.

Sollte der Steuerberater ebenfalls das hier veröffentlichte Prüftool nutzen und erhält aber einen Fehler, dann können nur unterschiedliche DEP's verwendet worden sein. Sollte der Steuerberater eine eigene Prüfsoftware (es reicht schon wenn dieses Prüftool hier modifiziert wurde) einsetzen, dann würde ich mich gar nicht weiter damit rumschlagen. Das Problem muss der Steuerberater mit seinem Softwarehersteller klären.

Falls Sie selbst Änderungen im Prüftool vorgenommen haben (oder eine alte Version verwenden), dann nochmal die aktuelle Version von hier herunterladen und nochmal versuchen.

[florian-aistleithner]

Es könnte auch sein, dass die im Prüftool verwendeten crypto-files unterschiedlich sind. ZB ein Fehler in der Seriennummer des Zertifikats (hex vs dezimal-darstellung), o.ä.

[germanchiefprogrammer]

Das Problem scheint mir gefunden. Also die Prüfung des DEP bringt keinen Fehler.

Der Steuerberater prüft aber nicht wie mir fälschlicherweise berichtet wurde und oben beschrieben wurde das DEP(!) sondern den QR-Code (Startbeleg). Und im QR-Code ist als letzter Parameter nicht die kompakte Repräsentation (3. Teil - Signatur) (Base-64-url) sondern die Base-64 codierte Form dieser Signatur enthalten. (Details siehe Kapitel 4.1 ff im Detailfragen PDF). Dies ist korrekt oder?

PS.: Wenn dem so ist, warum ist eigentlich die Signatur im DEP nicht identisch mit der im QR-Code. Unterscheidung ist ja nur das -, + bzw. der / und _)? Das ist ja super unglücklich sehe ich vor lauter Wald schon die Bäume nicht mehr?

[andreasschiestl]

Meiner Meinung machen Sie alles richtig, im QR-Code ist für die Signatur Base64 zu verwenden, siehe Prozess 4.1 der Detailfragen

[florian-aistleithner]

Wenn dem so ist, warum ist eigentlich die Signatur im DEP nicht identisch mit der im QR-Code.

JWS (JSON Web Signature https://en.wikipedia.org/wiki/JSON_Web_Signature) verlangt in der Spezifikation in der Kompakt-Darstellung base64url. Das wurde von der Internet Engineering Task Force so festgelegt.

Im QR-Code würden die Unterstriche aber Probleme machen, weil die dort schon eine Bedeutung haben: Nämlich als Trennzeichen.

[andreasschiestl]

Auch wäre es irgendwie unsinning Base64 und Base64Url im QR-Code zu vermischen (Verkettungswert und Umsatzzähler)

[schuhlos]

Nun ja, das selbige Problem habe ich auch. Der Steuerberater prüft mittels BMF App den Startbeleg und erhält die gleiche Fehlermeldung. Das DEP wird per Prüftool fehlerfrei dargestellt. Habe mir dies angesehen und bin nach Pkt 4.1 vorgegangen (Danke für den Hinweis hätte ich übersehen).

[Phoniexk]

Aber ganz kann ich das nicht verstehen? Warum fällt dieser Umstand erst durch den Steuerberater auf?

Einerseits kann man doch mit dem Prüftool den Inhalt des QR-Code (maschinenlesbaren Code) prüfen und anderseits müsst ihr doch auch irgendwie prüfen ob die Startbelegprüfung mit BMF-App oder FON-Webservice funktioniert !?!?

[schuhlos]

Bin auch selber schuld da ich das Dokument zu ungenau gelesen habe. Denn hätte ich diesen Teil nicht übersprungen und davon ausgegangen dass dies nach Base64 konvertiert werden muss hätte alles gepasst. Kunde hat auch Druck gemacht und hat natürlich erst seine Kassen am 31.03 registriert. Kommt halt alles zusammen. Aber trotzdem danke germanchief und andreas die haben das klar erkannt.

[germanchiefprogrammer]

Also mittlerweile habe ich den Fehler gefunden. In der Tat war - wie bereits beschrieben - der Base64URL Code statt des Base64 Codes auf dem QR Code verwendet. Unser Fehler hier ;-)

Aber ganz kann ich das nicht verstehen? Warum fällt dieser Umstand erst durch den Steuerberater auf?

Der Steuerberater hat für den Kunden die BMF App geprüft. Hat sich aber auch erst im Lauf einiger Telefonate rausgestellt. Und ja, man hätte das Prüftool auch für den Maschinenlesbaren Code verwenden können. Dies hat aber bei mir anfangs nicht getan.