| Nummer | Fragen der Industrie | gematik |
|---|
|
| |
| 28 |
| |
| 27 | | |
| 26 | Bezüglich VSDM2/Popp-Client: Mir ist nicht klar, was hier der konkrete Zusammenhang mit der RSA/ECC Umstellung ist, für uns ist dies an sich ein getrenntes Thema.
Trotzdem ist für uns natürlich interessant, wie hier ein realistischer Zeitplan aussieht:
- Wann ist die Spezifikation für den PoPP-Client finalisiert?
- Wann stehen Testmöglichkeiten für den PoPP-Client und das VSDM2 bereit?
- Wann ist es in der RU verfügbar?
- Wann ist es in der PU verfügbar?
- Wieviel Zeit rechnet die Gematik hier für die Implementierung in den Primärsystemen ein um einen Termin am 1.1.2026 noch realistisch halten zu können? | Wir würden zum Workshop am 03.06.25 einen entsprechende Zeitplan mitbringen, aus dem die angefragten Daten hervorgehen. |
| 25 | Vorausgesetzt wir haben einen PTV6 Konnektor und ein Primärsystem, welches EEC bereits voll unterstützt.
- Welche konkreten Schritte/Prüfungen sind notwendig um sicherzustellen, dass es in der Umgebung der Praxis keine Komponenten mehr gibt, die bei der RSA-ECC-Umstellung ausfallen könnten.
- Haben die PTV6 Konnektoren eine Prüfmöglichkeit/Warnlisten oder ähnliches oder müssen wir als Primärsystemhersteller jede Komponente einzeln prüfen?
Gerne für den Workshop mitnehmen. Es sollte unserer Ansicht nach sehr detailliert für jede einzelne mögliche Komponente konkret dargestellt werden, wie wir als Primärsystemhersteller die Voraussetzungen in der Praxis Prüfen können und über die notwendigen Schritte informieren/warnen können. | |
| 24 | Spricht was dagegen, bei "SignDocument" den Crypt-Parameter IMMER auf "RSA_ECC" zu setzen, für alle Dokumente, nicht nur fürs E-Rezept, wie heute empfohlen? Oder gibt es Anwendungsfälle für die Signatur (insbesondere unser Hauptanwendungsfall EBZ), die noch nicht ECC-Ready sind? | Es wird empfohlen bei "SignDocument" den Crypt-Parameter immer auf "RSA_ECC" zu setzen. Die so entstandenen ECC-Signaturen (die PTV5-Konnektoren im Feld agieren mit dem Parameter ECC-preferred) können von allen prüfenden Komponenten der TI (EBK, HSK, BC) verifiziert werden. |
| 23 | "ca. 2/2 der Konnektoren haben Autoupdate aktiviert. " Wenn das stimmt hätten alle Konnektoren Auto Update aktiv. Stimmt das? Oder ein Schreibfehler | gemeint ist die Hälfte der Konnektoren |
| 22 | PoPP-Feature: Das neue PoPP-Feature (Proof of Patient Presence) muss in Ihre Systeme integriert werden. Alternativ können Sie die Interoperabilität mit einem separaten PoPP-Client sicherstellen. Wer muss alles PoPP realisieren? Apotheken, KIS, Software für Arztpraxen? Gibt es eine spez. Spezifikation? | - Alle Primärsysteme, die den LEIs Zugriff auf VSDM2, ePA oder eRezept ermöglichen, müssen zukünftig PoPP unterstützen.
- Es wird einen gesonderten ILF für PoPP geben. Der wird abgestimmt mit den ILFs für VSDM2 und ZETA (ZeroTrust Absicherung der TI 2.0 Fachdienste) erstellt. Eine initiale Veröffentlichung erfolgt zum 30.06.2025. Aktualisierung erfolgt iterativ in mehreren Veröffentlichungen |
| 21 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "ExternalAuthenticate" darin liegen, dass - der Eingabe-Parameter "dss:SignatureType" jetzt optional ist und nicht ausgewertet wird (da das Signaturverfahren über die Kartenversion bestimmt wird) und
- der Eingabe-Parameter "SIG:SignatureSchemes" nicht mehr bei G2.1-Karten ausgewertet wird?
| Ja, die Änderung ist hier ebenfalls analog wie oben. Der Parameter "SignatureType" wird nicht ausgewertet und das Signaturverfahren wird über die Kartenversion bestimmt. Sie können hier nichts parametrieren und müssen in der Response der Operation prüfen, welches Signaturverfahren Anwendung fand. Diese semantische Änderung in der Auswirkung des Parameters "SignatureType" so wie das diesbezüglich geänderte Verhalten der Operation stellen ebenfalls eins der "breaking changes" bei PTV6 dar. |
| 20 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "SignDocument" darin liegen, dass der Eingabe-Parameter "SIG: Crypt" - jetzt optional ist und
- nicht ausgewertet wird (da der Konnektor den Schlüssel abhängig vom Kartentyp gemäß TAB_KON_900 wählt)?
| Ja, die Änderung ist hier analog wie bei "EncryptDocument". Der Parameter "Crypt" wird nicht ausgewertet, daher ist er zwar syntaktisch optional aber semantisch nicht mehr. Das Primärsystem muss unabhängig vom CRYPT-Parameter sowohl mit RSA-Artefakten als auch mit ECC-Artefakten in der Antwort zurechtkommen. |
| 19 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "EncryptDocument" darin liegen, dass die Eingabe-Parameter "KeyReference" und "Crypt" - jetzt optional sind und
- nicht ausgewertet werden?
| Ja, die beiden Parameter werden nicht ausgewertet, daher sind sie zwar syntaktisch optional aber semantisch nicht mehr. Andersrum gesagt: Sie können hier nichts parametrieren. Das Primärsystem muss unabhängig vom CRYPT-Parameter sowohl mit RSA-Artefakten als auch mit ECC-Artefakten in der Antwort zurechtkommen. |
| 18 | Bei welchem Konnektor mit welcher Firmware-Version wird ein Downgrade von PTV6 auf eine PTV5-Version erfolgreich sein und bei welchen Kombinationen nicht? Gibt es hier Unterschiede zwischen RU- und PU-Konnektoren? | |
| 17 | Gibt es einen "Zeitpunkt", ab dem Primärsystemanbieter frei umstellen können und im Zweifel auch zurück können? | Anpassungen an Primärsystemen sollten abwärtskompatible implementiert werden und können dann ab sofort ausgerollt werden. |
| 16 | Wie erkennen wir, ob SMC-B, SMC-Kt und HBA ECC fähig sind? Methode am Konnektor? | In der Übersicht der gesteckten Karten oder der Antwort auf getCards kann die Version der Karte eingesehen werden. ECC fähig sind Karten ab folgenden Versionen SMC-B PTV 4.8.0 HBA PTV 4.7.1 gSMC-KT PTV 4.4.1 |
| 15 | Was ist denn wenn bei dem Wartungspairing kein Pairing Block mehr zur Verfügung steht? | Wenn kein freier Pairingblock vorhanden ist, überschreibt das Kartenterminal den ältesten Eintrag. |
| 14 | Welche gSMC-KT funktionieren? Wie wird die benötigte Version erkannt? | Für gSMC-KT wurde festgelegt, dass G2.0 Karten bis Ende 2026 weiterbenutzt werden können. Ein PTV6-Konnektor zeigt für alle gepairten Kartenterminals die verwendete Kryptographie (RSA, ECC) an. Der PTV6 Konnektor führt ein Wartungspairing mit den Kartenterminals durch, um das RSA Zertifikat durch das ECC-Zertifikat zu ersetzen. Voraussetzung ist, dass die Firmewareversion des Kartenterminals aktuell ist und eine G2.1 gSMC-KT steckt. Wird daher für ein Kartenterminal einige Tage nach dem PTV6 update immer noch RSA angezeigt, so steckt eine G2.0 gSMC-KT, die bis Ende 2026 getauscht werden muss. |
| 13 | Welcher Hersteller liefert wann PTV6 bzw. PTV2? | |
| 12 | Können Teams Kanäle ggf. genutzt werden, um Informationen weiter zu tragen? | Wir können relevante Informationen bzgl EBK/HSK auf RUaaS stellen. Dann könne sich die Hersteller darauf subscriben und wären up-to-date |
| 11 | Muss ich bei meinen EBK zum Stichtag das PTV6 nutzen oder kann es ggf. weitergehen? | Es kann ggf. weitergehen. Zum Zeitpunkt des RSA-Phasout (Abschaltung von RSA in der PKI) wird nur die PKI geändert. Ein PTV5 Konnektor könnte unter gewissen Voraussetzungen auch nach Phaseout funktionieren. Das hängt aber vom individuellen Setup/Situation der LEI ab (dualpersonalisiert? pairing der KTs) Das ist mit Risikoverbunden und wir raten davon ab. |
| 10 | Wenn ich PTV6 einspiele, kann ich dann ab dem Stichtag nur noch ECC machen? Verkürzt PTV6 diese Zeit (Stichtag)? | Man kann es so sehen, dass der PTV6 den SOG-IS Stichtag für PSe vorzieht. Hintergrund ist die Risikoreduzierung in Bezug auf die Verfügbarkeit. Ziel ist, nicht alle Aspekte der Nicht-Verwendung von RSA auf einen Schalter mit einem Mechanismus an einem festen Tag zu legen. |
| 9 | Ist PTV6 kostenpflichtig? | gematik regelt nicht die Kostenpflicht. TI-Pauschale gedeckt. |
| 8 | Müssen die PS Hersteller das PTV6 Update an die LE verteilen oder wird das Konnektor-intern erfolgen? | it depends... Wenn die LE die Auto-Update-Funktionalität des Konnektors nutzen (muss im Konnektor aktiviert sein, per default aktiv), dann holt sich der Konnektor automatisch das Update, sobald es zugelassen und durch gematik freigegeben ist. ca. 2/2 der Konnektoren haben Autoupdate aktiviert Wenn Autoupdate deaktiviert ist, dann muss sich der Inhaber des Konnektors (oder dessen beauftragten Dienstleister) selbst darum kümmern, dass das PTV6 Update installiert wird. |
| 7 | Nur nochmal zur Sicherheit: Erst klang es so, als ob ECC nach wie vor optional ist. Die letzte Aussage klang aber doch danach, als ob sofern ECC Material vorhanden ist, ECC forciert wird und nur falls RSA-Only Material vorhanden ist, RSA weiter bis zum Stichtag verwendet werden kann. Vielleicht kann das hier nochmal jemand konkretisieren. | Mit PTV6 wird die ECC-Nutzung durchgesetzt (sofern möglich). D.h., wenn ECC Material vorhanden ist, dann wird dies forciert genutzt und nicht das vorhandene RSA Material. Daher muss: - das PS jederzeit den Zustand der gesteckten Karten wissen (G2.0 Karte oder G2.1 Karte) und darauf basieren kann es das PTV6 Konnektorverhalten bei den Schnittstellenaufrufen vorhersehen.
- das PS sich die Rückgabe der relevanten Konnektoroperationen ansehen und darauf basierend ermitteln, ob die Rückgabe RSA- oder ECC basiert ist.
|
| 6 | Zur Frage von Hr. Haas: Nach meinem Verständnis macht der PTV6 ausschließlich ECC, d.h. wird PTV6 bei einem Kunden eingespielt, MUSS das AVS ECC machen - sonst funktioniert das AVS nicht mehr!
| Ein PTV6-Konnektor erzwingt bei Signaturerstellung die Nutzung von ECC-Kryptographie nur dann, wenn ECC-Schlüsselmaterial zur Verfügung steht. Der PTV6-Konnektor entscheidet selbst, unabhängig von übergebenen Parametern, ob er ECC oder RSA-Signatur erzeugt. Er kann natürlich nur dann sich für ECC entscheiden, wenn auch eine Karte zur Verfügung steht, die private ECC-Schlüssel enthält, also eine G2.1-Karte. Steht keine G2.1-Karte zur Verfügung, liefert der PTV6-Konnektor weiterhin RSA-Signaturen, er meldet nicht etwa einen Fehler. Das ist der grundlegende Unterschied zur Abschaltung von RSA, nach der definitiv keine RSA-basierten Artefakte mehr erzeugt werden. Für ein PS ist es daher bei der Signaturerzeugung mittels eines PTV6-Konnektors entscheidend, den Rückgabewert von SignDocument oder ExternalAuthenticate zu überprüfen, um zu erfahren, welchen Signatur zurück geliefert wurde, RSA oder ECC. Eine genaue Übersicht über die Unterschiede im Verhalten von PTV5- und PTV6-Konnekotren findet sich unter Übersicht des Verhaltens des PTV5- und PTV6-Konnektors (HSK PTV2) an der Clientsystemschnittstelle |
| 5 | Kommen die HSKs direkt mit PTV6 bzw. dessen API? | Die API für die PSe sind sind beim PTV2 HSK identisch zum EBK PTV6. Die derzeitigen HSKs im Feld sind PTV 1.x und haben noch EBK PTV5äquivalente Schnittstellen |
| 4 | "PSe sollten ihren Nutzern nahelegen....": ja, wirklich gerne! Aber wie kann man per einheitlicher oder jeweiliger Konnektor-Hersteller-Schnittstelle herausfinden, ob überhaupt Nur-RSA-Geräte/-Karten im Einsatz sind? | Sie können über ReadCertificate Zertifikate lesen und prüfen.
|
| 3 | Wenn der PTV6 kommt und dieser entscheidet das er nur ECC macht welche Komponenten müssen dann alle ECC können? KIM-Clientmodul, PVS... | direkt: die PVSe indirekt: Auch die Zentralen Dienste, welche die Daten vom Konnektor über die PSe eingereicht bekommen |
| 2 | Dass ein Konnektor, der sich mit RSA-Identität identifiziert, keine VPN-Verbindung zur TI aufbauen werden können wird ist verstanden. Wird die Client-Verbindung zum Konnektor auf ECC-Zertifikat aus der TI geprüft, dass bestimmte Dienste dann nicht möglich sein werden? Wenn ja, welche? Hintergrund: Das Umstellen eines Client-Zertifikats ist bei unseren Kunden oft mit nicht-unerheblichem Aufwand verbunden und erfordert eine zu planende Unterbrechung der TI-Verfügbarkeit für mehr als nur eine handvoll Nutzer | Diese Frage wurde unter ECC-Testwoche: FAQs, Issues and Solving in Punkt 18 beantwortet. |
| 1 | Gibt es ne Seite mit den PTV 6 Breaking Changes? oder muss ich das selber aus den Spec /ILF rausfischen? | |
