Die Gültigkeit eines Zertifikates ist lediglich eine ASN.1 kodierte Zertifikatseigentschaft, die aus kryptographischer Sicht völlig unerheblich ist. Und selbst wenn die genutzte Software dieses Kriterium prüft, so muss zur Umgehung lediglich das Systemdatum angepasst werden.
Dass bei so einer fancy-Aufgabenstellung natürlich irgend jemand sofort reflexartig mit Blockchain antwortet war vorherzusehen 
Ich würde es dennoch mit etwas klassischem versuchen.
Eine fertige Lösung habe ich ad-hoc auch nicht, aber versuchen wir mal ein paar Puzzlesteine zu definieren, aus denen man etwas "bauen" kann.
1. asymmetrische Kryptographie
- Vertraulichkeit: Der zukünftige Empfänger der Nachricht soll sich ein Schlüsselpaar generieren und Dir den Public-Key zukommen lassen. Du verschlüsselst das Geheimnis mit seinem Public-Key und vernichtest den Klartext. Du hast nun ein Chiffrat, das du selbst nicht mehr entschlüsseln kannst, und die einzige Person die das (irgendwann einmal) kann ist der Inhaber des Private-Keys.
-
Integrität: Damit der Empfänger sich sicher sein kann, dass die Nachricht die er irgendwann einmal erhalten wird wirklich von dir stammt, willst Du diese signieren. Du erstellst Dir also auch selbst ein Schlüsselpaar und lässt dem zukünftigen Empfänger Deinen Public-Key zukommen. Mit dem Private-Key signierst du das Chiffrat. Ob Du Klartext oder Chiffrat signierst ist Geschmacksache, es gibt Vor- und Nachteile beider Varianten. Das Chiffrat zu signieren ermöglicht auch ohne den Private-Key des Empfängers zu besitzen eine Integritätsprüfung.
-
Tools hierfür z.B. "openssl smime" oder gpg
2. ein Server mit Versand-Script und Totmann-Schaltung
Du hinterlegst das signierte Chiffrat auf einem Server. Der Server prüft per Cronjob z.B. täglich, ob Du dich gemeldet hast. Wenn Du dich mehr als 6 Tage lang bei ihm nicht gemeldet hast, dann versendet er das Chiffrat an $DefinierterEmpfänger.
Schutzbedarf des Servers:
-
Vertraulichkeit: Das Chiffrat betrachten wir als sicher, entschlüsselt kann es nur vom Inhaber des PrivateKeys werden. Der einzige Hacker der also etwas damit anfangen könnte diesen Server zu knacken um an das Chiffrat zu kommen, ist der PrivateKey-Inhaber selbst. Du musst also den Server so absichern, dass er ein ausreichendes Schutzniveau gegenüber dem PrivateKey-Inhaber bietet, schließlich soll dieser nicht zu früh an seine Nachricht gelangen können.
-
Integrität und Verfügbarkeit: Dritte denen etwas daran liegt zu verhindern, dass (wenn Dir etwas zustößt) die Nachricht an den Empfänger versandt wird, könnten deinen Server dahingehend kompromittieren wollen, dass er eine gefälschte Nachricht an den Empfänger sendet oder der Versand überhaupt ausbleibt.
-
Verfügbarkeit: nicht nur einen sondern mehrere Server verwenden, diese nach außen hin möglichst unsichtbar machen und Angriffsfläche reduzieren. Klassische System-Härtung und Redundanz.
-
Integrität: Damit nicht jemand eine gefälschte Nachricht versenden kann haben wir mit dem Empfänger vereinbart, dass dieser die Signatur prüfen wird und den Public-Key hierfür von Dir persönlich erhalten hat. Solange also nicht jemand mittels SocialEngineering den Empfänger überredet eine gefälschte Nachricht als Deine anzuerkennen sollte die Integrität gewahrt sein.
Aus meiner Sicht wars das auch. Klingt nicht nach "Zukunftsverschlüsselung", sondern ist klassische Ende-zu-Ende Mail-Security, bei der die Mail aber am "Totmann-Schaltungs-Server" für x Wochen/Monate/Jahre zurückgehalten wird.
