Welchen Zweck verfolgen die X-KIM-XXXData-Header? Warum verkompliziert man den Prozess der KIM-Nachrichten in dieser Art und Weise?

Nur für Monitoring? Ist das verhältnismäßig? Warum sucht man diese Informationen im Monitoring nicht einfach aus dem VZD anhand FROM, TO und CC Headern? Warum verlagert man den Prozess in das Clientmodul und erhöht dort die Komplexität?

Aus persönlicher Sicht gehört das ins Monitoring-Tool, wo man genau 1 System anpassen muss und nicht 7+ Clientmodule auf zig-hundertausenden Installationen.

Scope:
AccountManager.yaml
gemSpec_CM_KOM-LE:

• 3.7 Administrationsmodul
• 4.1.1 Allgemeine Festlegungen

Optional sollte das Passwort erst sein, wenn dies durch alle Fachdienste unterstützt wird.

(!) Grundsätzlich bietet diese Änderung keinen Mehrwert und kann zu IOP-Problemen führen, da die Account Manager Stand heute ein Passwort bei createCert erwarten.

Die Angabe eines Passworts für den PKCS#12 keystore führt bisher zu keinem Problem und sorgt, zusätzlich dafür, dass der keystore passwort-geschützt übertragen wird, auch wenn der sicherheits-technische Mehrwert dessen gering ist.
So muss ggf. in Clientmodulen, welche diesen geeignet verschlüsselten keystore in der Form weiterverwenden möchten, nach dem Abruf nicht erneut ein entsprechend passwort-geschützter keystore erzeugt werden, sodass der abgerufene keystore unverändert weiterverwendet werden könnte.

Es besteht keine Notwendigkeit dieser Änderung, da die Angabe eines Passwortes aktuell kein Hindernis ist. Dies ist in Relation zu ggf. entstehenden IOP-Problemen zu betrachten.
(Beachte: damalige Diskussion drehte sicher vielmehr um die encryption des keystores selbst nicht um das Passwort.)

Relevante Afo. FD-Spec:
A_18784-04 - Bereitstellung Schlüssel und Zertifikat für Clientmodul als passwortgeschützte PKCS#12 Datei

Was passiert wenn sich die Version ändert?
Dann passt die Afo ja nicht mehr.
Sollte hier ggf. auf die Angabe der Version verzichtet werden und immer auf die aktuelle verfügbare Version hingewiesen werden.

Kann der Satz "Zur Pflege der Basisdaten des Verzeichnisdienstes und..." kann m.E. endlich raus, da wir keine Basisdaten mehr pflegen.

Das kimData Attribut enthält redundant zum komLeData die KIM-Version. Redundanz erzeugt Fehler, weil beide Attribute immer synchron angepasst werden müssen. Warum wird die Version noch einmal in kimData gespiegelt?

Das Attribut ist als optional gekennzeichnet, viele AFO referenzieren aber jetzt statt komLeData kimData. Das kann so nicht funktionieren, da kimData für “alte” Datensätze nicht existiert, bzw. durch die Optionalität nicht existieren muss.

Ist es in der Afo nun wirklich so gemeint, dass in den Header X-KIM-DecryptionResult anstatt die ID 00 der Text "Die KOM-LE Nachricht wurde erfolgreich entschlüsselt" eingetragen werden soll?

Den Hintergrund verstehe ich nicht und möchte dazu sagen, dass derzeit die Entwicklungen der Primärsysteme dahingehend laufen, dass die IDs ausgewertet werden.
Eine Mischung aus "mal Text" und "mal ID" finde ich fragwürdig.

Gemäß dieser Afo muss das Clientmodul die Liste der für den Nutzer wählbaren appTags vom Account Manager abrufen , um diese dem Nutzer zu Auswahl anbieten zu können. Aktuell findet sich unter https://github.com/gematik/api-kim/tree/develop/src/openapi keine unabhängige interface Funktion zum account-unabhängigen Abruf der Liste.

übersehe ich etwas?

Beachte:
Die „globale“ Liste der appTags ist unabhängig vom KIM-Account und sollte zwingend nicht Teil spezifischer Account-Informationen sein.
Es ist aufgrund der häufig nicht gegebenen Online-Anbindung der Betriebsumgebungen des KIM-Clientmoduls auszuschließen, diese aus dem öffentlichen Internet abzurufen!

In diesem Kontext weiterführend relevant:
#37

Es existiert keine formale Beschreibung von AppTags. Wie muss das “Format” aussehen? Die Beispiele sind widersprüchlich.

kimData: [email protected],1.0,DALE-UV;Einsendung;V1.0|eEB;V1.0

Gemäß Beschreibung wäre also DALE-UV;Einsendung;V1.0 ein einzelnes AppTag. Wie soll das geparst werden? Dort wäre die Version an 3. Stelle getrennt mit Semikolon, bei eEB;V1.0 ist die Version an 2. Stelle. Hier sollte eine einheitliche formale Definition der AppTags erfolgen, da sonst jeder AppTag selbst unterschiedlich geparst werden muss, was ein schlechter Weg wäre.

Ohne formale Definition kann auch keine Validierung geschehen und bei den REST Aufrufen ungültige bzw. destruktive AppTags gesendet werden (z.B. Komma innerhalb des Tags).

403 und 404 sind per Definition transiente Fehler (4xx).
Als persistente Fehler gelten reponse codes 5xx.
Auch können diese Zustände je nach Umsetzung und technischer Abbildungen verschieden in den Clientmodulen auftreten.

Hier ist aus Kompatibilitätsgründen die Anwendungsdomäne KIM zu berücksichtigen, sodass der Verweis auf bestimmte Fehlercodes „(403 und 404)“ entfallen kann und die Behandlung zw. transient und persistenten Fehlerfall abstrakter beschrieben werden kann, im Ermessen des Herstellers liegen sollte.

Es reicht, der Hinweis auf die Unterscheidung zw. transienten und persistenten Fehlerfällen, um zu verhindern, dass die KOM-LE-S/MIME-Nachricht, im Fall eines persistenten Fehlers, in die Fehlernachricht eingebettet wird und ein Nutzer im Fehlerfall vergeblich versucht eine Mail erneut an sich selbst weiterzuleiten, um den Abrufvorgang und die Verarbeitung zu wiederholen.
=> Im persistenten Fehlerfall würde dies entsprechend erneut zum selben Fehlerbild führen (deadlock).

• Warum wird zum Löschen einer Ressource ein POST genutzt und kein DELETE, so wie es nach REST Konvention korrekt wäre?
• Warum verwendet man nicht die gleiche Wordingstruktur?

delete_Attachment anstatt deleteMaildata.

Wie ist es geregelt wenn der AccountManager des KIM-Fachdienstes schon eine neuere Liste hat und der VZD aufgrund der geforderten "stündlichen" prüfung gemäß A_23728 noch keine neuere Liste hat.
Das Resultat wäre, dass der VZD aufgrund einer veralteten Liste die Operation nicht durchführt.

Das darf nicht passieren.
Der VZD müsste also auch immer prüfen ob es eine neuere Liste gibt sobald Fachdaten gteändert werden sollen durch den AccountManager.

Das gleiche gilt auch für A_23730 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung REST

Nachrichten die nach einer Deregistrierung nicht abgeholt werden, sollen nach 30 Tagen gelöscht werden.
Jedoch werden hier die automatisch generierten Mail (DSN) nicht betrachtet.
Hier wäre eine Anpassung notwendig zur Klarstellung:

Löschfrist von Nachrichten und automatisch generierten Mails nach der endgültigen Deregistrierung

Für was wird der zusätzliche Header X-KIM-Message-ID eingeführt? Die Message-Id einer Nachricht ist doch vorhanden und wird dadurch nur redundant eingefügt?

"Handelt es sich bei der Mail-Adresse um einen HBA-Account, dann erfolgt die Aktualisierung der KIM-Version nachdem ein POP3 Nachrichtenabruf erfolgt ist"

=> Die Festlegung zur Aktualisierung nach dem POP3-Abruf spielt keine Rolle. Die Aktualisierung ist auch währenddessen, parallelisiert möglich. Einzige Voraussetzung zur Aktualisierung ist das Vorhandensein der KIM-Mail-Account-Credentials, welche bereits zu Beginn der POP3-Protokollschritte übertragen werden.

=> Anforderung kann umbenannt werden = "beim Senden" kann raus

=> Die Aktualisierung der KOM-LE-Version kann nach diesem Vorgehen auf dem Versand- und Empfangspfad erfolgen. Es reicht der Hinweis, dass für Aktualisierung der KOM-LE-Version bzgl. eines mit einem HBA verknüpften KIM-Accounts, die userID benötigt wird, welche nur im POP3-Benutzernamen und damit beim Nachrichtenabruf vorhanden ist.

• komLeData darf auf lange Sicht nicht entfallen! - siehe #30
• i.d.R. werden Clientmodule nicht nach komLeData „suchen/filtern“, da die angenommene Festlegung gilt, dass zu jedem mail-Attribut auch ein komLeData-Attribut existiert, sodass absolut nach „mail“ gesucht werden kann und aus der Rückgabemenge der Daten „komLeData“ ausgewertet wird.

Neue VZD-Spec beschreibt entsprechend:
A_23819 - VZD, I_Directory_Application_Maintenance, Behandlung komLeData & kimData REST

In diesen Zusammenhang relevant:
A_19356-07 - Prüfen der Version des Empfängers #30

Verstehe ich es richtig, dass bei der Prüfung der Header-Elemente (inhalt nicht kennzeichner) from, sender, reply-to, to und cc alle Elemente geprüft werden sollen?
Also DisplayName und spec-addr? Oder soll nur die spec-addr gemäß RfC5322 geprüft / verglichen werden?

Gemäß images/diagrams/architecture/KIM 2.0 Architektur.png soll es über ein Internet-GW von einem Geräte des LE möglich sein, KIM ohne Zugriff auf einen Konnektor zu nutzen. Wie soll hier die Ver-/Entschlüsselung und Signatur-Erzeugung/-Prüfung funktionieren?

A_23554 - Weiterleitung MAIL FROM - SIZE-Parameter Das Clientmodul MUSS, wenn es vom Clientsystem ein MAIL FROM Kommando erhält, prüfen, ob durch das Clientsystem der Parameter size befüllt wurde. Ist dies der Fall, MUSS das Clientmodul erst nach Verarbeitung der Nachricht durch das Clientmodul und der Anpassung des Parameters size in MAIL FROM das Kommando an den Fachdienst weiterleiten.[<=]

Sollte noch ein wenig genauer definiert werden, damit es 100% keine Fehlinterpretationen geben kann.
Anpassen des "size" Parameter auf welchen Wert?

In den Hinweisen zur Afo steht: "Hinweis: KIM-Teilnehmer können zu ihrer KIM Mail-Adresse ein oder mehrere Anwendungskennzeichen festlegen." Das klingt danach, dass mind. 1 Anwendungskennzeichen angegeben werden muss.
Im Datenmodell sind die appTags optional.

Muss es künftig zu einem Account mindestens 1 Anwendungskennzeichen geben?

Wenn hier von $size gesprochen wird, welche Größe soll denn da rein wenn z.B. eine KAS Mail versendet worden ist.
ist $size dann die gesamte Größe inkl. KAS size oder nur die size, die im MAIL FROM nach der Verarbeitung gemäß Spec herauskommt?

Die Afo KOM-LE-A_2187-05 spezifiziert, dass ein Aufruf von setAccount nur möglich ist, wenn die KIM E-Mail Adresse auch im VZD vorhanden ist.  Die Operation setAccount kann aber auch benutzt werden, um Werte außerhalb des VZD zu setzen: password und dataTimeToLive. In einem solchen Fall ist die Einschränkung, dass die KIM E-Mail Adresse auch im VZD vorhanden sein, nicht sinnvoll.

Vorschlag zur Änderung:
Der zweite Punkt unterhalb von "Für die Operationen gilt:" wird durch die folgenden beiden Punkte ersetzt:

• bei Aufruf der Operation setAccount: Wenn über setAccount Daten im VZD geändert werden sollen (z.B. kimVersion), dann muss der - in der Operation angegebene - Parameter username (E-Mail Adresse) in dem VZD-Datensatz mit der Telematik-ID des AUT-Zertifikats aus dem Token im mail Attribut der Fachdaten vorhanden sein.
• bei Aufruf der Operation deregisterAccount: Der - in der Operation angegebene - Parameter username (E-Mail Adresse) muss in dem VZD-Datensatz mit der Telematik-ID des AUT-Zertifikats aus dem Token im mail Attribut der Fachdaten vorhanden sein.

Michael Bouschen

Die AFO sollte ausführlicher beschreiben, was genau gemeint ist. Welchen Parameter "size" gibt es bei einem SMTP "MAIL FROM" Command? In der RFC zu SMTP kann ich nichts über einen size-Parameter finden.

“Ist das LDAP-Directory Attribut komLeData für den Empfänger undefiniert, dann muss ein 136 KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden” - wurde ersatzlos gestrichen. Was passiert wenn weder komLeData noch kimData vorhanden ist?

A_23737 - Clientmodul - Übermittlung von zusätzlichen Header-Informationen
Das Clientmodul MUSS beim Versand einer Nachricht die folgenden X-KIM Header erzeugen.

X-KIM-ToData
Enthält Daten aus dem VZD-Eintrag des Empfängers (MAIL TO).
Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt.
Format: {,,,}

X-KIM-CcData
Enthält die Daten aus dem VZD-Eintrag des Empfängers (MAIL CC).
Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt.
Format: {,,,}

Frage:
Wie soll vorgegangen werden, wenn es in einer KIM-Nachricht mehrere CC oder TO gibt.
Sollen dann n Header der gleichen Keynames vorhanden sein?
Es wird ja nur beschrieben dass prtofessionOID und specialization durch | getrennt werden müssen.

A_23541 - Servicelokalisierung durch das Clientmodul
Das Clientmodul MUSS den FQDN des Fachdienstes sowie den zu nutzenden Port per DNS Service Discovery bestimmen, wenn diese nicht durch das Clientsystem im jeweiligen Benutzernamen bereitgestellt wurden.[<=]

In der Beschreibung steht, dass das CM den FQDN und den Port des Fachdiensten per DNS SD ermitteln muss wenn der Teilstring fehlt.
Soweit OK.

Jedoch müssen diese Afo nochmal geprüft werden durch gematik, da diese nachfolgende Afo besagt, dass der Vorgang abgebrochen werden muss wenn der Benutzername nicht passt im Aufbau:
Bevor ich feststellen kann das was fehlt, muss ja zuerst die Prüfung der Benutzernamen stattfinden und das CM käme nie bis zur A_23541.

A_21519-02 - Überprüfung des SMTP-Benutzernames
Das Clientmodul MUSS die übergebene SMTP-Benutzername-Zeichenkette auf Vollständigkeit überprüfen. Werden optionale Bestandteile des SMTP-Benutzernamens nicht genutzt, MUSS sichergestellt werden, dass später folgende optionale Bestandteile in ihrer vorgegebenen Position platziert werden. Als Platzhalter ist in so einem Fall "*" zu verwenden. Wenn die SMTP-Benutzername-Zeichenkette nicht vollständig ist, MUSS das Clientmodul den SMTP Fehlercode gemäß Tabelle "Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau" an das Clientsystem senden und den Vorgang abbrechen.

A_21518-02 - Überprüfung des POP3-Benutzernames
Das Clientmodul MUSS die übergebene POP3-Benutzername-Zeichenkette auf Vollständigkeit überprüfen. Werden optionale Bestandteile des POP3-Benutzernamens nicht genutzt, MUSS sichergestellt werden das später folgende optionale Bestandteile in ihrer vorgegebenen Position platziert werden. Als Platzhalter ist in so einem Fall "*" zu verwenden. Wenn die POP3-Benutzername-Zeichenkette nicht vollständig ist, MUSS das Clientmodul den POP3 Fehlercode gemäß Tabelle "Tab_POP3_Verbindung Antwortcodes für POP3-Server-Verbindungsaufbau" an das Clientsystem senden und den Vorgang abbrechen. [<=]

Es sollte eine einheitliche Regelung geschaffen werden, wie eine unbegrenzte Quota definiert ist.

In fast allen adoc Dokumentationen funktionieren die Links aus dem "Inhaltsverzeichnis" auf die Kapitel nicht.

In z.B. : https://github.com/gematik/api-kim/blob/main/docs/KIM_API.adoc wird auf den Anker #registeraccount verlinkt, der Anker selbst hat aber die ID #211-registeraccount. Bei dem Anker wird scheinbar automatisch die Kapitelnummer mit rein genommen.

Die SMTP-Protokollschritte zur Übermittlung der Empfängerinformationen ("RCPT TO") entscheiden über die Zustellung einer Mail (nicht die MIME-Header), deren Daten im nachfolgenden SMTP-Protokollschritt "DATA" übermittelt werden.

Analogie Briefversand (E-Mail Reinform):
Postbote/Posttransport = KIM/Transportschicht
Postleitungsinformationen - Adressdaten auf Briefumschlag = entsprechende SMTP-Protokollschritte
Brief im Briefumschlag = MIME-Message/eigentliche Mail

(Was auf dem Brief im Briefumschlag steht, sieht Postransport nicht bzw. spielt keine Rolle für den Transport)

Gemäß A_19356-XX darf eine Nachricht, in Abhängigkeit zu deren "Größe"/Datenmenge nur an Empfänger geeigneter KOM-LE-Version versendet werden.

Ein RFC-konformer Mailclient wird die Informationen gemäß der MIME-Header To, Cc, Bcc, ... im per SMTP RCPT TO an das Clientmodul übermitteln. Leitet das Clientmodul diese vor der Abhandlung von bspw. A_19356-XX einfach weiter, wird die Mail trotzdem an jene Empfänger zugestellt, auch wenn diese nicht die für die Nachrichtenverarbeitung geeignete KOM-LE-Version im VZD ausweisen.

Analog MAIL FROM, siehe #32 & #40, darf RCPT TO darf erst nach Erhalt und ggf. Verarbeitung der Maildaten und damit nach SMTP "DATA" an den Zielmailserver weitergeleitet werden, da erst mit vorliegen der vollständigen Mail im Clientmodul, entsprechende Prüfungen (u.a. A_19356-XX) durchgeführt werden können.

=> [gemSpec_CM_KOMLE] - 3.3.3 PROXY-Zustand vs. 3.3.4 PROCESS-Zustand

PS: nerver trust the client -> MAIL FROM SIZE ist kein geeigneter Anhaltspunkt, da dieser Wert vom Mail-Client gesetzt und nicht durch das Clientmodul technisch absolut bestimmt wird.

Es fehlt ggf. notwendige Spezifikation bzgl. des neuen AccountLimits-Parameter „kasMailSizeThreshold“.

Siehe ursprüngliche PR: #22

=> Entsprechend muss der Umgang mit diesem Parameter definiert:

• Was impliziert der Parameter?
• Wie ist der Parameter zu verwenden?
• Was passiert, wenn nicht oder invalid gesetzt?
  ...

Mit der sich noch im Aufbau befindlichen hersteller-unabhängigen Komponenten-Interoperabilität zwischen CM und und FD sind umfassende Spezifikationserweiterungen/-konkretisierungen notwendig.

So wird in KIM 1.5.3 u.a. vorgesehen, dass ServiceInformation durch ein CM vom Account Manager abrufbar werden.

Beschreibung des Problembilds am Beispiel der passwordPolicy:

Aufgrund der historischen Entwicklung und damit verbundenen legacy-Betrachtung der bereits bestehenden KIM-Abbildungen, ist es u.a. notwendig, dass über die ServiceInformationen die konkreten Passwort-Richtlinien des jeweiligen KIM-FD Account Managers bereitgestellt werden, sodass ein herstellerfremdes CM diese entsprechend beachten bzw. dem Nutzer anzeigen kann.

Im Kontext dieser Richtlinien und weiterer Abhängigkeiten werden entsprechend Passwörter (auch iniPassword & OTP) bspw. gemäß AccountManager.yaml in HTTP Header-Elementen übertragen:

https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L89
https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L202
https://github.com/gematik/api-kim/blob/develop/src/openapi/AccountManager.yaml#L571
...

Problem:
Ein charset dieser Werte ist nicht näher, verbindlich spezifiziert, sodass beliebige Zeichen gesetzt werden könnten - bspw. ungefilterter user-input bei Passwort.

Verweis auf RFC´s

Gemäß RFC7230 3.2 und ff. können und sollten nur ASCII chars in HTTP header values verwendet werden [USASCII].
Anderfalls müsste auf MIME-Encoding zurückgegriffen werden, was i.d.R. nicht standardmäßig, verbreitet, weder in HTTP client- noch serverseitig unterstützt wird.

Potenzielle Auswirkungen:
Werden bpsw. in den Passwörter non-ASCII chars, wie Umlaute verwendet, können client- und oder servseitige Fehlerzustände auftreten.

Hinweis:
Dies ist u.a. ein Grund warum HTTP Basic authentication stets base64 kodiert übertragen wird.

Vorschläge möglicher Anpassungen

1. Festlegung des globalen charsets für jene header-values entsprechend RFC7230.
   Vorteil: Keine Anpassung bestehender Interface-Spezifikation
   Nachteil: technisch implizite Parallel-Spezifikation notwendig

2. Base64-Kodierung sämtlicher, proprietärer, jedoch nicht näher spezifizierter HTTP header values analog (vgl. RFC7617)
   Vorteil: es treten zukünftig keine Probleme in diesem Kontext auf - technisch sauberste Lösung
   Nachteil: Änderung grundlegender Bestandteile der Interface-Spezifikation -> potenzielle IOP-Probleme -> ggf. Versionierung notwendig
   Hinweis: Da aktuell in KIM 1.5 keine produktive, hersteller-übergreifende Nutzung CM <-> Fachdienst existiert, ist diese Änderung ggf. noch moderiert möglich.

Ergänzender Hinweis HTTP Basic-Auth

Es muss beim Parsen der credentials (username:passwort) beachtet werden, dass bspw. auch ":" Teil des Passwortes sein kann. 👌

A_19362 und A_19368 werden in A_19362-01 und A_19368-01 von einer generischen Form zu einer spezifischen Form für Upload und Download umgeschrieben. Warum hat man hier nicht einfach nur A_19368 gestrichen, da “eine Verbindung” sowohl für Upload als auch für Download nötig ist, würde die ursprüngliche Form beide Fälle abdecken und die Spezifikation vereinfachen.