Automatisches Verifikationsverfahren

Bei der Zertifikatverwaltung können Konflikte zwischen Zertifikaten entstehen, d.h. das System kann aufgrund der Vorlage nicht entscheiden, ob das neue Zertifikat verwendet werden darf oder nicht. Im Konfliktfall hat das vorhandene Zertifikat Vorrang, das neue zweifelhafte Zertifikat wird in eine eigene Tabelle eingetragen:

create table `invalid_certs` (
    `nr`            integer primary key autoincrement, -- Index
    `id`            text,                   -- EI-ID
    `certificate`   text,                   -- Das Zertifikat
    `date_rcpt`     text default '',        -- Eingangsdatum
    `comment`       text default '',        -- Bearbeitungsvermerk
    `date_close`    text default ''         -- Erledigungsdatum
);

Im Feld ‘comment’ werden sukzessive sämtliche Schritte bis zur Verifikation oder entgültigen Ablehnung notiert. In der Regel wird der Nutzer nicht auf diese Daten zurückgreifen müssen; im Bedarfsfall stellen sie aber mit weiteren Daten ein vollständiges Protokoll dar, mit dessen Hilfe auch komplizierte zweifelhafte Fälle geklärt werden können.

Request

Der Import eines zweifelhaften Zertifikats führt zu einem automatischen Verfifikations-Request. Voraussetzung für die Durchführbarkeit ist, dass das Feld EI.ConfirmationInterface Einträge wie:

mail=ei@my_mail.de
url=my_site:my_port

aufweist. url definiert einen Serverport, der einen direkten Echtzeitabgleich erlaubt, mail ein servergestütztes System, das nur mit einer bestimmten Zeitverzögerung arbeitet. [1] Das Mailsystem ist auch für den privaten Nutzer einsetzbar, da er nur ein Postfach für das EI-System reservieren muss.

Werden keine Angaben gefunden, ist ein automatischer Abgleich nicht möglich. Dies wird in der Tabelle ‘invalid_certs’ notiert. Der Nutzer muss das Problem manuell beheben, wenn der das Zertifikat für Kommunikationszwecke nutzen will.

Für den Request wird ein PEM-kodiertes ASN.1-Datenpaket generiert:

Request ::= SEQUENCE {
   request_oid OID ( "EI.Update_Request" ) ,
   random OCTET STRING,
   cert_list SEQUENCE OF Certificate,
}

Es enthält sämtliche bekannten Zertifikate der Familie einschließlich des/der zweifelhaften. Alle Zertifikate werden auf Einträge in EI.Confirmation_Interface untersucht.

Sind verschiedene Einträge in den Zertifikaten der Liste vorhanden, wird die Verhandlung mit allen genannten Interfaces geführt. Die Anfragen werden in der Tabelle ‘requests’ protokolliert:

create table `requests` (
    dest    text,              -- ConformationInterface
    req     text,              -- der Request-String
    resp    text,              -- der Respond-String
    dateout  text              -- spätestes Erledigungsdatum
);

Requests werden in der Reihenfolge direkte-Verifizierung/servergestützte-Verifizierung abgearbeitet, die Antworten im Feld ‘resp’ gespeichert.

Ein Request per URL wird mit dem allgemeinen selbst signierten EI-Basis-Zertifikat durchgeführt. Dieses Zertifikat stellt lediglich die Verschlüsselung der Verbindung sicher, da es von allen Nutzern verwendet werden kann. Es stellt sicher, dass immer eine verschlüsselte Verbindung zu Stande kommt, da dieses Zertifikat nicht abgelehnt wird.

Ein Request per Email muss im Subject-Feld den Textstring EI.Update_Request besitzen. Im Feld From: muss die Antwort-Email-Adresse angegeben sein.

Respond

Das empfangende System liest aus dem ASN.1-Datenpaket sämtliche Zertifikate aus. Berücksichtigt werden ausschließlich die im Request aufgelisteten Zertifikate. Weitere Familienzertifikate werden nicht berücksichtigt.

Für jedes Zertifikat in der Tabelle ‘cert_list’ wird ein ANS.1-Prüfobjekt generiert:

Object_verifier ::= SEQUENCE {
    verify    SEQUENCE {
         oid    OID ( EI.Request_no_private_key |
                      EI.Request_valid_certificate |
                      EI.Request_certificate_invalid ) ,
         random OCTET STRING,
         hash   OID                     -- benutzer Hashalgorithmus für das folgende Feld
         fp     OCTET STRING            -- Hashwert des Zertifikats, als hex-codiederte string "xx:xx:..."
         }
     algorithm OID ( "EMSA4(SHA-256)" | "EI.NO_SIGNATURE" ),
     signature OCTET STRING             -- optional
}

Wenn das Zertifikat nicht bekannt oder kein privater Schlüssel vorhanden ist, ist eine Signatur natürlich nicht möglich. Der Verifier wird mit ‘EI.Request_no_private_key’ markiert, eine Signatur nicht erzeugt. Ist der private Schlüssel bekannt, wird in ‘signature’ die Signatur untergebracht.

Die Verifier werden in eine weitere Struktur verpackt:

Signed ::= SEQUENCE {
    request     Request,
    verify      SEQUENCE OF Object_verifier,
    signer_stat OID ( EI.Request_no_private_key |
                      EI.Request_valid_certificate |
                      EI.Request_certificate_invalid ) ,
    sign_cert   Certificate             -- optional
}

Dabei ist die genaue Reihenfolge der Zertifikate im Request einzuhalten. Abschließend wird der komplette Respond generiert:

Respond ::= SEQUENCE {
    oid         OID ( "EI.Update_Respond" ),
    signed      Signed,
    algorithm   OID ( "EMSA4(SHA-256)" | "EI.NO_SIGNATURE"),
    signature   OCTET STRING   -- optional
}

Der gesamte Respond wird mit dem Zertifikat ‘sign_cert’ signiert. Dieses muss eines der Zertifikate aus dem Request sein. Ist im Request kein eigenes Zertifikat vorhanden, wird keine Signatur erstellt.

Receive-Respond

Email-Antworten werden nur akzeptiert, wenn

  • der Request in der Tabelle ‘request’ notiert ist,
  • der Absender mit der in der Tabelle ‘requests’ notierten Zieladresse übereinstimmt
  • die Nachricht innerhalb des Überwachungsfensters erfolgt ist,
  • der Datensatz korrekt als ‘EI.Resond deklariert ist.

Sämtliche Respond-Sätze werden in der Tabelle ‘requests’ im Feld ‘resp’ notiert, um im Bedarfsfall genauere Auswertungen vornehmen zu können.

Timeout

Läuft die Überwachungszeit in der Tabelle ‘requests’ läuft ab, ohne dass eine Antwort erhalten wurde, wird dies in ‘requests’ und ‘invalid_certs’ notiert. Am Status der betroffenen Zertifikate ändert sich nichts. Wurde das zweifelhafte Zertifikat wird durch einen anderen Request verifiziert, muss ggf. der Nutzer tätig werden.

EI.Update_Respond

Das automatische Verfahren soll höchstmögliche Sicherheit für den Nutzer gewährleisten. Die Auswertungsergebnisse aller Responds werden in der Tabelle ‘invalid_certs’ im Feld ‘comment’ notiert. Ein Zertifikat gilt dann und nur dann als verifiziert, wenn im Respond zu sämtlichen Zertifikaten gültige Signaturen vorgelegt werden. Es genügt ein Respond, der diese Bedingungen erfüllt.

[1]Zukünftig sind auch weitere Mechanismen denkbar.