Errata zu Release Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb. Release 1.4.6

Transkript

1 Einführung der Gesundheitskarte Errata zu Release Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb führt zu Release Version: Stand: Status: freigegeben Klassifizierung: öffentlich Referenzierung: [gemerrata_r1.4.6] gemerrata_r1.4.6.xlsx gematik - öffentlich Seite 1 von 4

2 Betroffene Produkttypen Neue Produkttypversion KSR Namensdienst OCSP-Proxy Sicherheitsgateway KV-SaveNet TSP-x TSL-Dienst VPN-Zugangsdienst Zeitdienst Zentrales Netz VSDM VSDD VSDM CMS VSDM UFS VSDM Intermediär Störungsampel TSP-SSt SMC-B (personalisiert) HSM-B in Vorbereitung Konnektor Konnektor (mit QES) gemerrata_r1.4.6.xlsx gematik - öffentlich Seite 2 von 4

3 Details C_4757 ID Dokument Quelle Dokument und/oder Kapitel ARV_706.3_Spec_SST_Stör ungsampel_teil2_v1.1.0.doc ARV_706.3_SPEC_ SST_STAMPEL_AF O_0010 Zertifikatsprüfung Servicepunkt Web- Service Beschreibung der Änderung Anpassungen an Afos; TUCs, Tabellen, Korrekturen von Änderung betroffene Dokumente In der Anforderung steht: "Der Sender von Daten an die Störungsampel KANN die Vertrauenswürdigkeit der Verbindung durch die Auswertung des Serverzertifikats überprüfen." Um das erforderliche Schutzniveau "hoch" für das Schutzziel "Vertraulichkeit" für die Kommunikation über die Schnittstelle I_Monitoring_Update zu erreichen muss das Serverzertifikat der Störungsampel geprüft werden. ARV_706.3_SPEC_SST_STAMPEL_AFO_0010 wird geändert: alt Der Sender von Daten an die Störungsampel KANN die Vertrauenswürdigkeit der Verbindung durch Nachweis der Gültigkeit des Serverzertifikats überprüfen. neu: Der Sender von Daten an die Störungsampel SOLL die Vertrauenswürdigkeit der Verbindung durch die Prüfung des Serverzertifikats überprüfen. Die Prüfung SOLL gemäß gemspec_pki#tuc_pki_018 mit Prüfmodus Online erfolgen. ARV_706.3_Spec_SST_Störungsam pel_teil2_v1.1.0.doc C_4756 ARV_706.3_Spec_SST_Stör Kapitel und ungsampel_teil2_v1.1.0.doc In der Spezifikation fehlt die Festlegung, dass das zu benutzende Serverzertifikat aus dem Vertrauensraum der TI stammen muss, da Zertifiakate außerhalb des Vertrauensraums nicht geprüft werden können. Die Spezifikation muss entsprechend angepasst werden. Das Zertifikat muss von Los 3 (Komponentenzertifikate) dem Betreiber der Störungsampel bereitgestellt werden. Die Admission-OID für das Serverzertifikat muss von der gematik bereitgestellt werden. In ARV_706.3_Spec_SST_Störungsampel_ Teil2_V1.1.0.doc wird eine neue Anforderung spezifiziert: neue AFO: ARV_706.3_SPEC_SST_STAMPEL_AFO_0100 "Serverzertifikat aus dem Vertrauensraum der TI" Die Störungsampel MUSS ein Serverzertifikat C.ZD.TLS-S aus dem Vertrauensraum der TI mit der Admission-OID "oid_stamp" für die Schnittstelle I_Monitoring_Update verwenden. gemspec_oid: In Tabelle 6: Tab_PKI_406 OID-Festlegung technische Rolle in X.509-Zertifikaten wird eine neue OID für Störungsampel mit folgendem Inhalt angelegt: OID-Referenz: oid_stamp ProfessionItem: Störungsampel ProfessionOID: ARV_706.3_Spec_SST_Störungsam pel_teil2_v1.1.0.doc, gemspec_oid C_4790 gematik_pers_smc-b.xsd, gematik_hba_smc- B_Typen.xsd, gemspec_pers_smc-b.doc Card-G2-A_3109 Feldtypen der SMC- B- Übergabeschnittstell e Die in gemspec_pers_smc-b definierte Beschränkung der InstID auf eine feste Länge von 9 oder 10 Stellen ist nicht praktikabel, da hier sektorspezifische Institutions-Kennnummern verwendet werden, welche keiner solchen Beschränkung unterworfen sind. Um zukünftige Änderungen zu vermeiden, wird für das Feld variable Länge (minimale Länge 0) mit einer Begrenzung auf auf maximal 20 Zeichen definiert. C_4849 gemspec_pki Tab_SMCB_KZBV Das Profil für SMC-B-Zertifikate der KZBV wird präzisiert und die Definition des subject.organizationname angepasst. C_4877 gemspec_pki Tab_SMCB_KZBV Für das Profil SMC-B-Zertifikate der KZBV wird die Pflicht aufgehoben, eine -Adresse (in der subjectaltnames- Erweiterung als rfc822name) in das Zertifikat aufzunehmen. Außerdem sollen überlange Institutionsnamen (größer als 64 Zeichen) in der subjectaltnames-erweiterung aufgenommen werden können. Die durchzuführenden Änderungen in gemspec_pers_smc-b und Schema gematik_hba_smc-b_typen.xsd werden im Anhang "Anlage-C_4790" beschrieben. Text-ALT: Gemäß Freigabedaten der zuständigen KZV Text-NEU: Telematik-ID gemäss Freigabedaten der zuständigen KZV Die Änderung entspricht den Vorgaben für die subjectaltnames-erweiterung in den generischen SMC-B-Zertifikatsprofilen und somit kann auf diese verwiesen werden. Dort werden -Adresse und überlange Institutionsnamen als optionale Inhalte aufgeführt. ALT: SubjectAltNames { }; -Adresse gemäss Freigabedaten der zuständigen KZV; 1; FALSE; NEU: SubjectAltNames { }; siehe Kap 5.3.4; 0-1; FALSE; Produkttypsteckbrief TSP-SSt, gem_pers_smc-b.xsd, gematik_hba_smc-b_typen.xsd, gemspec_pers_smc-b.doc gemspec_pki gemspec_pki gemerrata_r1.4.6.xlsx gematik öffentlich Seite 3 von 4

4 Details ID Dokument Quelle Dokument und/oder Kapitel C_4878 gemspec_pki Tab_SMCB_KZBV Das Profil für SMC-B-Zertifikate der KZBV wird präzisiert und die Definition der registrationnumber angepasst. Beschreibung der Änderung Anpassungen an Afos; TUCs, Tabellen, Korrekturen von Änderung betroffene Dokumente In der Tabellenzeile "Admission" wird im Feld für den Inhalt die Zeile "registrationnumber = " geändert: ALT: registrationnumber = <Online-Kennung gemäss Freigabedaten der zuständigen KZV> NEU: registrationnumber = <Telematik-ID gemäss Freigabedaten der zuständigen KZV> gemspec_pki C_4973 gemrl_betr_ti Die Sicherung des Informationsaustauschs zwischen den ITSM- Teilnehmern erfordert die Ablösung des direkten Mailaustauschs durch die vermittelte Kommunikation über eine zentrale Informatiomnsdrehscheibe (ZID). Nur so lassen sich die Informationen zentral validieren und eine einheiliche Syntax und Sematik der ausgetauschten Daten sicherstellen. C_4975 gemspec_sst_vsdm gemspec_intermediaer_vs DM siehe Anlage Die geforderten Bearbeitungszeiten für die VSDM-Anwendungsfälle gehen davon aus, dass bei Bedarf für eine Verbindung zwischen Konnektor und Intermediär in der überwiegenden Zahl der Fälle eine TLS-Session und für die Verbindungen zwischen Intermediär und Fachdienst eine aufgebaute TLS-Verbindung bereits zur Verfügung steht. Es hat sich im Rahmen der Umsetzung gezeigt, dass die hierfür in den Anforderungen verankerte Funktionalität der "TLS Session Resumption per Session-Ticket" nicht oder nur mit erheblichen Aufwand auf Basis der am Markt verfügbaren Frameworks für den Konnektor und den Intermediär realisierbar ist. Das Ziel läßt sich aber auch über die Nutzung von TLS Session Resumption per Session-ID für die Strecke Konnektor<>Intermediär und per HTTP-Connection-Pooling für die Strecke Intermediär<>Fachdienst vollständig erreichen. Dieser Ansatz wird beispielsweise durch gängige Java-Frameworks unterstützt. Die Korrekturen an [gemrl_betr_ti] zur Aufnahme der zentralen Informationsdrehscheibe (ZID) sind umfassend und verteilen sich über das gesamte Dokument, sodass die Änderungen in einer vollständig überarbeiteten Fassung des Dokuments dargestellt werden (die letzte Version des Dokuments wird im regulär veröffentlichten Dokumentenpaket durch Version ersetzt). Es werden zusätzliche Anforderungen zu den Kommunikationsbeziehungen der Fachanwendung VSDM spezifiziert: No Pipelining, http-keepalive Die Anforderung für TLS Session Resumtion mit Session Ticket entfällt. Für die Verbindung von Fachmodul zum Intermediär ist TLS Session Resumption mit Session ID zu verwenden. Der Intermediär muss eine Anzahl an Verbindungen zu den Fachdiensten permanent verfügbar halten. Es werden zusätzliche sicherheitsrelevante Anforderungen an TLS-Verbindungen an die übergreifende Spezifikation aufgenommen. Bestehende Fachdienste VSDM sind von dieser Änderung nicht betroffen. Die durchzuführenden Änderungen werden im Anhang "Anlage-C_4975" beschrieben. gemrl_betr_ti gemspec_krypt gemspec_sst_vsdm gemspec_intermediaer_vsdm gemprodt_kon gemprodt_intermediaer_vsdm gemprodt_fd_vsdm gemerrata_r1.4.6.xlsx gematik öffentlich Seite 4 von 4

5 Anlage zu C_4790 Änderung des Feldtypen für InstID A) Änderung in gemspec_pers_smc-b: Tabelle 3: Tab_SMC-B_Pers_001 Vorbefüllung für einen SMC-B-Antrag Kennnummer der Institution 9 bis 10 Ziffern, vgl.3.1 Tabelle 9: Tab_SMC-B_Pers_003 SmcbSperrAuftrag von der AttrBS an den TSP ID der Institution InstID O IKType String20Type InstID O IKType String20Type identifizierendes Merkmal für die Institution: Institutskennzeichen, Betriebsstättennummer bzw. Abrechnungsnummer; Identifikationsnummer der Institution (Institutskennzeichen, Betriebsstättennummer, Abrechnungsnummer, PraxisID o.ä.), deren Karte/n zu sperren ist/sind; Ziffern Tabelle 22: Felder von InstitutionType InstID O IKType String20Type identifizierendes Merkmal für die Institution (Institutskennzeichen, Betriebsstättennummer, Abrechnungsnummer, PraxisID o.ä.) Tabelle 11: Feldtypen IKType n9..10 Zur Darstellung einer 9- oder 10stelligen Kennnummer B) Änderung in Schema gematik_hba_smc-b_typen.xsd 1) Typdefinition IKType löschen: <simpletype name="iktype"> </simpletype> alt: <element name="instid" type="gematik:iktype" minoccurs="0"> neu: <element name="instid" type="gematik: String20Type" minoccurs="0"> Anlage-C_4790.doc gematik öffentlich Seite 1 von 1 Stand:

6 Anlage zur Änderung C_4975 Inhaltsverzeichnis S.1-4 Änderungen in gemspec_intermediaer_vsdm S.5 Änderungen in gemspec_sst_vsdm S.6-7 S.8-9 Änderungen in gemspec_krypt Änderungen an Produkttypsteckbriefen Änderungen in gemspec_intermediaer_vsdm 3.3 Konfiguration Konfigurierbare Parameter abhängig von der Umgebung Tabelle 5: Tab_INTM_VSDM_18 Konfigurationsparameter für die Verbindung zu den Fachdiensten [VSDM- A_2350] Parameter Beschreibung Fachdienst SessionResumption-Limit Die max. Dauer, in der der Intermediär eine vorher mit einem Fachdienst ausgehandelte Session mittels Session- Resumption wiederverwendet. Fachdienst Connection Pool Anzahl der Verbindungen, die der Intermediär zu jedem Fachdienst permanent offen halten muss. Anlage-C_4975.doc Seite 1 von 9

7 3.6 Kommunikationsbeziehungen No Pipelining Der Intermediär darf beim Verbindungsaufbau zu einem Fachdienst kein Pipelining verwenden. Die einzelnen Request/Reply-Paare dürfen sich nicht beeinflussen. Eine HTTPconnection wird daher zu einem Zeitpunkt immer nur für ein Request/Reply-Paar verwendet. [VSDM-A_3021] Abbildung 1: Vergleich no-pipelining vs. pipelining Connection pooling durch den Intermediär Der Aufbau einer HTTP-connection vom Intermediär zum Fachdienst ist zeitaufwendig. Um Verzögerungen bei der Abarbeitung eines Aufrufs vom Fachmodul zu minimieren, wird die HTTP-connection nicht für jedes Request/Reply-Paar neu aufgebaut. Der Intermediär hält dauerhaft HTTP-connections zu den Fachdiensten offen. Jede HTTP-connection kann nacheinander für mehrere Request/Reply-Paare genutzt werden. Der Intermediär muss zu jedem Fachdienst (UFS, VSDD und CMS) einen permanenten Pool von jeweils 5 HTTP-connections halten. Dieser Wert muss konfigurierbar sein. Wenn eine der permanenten Verbindungen, z.b. durch einen Fehler, abgebaut wird, dann muss der Intermediär die Verbindung innerhalb einer Zeit von höchstens 1s wieder aufbauen. [VSDM- A_3022] Der Intermediär muss die Verarbeitung der Anfragen von Fachmodulen und die Verwaltung der HTTP-connections im eingeschwungenen Zustand im Rahmen seiner Bearbeitungszeit erledigen. Zwei Request/Reply-Paare, die auf Anwendungsebene zur gleichen Conversation gehören, können über verschiedene HTTP-connections übertragen werden. Anlage-C_4975.doc Seite 2 von 9

8 Sollten die fünf Verbindungen bei Lastspitzen nicht ausreichen, muss der Intermediär zusätzliche Verbindungen etablieren, die dann nach Bedarf wieder geschlossen werden [VSDM-A_3023]. Wenn der Fachdienst beim Aufbau der Verbindungen nicht erreichbar ist, dann soll der Intermediär das Connection pooling für einen Zeitraum aussetzen, bis der Fachdienst wieder erreichbar ist. Wird während dieser Phase vom Fachmodul ein Request an den Fachdienst gestellt, dann muss der Intermediär versuchen, eine Verbindung zum Fachdienst aufzubauen. Werden mehrere Fachdienste an einem Endpunkt (FQDN:Port) betrieben, dann kann der Intermediär einen gemeinsamen Pool mit der aufaddierten Anzahl der permanent je Fachdienst zu haltenden HTTP-connection aufbauen und verwalten. Innerhalb des aggregierten Pools muss technisch nicht nach den Fachdiensten unterschieden werden. FM FM Konnektor (Fachmodul) A HTTP Connection 012 A HTTP Connection 013 Zuordnung der HTTP Verbindungen von FM zu FD HTTP Conn. 1 n Fachdienste VSDM TLS-Terminierung A A Fachdienst UFS A Konnektor (Fachmodul) A FM Konnektor (Fachmodul) HTTP Connection 021 Intermediär VSDM HTTP Conn m B FM B HTTP Connection 010 Fachdienste VSDM TLS-Terminierung B Fachdienst VSDD B Konnektor (Fachmodul) Abbildung 2: Beispiel für den Connection-Pool des Intermediärs B1 Ausgangsanforderungen Tabelle 1: Ausgangsanforderungen mit Nachweis der Erfüllung AFO-ID Beschreibung erfüllt VSDM- A_3021 VSDM- A_3022 VSDM- A_3023 Der Intermediär VSDM DARF NICHT Pipelining gemäß RFC 2616 für HTTP-Requests zum Fachdienst verwenden. Der Intermediär VSDM MUSS zu jedem Fachdienst (UFS, VSDD und CMS) eine konfigurierbare Anzahl permanenten HTTP- Verbindungen vorhalten. Der Default Wert für die permanenten HTTP-Verbindungen beträgt 5. Der Intermediär VSDM MUSS temporär zusätzliche HTTP- Verbindungen zum Fachdienst aufbauen, wenn die Anzahl der permanent aufgebauten Verbindungen nicht für die parallele Verarbeitung von Anfragen der Fachmodule ausreichen. Anlage-C_4975.doc Seite 3 von 9

9 C1 Default Werte der Konfiguration abhängig von der Umgebung Tabelle 23: Empfohlene Default-Konfiguration für die Verbindung zu den Fachmodulen Parameter Fachmodul Keepalive-Timeout Defaultwert 12 Stunden (720 Minuten) 5 Minuten Tabelle 24: Empfohlene Default-Konfiguration für die Verbindung zu den Fachdiensten Parameter Defaultwert Fachdienst Keepalive-Timeout 12 Stunden (720 Minuten) 5 Minuten Fachdienst SessionResumption-Limit 12 Stunden (720 Minuten) Fachdienst Connection Pool 5 Anlage-C_4975.doc Seite 4 von 9

10 Änderungen in gemspec_sst_vsdm 2.2 Transportsicherung Da der Verbindungsaufbau in der Regel ein zeitaufwändiger Vorgang ist, sollen die Verbindungen für einen konfigurierbaren Zeitraum offen gehalten werden. Wenn dennoch Verbindungen erneut aufgebaut werden müssen, soll das Session-Resumption-Verfahren gemäß [RFC5077] verwendet werden, um eine Session ohne Neuaushandlung der Parameter fortführen zu können. [VSDM-A_2225] [VSDM-A_2226] B2 Ausgangsanforderungen Tabelle 2: Tab_SST_VSDM_14 Ausgangsanforderungen mit Nachweis der Erfüllung AFO-ID Beschreibung erfüllt VSDM- A_2225 Die Fachanwendung VSDM MUSS Session Resumption gemäß RFC 5077 nutzen, um eine Session ohne Neuaushandlung der Parameter fortführen zu können. CR-A_11 VSDM-A_2163 VSDM- A_2226 Das Fachmodul VSDM und der Intermediär VSDM MÜSSEN für die Verbindung zwischen Fachmodul und Intermediär TLS Session Resumption mittels Session-ID gemäß RFC 5246 nutzen, um für den wiederholten Aufbau von TLS-Verbindungen die bereits ausgehandelten Session-Parameter zu nutzen. Die Fachanwendung VSDM SOLL TLS-Verbindungen mit konfigurierbarer Session-Resumption nutzen und für Nachrichten wiederverwenden. CR-A_11 VSDM-A_2162 VSDM-A_2163 Die Fachanwendung VSDM SOLL das Keepalive-Feature Persistent Connections aus http 1.1 gemäß RFC 2068 unterstützen, damit die Verbindungen in Folgeanfragen wiederverwendet werden können. Wenn es genutzt wird, MUSS die Fachanwendung VSDM die Lebensdauer der Verbindungen durch einen konfigurierbaren Timeout begrenzen. Anlage-C_4975.doc Seite 5 von 9

11 Änderungen in gemspec_krypt TLS-Verbindungen Sicherheitsziel bei der Verwendung von TLS in der TI ist die Forward Secrecy [BSI-TR , S. ix], was sich u. a. in den vorgegebenen CipherSuites (vgl. Tab_KRYPT_015 und Tab_KRYPT_016) widerspiegelt. Um dieses Ziel zu erreichen muss sichergestellt werden, dass in regelmäßigen Abständen frisches Schlüsselmaterial über einen authentisierten Diffie-Hellman-Schlüsselaustausch gebildet wird, welches das alte Material ersetzt wobei das alte Material sowohl im Klienten als auch im Server sicher gelöscht wird. Insbesondere bei der Nutzung von TLS-Resumption (vgl. [RFC-5246, S. 36] oder [RFC-5077]) kann die Dauer einer TLS-Session deutlich länger sein als die Lebensdauer der TCP-Verbindung innerhalb welcher der initiale Schlüsselaustausch stattgefunden hat. Aus diesem Grunde werden analog zu den IPsec-Vorgaben (vgl. gemspec_krypt#gs-a_4383) Vorgaben für die maximale Gültigkeitsdauer dieses Schlüsselmaterials gemacht. GS-A_5322 Weitere Vorgaben für TLS-Verbindungen Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN u. a. folgende Vorgaben erfüllen: Falls der Produkttyp als Klient oder als Server im Rahmen von TLS an einer Session-Resumption mittels SessionID (vgl. [RFC-5246, Abschnitt ]) teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird. Falls der Produkttyp als Klient im Rahmen von TLS an einer Session-Resumption nach [RFC-5077] teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird. Damit verbundene SessionTickets MUSS er ebenfalls sicher löschen. Falls der Produkttyp als Server im Rahmen von TLS an einer Session- Resumption nach [RFC-5077] teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird. Damit verbundene SessionTickets MUSS er, falls bei ihm vorhanden, sicher löschen. Das Schlüsselmaterial, dass bei der Erzeugung des SessionTickets (für die Sicherung von Vertraulichkeit und Authentizität der SessionTickets) verwendet wird MUSS spätestens alle 48 Stunden gewechselt werden und das alte Material MUSS sicher gelöscht werden. Als kryptographische Verfahren zur Erzeugung/Sicherung der SessionTickets MÜSSEN ausschließlich nach [BSI-TR ] zulässige Verfahren verwendet werden und das Schlüsselmaterial muss die Entropieanforderungen gemäß gemspec_krypt#gs-a_4368 erfüllen. Anlage-C_4975.doc Seite 6 von 9

12 Falls ein Produkttyp als Klient oder Server im Rahmen von TLS die Renegotiation unterstützt, so MUSS er dies ausschließlich nach [RFC-5746] tun. Ansonsten MUSS er die Renegotiation-Anfrage des Kommunikationspartners ablehnen. Aktuell gibt es in der TI keine Anwendungsfälle für eine Session-Renegotiation im Rahmen von TLS. Hinweis: Hintergrundinformationen sind in diesem Zusammenhang in [CM-2014] zu finden. A5.2 Weitere Dokumente [CM-2014] [RFC-5077] [RFC-5246] [RFC-5746] 20 Years of SSL/TLS Research, An Analysis of the Internet s Security Foundation, Christopher Meyer, 9. February Transport Layer Security (TLS) Session Resumption without Server- Side State, January 2008, The Transport Layer Security (TLS) Protocol Version 1.2, August 2008, Transport Layer Security (TLS) Renegotiation Indication Extension, February 2010, Anlage-C_4975.doc Seite 7 von 9

13 Änderungen in Produkttypsteckbrief Intermediär VSDM [gemprodt_intermediär_vsdm_ptv1.2.0] Tabelle 2: Anforderungen zur funktionalen Eignung "Produkttest / Produktübergreifender Test" Afo-ID Afo-Bezeichnung Quelle (Referenz) VSDM-A_3022 Intermediär VSDM: Connection Pooling zu Fachdiensten gemspec_intermediaer_ VSDM VSDM-A_3023 Intermediär VSDM: Zusätzliche Verbindungen zu Fachdiensten gemspec_intermediaer_ VSDM VSDM-A_2225 Fachanwendung VSDM: Session Resumption nutzen Fachmodul VSDM, Intermediär VSDM: TLS Session Resumption mittels Session-ID nutzen gemspec_sst_vsdm Tabelle 3: Anforderungen zur funktionalen Eignung "Herstellererklärung" Afo-ID Afo-Bezeichnung Quelle (Referenz) VSDM-A_3021 Intermediär VSDM: Kein Pipelining gemspec_intermediaer_ VSDM Tabelle 4: Anforderungen zur sicherheitstechnischen Eignung "Sicherheitsgutachten" Afo-ID Afo-Bezeichnung Quelle (Referenz) GS-A_5322 Weitere Vorgaben für TLS-Verbindungen gemspec_krypt Anlage-C_4975.doc Seite 8 von 9

14 Änderungen in Produkttypsteckbriefen Konnektor (Ausbaustufe VSDM) [gemprodt_kon_ptv1.3.0] und vollständiger Ausbau einschließlich QES [gemprodt_kon_ptv2.3.0] Tabelle 3: Anforderungen zur funktionalen Eignung "Produkttest / Produktübergreifender Test" Afo-ID Afo-Bezeichnung Quelle (Referenz) VSDM-A_2225 Fachanwendung VSDM: Session Resumption nutzen Fachmodul VSDM, Intermediär VSDM: TLS Session Resumption mittels Session-ID nutzen gemspec_sst_vsdm Tabelle 5: Anforderungen zur sicherheitstechnischen Eignung "CC-Evaluierung" Afo-ID Afo-Bezeichnung Quelle (Referenz) GS-A_5322 Weitere Vorgaben für TLS-Verbindungen gemspec_krypt Änderungen in Produkttypsteckbrief Fachdienste VSDM [gemprodt_fd_vsdm_ptv1.2.1] Tabelle 2: Anforderungen zur funktionalen Eignung "Produkttest / Produktübergreifender Test" für alle Fachdienste Afo-ID Afo-Bezeichnung Quelle (Referenz) VSDM-A_2225 Fachanwendung VSDM: Session Resumption nutzen gemspec_sst_vsdm Anlage-C_4975.doc Seite 9 von 9