Key-Roll-Over

User Story

Als Entwickler des Java SDKs möchte ich einen Key-Roll-Over implementieren

Warum

  • In der Doku heißt es: "Sofern ein falscher oder veralteter Schlüssel verwendet wurde, der Metadatensatz aber dennoch entschlüsselt werden konnte, sollte Verarbeitung fortgesetzt werden, aber eine entsprechende Meldung erfolgen." Wie ist für sendende Systeme erkennbar, dass eine Entschlüsselung erfolgreich/nicht erfolgreich war.
  • Falsche Schlüssel sollten nie akzeptiert werden.
  • "Veraltete Schlüssel" muss definiert werden: Nur im Rahmen eines Key Rollover übergangsweise erlaubt.
  • Vorschlag: Diesen Satz aus der Dokumentation streichen und o.g. Hinweise ergäzen.

Bei den falschen Schlüssel gebe ich dir recht. Der gehört raus. Mit veralteter Schlüssel meinte ich einen früher gültigen Schlüssel. Bei Key-Rollover ist zu bedenken, dass der aufgrund folgenden Szenarios etwas länger werden:

  • Der Antragsteller startet einen Antrag
  • Der Antragsteller lädt das erste Attachment hoch
  • Der Online-Dienst lädt den Verschlüsselungsschlüssel und verschlüsselt damit das Attachment
  • Der Antragsteller füllt den Antrag weiter aus
  • Der Verschlüsselungsschlüssel wird getauscht
  • Der Antragsteller sendet den Antrag ab

Damit kommen wir von Sekunden in den Bereich von Stunden. Wenn der Antrag zwischengespeichert wird, werden daraus Tage.

Die Alternative wäre eine Verschlüsselung mit einem Schlüssel des Antragstellers. Das führt aber zu einer Umverschlüsselung beim Absenden.

Entscheidung: Da das aktuelle SDK nur einen privaten Schlüssel unterstützt, wird bei Verwendung eines alten/falschen Schlüssels immer ein reject-submission-Event erstellt. Deshalb implementieren wir einen Keyrollover

Links, Hinweise, Bemerkungen

Ursprüngliche Entscheidung siehe #594 (comment 38085)

Akzeptanzkriterien

  1. ...
  2. ...
  3. ...

Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)

Edited by Carsten Fröhlich