-- Migration 021: Herkunft eines Hardwarekeys festhalten
--
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
--
-- ---------------------------------------------------------------------------
-- Warum das nicht schon in 019 stand
-- ---------------------------------------------------------------------------
-- 019 hat die Attestation bewusst nicht geprueft und deshalb auch nichts
-- darueber gespeichert: Wer seinen eigenen Schluessel an seinem eigenen Server
-- registriert, muss sich nicht ausweisen lassen. Die Spalte aaguid war dabei
-- schon angelegt - und blieb in der Praxis immer leer. Das ist kein Fehler
-- der Umsetzung, sondern Absicht des Standards: Fordert eine Seite
-- attestation "none" an, ersetzt der BROWSER die Geraetekennung durch
-- sechzehn Nullbytes, bevor der Server sie zu sehen bekommt. Ohne
-- angeforderte Attestation gibt es also grundsaetzlich keine Herkunft, nicht
-- einmal eine ungepruefte.
--
-- Gebraucht wird sie, seit die Frage anders lautet: Ein Passwortverwalter
-- liess sich als zweiter Faktor registrieren. Fuer das Deploymentcenter
-- selbst ist das hinnehmbar, fuer ein Protokoll, das ausdruecklich Hardware
-- verlangt, nicht.
--
-- ---------------------------------------------------------------------------
-- attested ist die einzige Spalte, an der eine Entscheidung haengt
-- ---------------------------------------------------------------------------
-- Die drei uebrigen sind Anzeige und Nachvollziehbarkeit. Die Trennung ist
-- beabsichtigt: attestation_ca und attestation_root kommen aus einem
-- Zertifikat, das der Authenticator geschickt hat - also von aussen. Sie
-- eignen sich, um einem Menschen zu zeigen, was da angekommen ist, aber nicht
-- als Grundlage eines Vergleichs im Code. Was die Pruefung ergeben hat, steht
-- in genau einem Bit, und das hat der Server selbst gesetzt.
--
-- Vorgabe 0: Alles, was vor dieser Migration registriert wurde, ist NICHT
-- attestiert - und zwar unabhaengig davon, ob es ein Yubikey war. Das ist die
-- ehrliche Vorgabe. Ein "war bestimmt Hardware" waere eine Behauptung ueber
-- etwas, das nie geprueft wurde, und genau solche Behauptungen soll diese
-- Migration abschaffen. Wer die Stufe "strict" nutzen will, nimmt seinen
-- Schluessel einmal neu auf; das ist der Preis dafuer, dass die Spalte etwas
-- bedeutet.
ALTER TABLE dc_user_credentials
  ADD COLUMN attested TINYINT(1) NOT NULL DEFAULT 0 AFTER aaguid;

-- Das Attestationsformat, so wie der Authenticator es genannt hat:
-- "packed" (CTAP2, der Normalfall beim YubiKey 5), "fido-u2f" (CTAP1),
-- "none" (Passwortverwalter und eingebaute Passkeys).
ALTER TABLE dc_user_credentials
  ADD COLUMN attestation_fmt VARCHAR(32) NULL AFTER attested;

-- Der Name aus dem Blattzertifikat - bei Yubico etwa
-- "Yubico U2F EE Serial 1234567890".
ALTER TABLE dc_user_credentials
  ADD COLUMN attestation_ca VARCHAR(190) NULL AFTER attestation_fmt;

-- Die Wurzel, bei der die Kette geendet hat. Sie steht hier und nicht nur im
-- Protokoll, weil sie die Frage "warum gilt dieser Schluessel als Hardware"
-- ohne Blick in die Logdatei beantwortet.
ALTER TABLE dc_user_credentials
  ADD COLUMN attestation_root VARCHAR(190) NULL AFTER attestation_ca;

-- ---------------------------------------------------------------------------
-- Die Regel selbst steht in dc_settings, nicht hier
-- ---------------------------------------------------------------------------
-- Eingetragen wird sie erst beim ersten Speichern in der Oberflaeche. Ein
-- INSERT waere hier moeglich, wuerde aber eine Entscheidung vorwegnehmen:
-- Eine Migration, die eine Sicherheitsstufe setzt, aendert im Vorbeigehen das
-- Verhalten einer laufenden Anlage. Fehlt der Eintrag, liest
-- HardwarePolicy::level() die Vorgabe "off" - also genau das Verhalten von
-- vorher. Umgestellt wird, wenn jemand umstellt.