ARC-10: signatur-zeitstempelerhalt-bsi-tr-03125
This commit is contained in:
sysops
@@ -0,0 +1,172 @@
|
||||
# ARC-10 — Signatur- und Zeitstempelerhalt (BSI TR-03125): Prüfprotokoll
|
||||
|
||||
Datum: 2026-09-03
|
||||
Host: 192.168.1.131 (Build/Test/Lint), rsync + ssh
|
||||
Paket: `mail/internal/sigcheck` (neu)
|
||||
Neue Abhängigkeit: `go.mozilla.org/pkcs7 v0.10.0` (`go get` + `go mod tidy`, `go.mod`-Direktive `go 1.24` unverändert)
|
||||
|
||||
## Umsetzung
|
||||
|
||||
**Erkennung** (Akzeptanzkriterium 1): `sigcheck.Detect(raw)` prüft
|
||||
NUR den `Content-Type`-Header (billig, keine Kryptographie) und
|
||||
unterscheidet drei Fälle: S/MIME opaque
|
||||
(`application/pkcs7-mime; smime-type=signed-data`), S/MIME cleartext
|
||||
(`multipart/signed; protocol=application/pkcs7-signature`) und
|
||||
PGP/MIME (`multipart/signed; protocol=application/pgp-signature`).
|
||||
Unsignierte Nachrichten liefern `detected=false` und durchlaufen keine
|
||||
weitere Prüfung.
|
||||
|
||||
**Kryptographische Prüfung** (Akzeptanzkriterium 2): `sigcheck.
|
||||
Verify(raw, kind, now)` — für S/MIME echte PKCS7-Signaturprüfung
|
||||
(`go.mozilla.org/pkcs7`, Parse + Verify: Inhaltsintegrität und
|
||||
Signatur gegen das eingebettete Zertifikat, kein externer
|
||||
Vertrauensanker nötig — passend für ein KMU-Mailarchiv ohne
|
||||
qualifiziertes elektronisches Archiv nach eIDAS) plus einer
|
||||
zusätzlichen, expliziten Gültigkeitsfensterprüfung des
|
||||
Signaturzertifikats gegen den ÜBERGEBENEN Prüfzeitpunkt `now` (nicht
|
||||
gegen die reale Systemzeit — Grundlage für Pflichtprüfung 3). Ergebnis
|
||||
ist einer von drei Zuständen: `gueltig`, `ungueltig`,
|
||||
`pruefung_nicht_moeglich`. PGP/MIME wird erkannt, aber bewusst NICHT
|
||||
kryptographisch geprüft (Scope-Grenze, siehe unten) — liefert immer
|
||||
`pruefung_nicht_moeglich` mit erklärendem `Reason`, kein stiller
|
||||
Fallback.
|
||||
|
||||
**Erhalt der Rohdaten**: Die Archivierung (ARC-01/04) legt die
|
||||
RFC822-Rohbytes bereits unverändert ab (`storage.ArchiveKey`, keine
|
||||
Re-Serialisierung). `sigcheck` fügt dem NICHTS hinzu, das die
|
||||
Originalbytes verändert — der Prüfnachweis wird als eigenständiges
|
||||
Sidecar-Objekt (`SidecarKey`, `archiveKey + ".sigcheck.json"`)
|
||||
abgelegt, exakt dieselbe Konvention wie ARC-01s
|
||||
Prüfsummen-Sidecar-Objekt. `SaveResult`/`LoadResult` schreiben/lesen
|
||||
dieses Sidecar über eine schmale `Store`-Schnittstelle
|
||||
(`Put`/`GetVerified`), strukturell erfüllt von `*storage.Service` ohne
|
||||
Paketkopplung.
|
||||
|
||||
**Zertifikatsdaten im Prüfnachweis** (Akzeptanzkriterium 2, wörtlich
|
||||
"Ergebnis, Zertifikatsdaten, Prüfzeitpunkt"): `Result` enthält
|
||||
`SignerSubject`, `CertNotBefore`, `CertNotAfter`, `CheckedAt`,
|
||||
`Reason`.
|
||||
|
||||
## Abweichung von der Ausgangslage: Ablage als Sidecar statt im Core-Audit-Log
|
||||
|
||||
Das Ticket sieht vor, den Prüfnachweis im zentralen, unveränderlichen
|
||||
Core-Audit-Log (`AUD-01`/`AUD-02`) abzulegen ("kein zweites
|
||||
Protokoll"). `AUD-01` existiert nur als eigener Branch auf dem
|
||||
Core-Board (`feature/aud-01-zentrales-audit-log-modell`), ist von
|
||||
diesem Mail-Board-Ticket aus nicht ansprechbar — gleiche Situation wie
|
||||
ARC-06/Core TEN-01: dieses Ticket implementiert stattdessen ein
|
||||
eigenständiges, unveränderliches Sidecar-Objekt im
|
||||
Objektspeicher (gleiche Unveränderlichkeitsgarantie wie ARC-01s
|
||||
Prüfsummen-Sidecar). Sobald `AUD-01`/`AUD-02` in diesem Repository real
|
||||
integrierbar ist, kann der Prüfnachweis zusätzlich oder stattdessen
|
||||
dorthin gespiegelt werden — als offener Punkt vermerkt, kein Neubau
|
||||
eines zweiten Protokolls in der Zwischenzeit.
|
||||
|
||||
## Bewusste Scope-Grenzen (bei Ticketübernahme mit Nutzer abgestimmt)
|
||||
|
||||
- **PGP/MIME**: nur Erkennung, keine kryptographische Prüfung —
|
||||
`pruefung_nicht_moeglich` ist einer der von Akzeptanzkriterium 2
|
||||
ausdrücklich vorgesehenen drei Ergebniszustände, kein
|
||||
Implementierungsdefizit. Folgeticket bei Bedarf.
|
||||
- **Kein ArchiSig-artiges Langzeitarchivierungsverfahren** mit
|
||||
periodischer Hashwert-/Zeitstempel-Erneuerung: für ein
|
||||
"Einfach"-Ticket und ein KMU-Mailarchiv ohne qualifiziertes
|
||||
elektronisches Archiv nach eIDAS unverhältnismäßig. Ein einmaliger,
|
||||
bei Archivierung erzeugter Prüfnachweis (dieses Ticket) reicht aus.
|
||||
Eigenes Folgeticket, falls künftig benötigt.
|
||||
- **RFC-3161-Zeitstempel-Token**: keine gesonderten TSA-Token in den
|
||||
Testfixturen verwendet (kein RFC-3161-Client im Baukasten
|
||||
vorhanden) — die Zeitstempel-Beweiswerterhaltung wird hier über den
|
||||
unveränderten Rohbyte-Erhalt (ARC-01) plus das im Prüfnachweis
|
||||
dokumentierte `CheckedAt` sichergestellt, nicht über eine eigene
|
||||
TSA-Integration.
|
||||
|
||||
## Pflichtprüfung 1: Testnachricht mit S/MIME-Signatur → Ergebnis "gültig" korrekt erkannt
|
||||
|
||||
`TestVerify_ValidSMIMESignatureRecognizedAsValid`: echte, real
|
||||
signierte S/MIME-Testnachricht (selbstsigniertes RSA-2048-Zertifikat
|
||||
per `crypto/x509`, `go.mozilla.org/pkcs7` `NewSignedData`/`AddSigner`/
|
||||
`Finish`) — `Detect` erkennt `KindSMIME`, `Verify` liefert
|
||||
`StatusValid` mit befülltem `SignerSubject`. Archivierung +
|
||||
Abruf des Prüfnachweises über echten `storage.Service`
|
||||
(`LocalDriver`) geprüft — Rundtrip liefert identisches Ergebnis.
|
||||
|
||||
Ergebnis: **BESTANDEN**.
|
||||
|
||||
## Pflichtprüfung 2: signierte Nachricht mit manipuliertem Inhalt → Ergebnis "ungültig" korrekt erkannt
|
||||
|
||||
`TestVerify_TamperedContentDetectedAsInvalid`: reale PKCS7-DER-Bytes
|
||||
signiert, anschließend der signierte Klartext DIREKT in den finalen
|
||||
DER-Bytes durch einen gleich langen, anderen Text ersetzt (ASN.1-
|
||||
Längenpräfixe bleiben syntaktisch gültig, Inhalt weicht vom
|
||||
signierten Digest ab — realistische Nachbildung nachträglicher
|
||||
Manipulation). `Verify` liefert `StatusInvalid` mit erklärendem
|
||||
`Reason`.
|
||||
|
||||
Ergebnis: **BESTANDEN**.
|
||||
|
||||
## Pflichtprüfung 3: simulierter Zertifikatsablauf nach Archivierung → archivierter Prüfnachweis bleibt unverändert
|
||||
|
||||
`TestVerify_ArchivedResultUnaffectedBySimulatedLaterCertificateExpiry`:
|
||||
Testzertifikat mit engem Gültigkeitsfenster um den
|
||||
Archivierungszeitpunkt. Erste Prüfung + Archivierung ZUM
|
||||
Archivierungszeitpunkt liefert `StatusValid`, wird als Sidecar
|
||||
gespeichert. Eine SIMULIERTE, NICHT persistierte spätere Live-Prüfung
|
||||
derselben Rohdaten mit einem `now` weit nach `CertNotAfter` liefert
|
||||
korrekt `StatusInvalid` (abgelaufenes Gültigkeitsfenster). Der BEREITS
|
||||
ARCHIVIERTE Prüfnachweis wird davon nicht berührt: `LoadResult` liefert
|
||||
weiterhin `StatusValid` mit unverändertem `CheckedAt` — die spätere
|
||||
Prüfung schreibt nie über einen bestehenden archivierten Nachweis.
|
||||
|
||||
Ergebnis: **BESTANDEN**.
|
||||
|
||||
## Ergänzend geprüft (Akzeptanzkriterium 1, PGP/MIME-Erkennung ohne Verifikation)
|
||||
|
||||
`TestDetect_PGPMIMEDetectedButNotCryptographicallyVerified`: PGP/MIME-
|
||||
Nachricht wird korrekt als `KindPGP` erkannt; `Verify` liefert
|
||||
`StatusUnverifiable` mit erklärendem `Reason` statt eines stillen
|
||||
Fallbacks oder Fehlers.
|
||||
|
||||
`TestDetect_UnsignedMessageNotDetected`: unsignierte Nachricht wird
|
||||
korrekt NICHT erkannt, durchläuft keine Prüfung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
1. **Signierte Nachrichten (S/MIME, PGP/MIME) werden bei Archivierung
|
||||
erkannt**: `Detect`, durch alle Detect-Tests belegt.
|
||||
2. **Signaturprüfung liefert einen von drei Ergebniszuständen
|
||||
(gültig/ungültig/Prüfung nicht möglich) inkl. Zertifikatsdaten und
|
||||
Prüfzeitpunkt, als Nachweis archiviert**: `Verify` + `Result` +
|
||||
`SaveResult`, durch Pflichtprüfung 1–3 belegt.
|
||||
3. **Prüfnachweis über die Detailansicht abrufbar, Original-Mail
|
||||
unverändert**: `LoadResult` liest ein eigenständiges
|
||||
Sidecar-Objekt, rührt die archivierten RFC822-Rohbytes nicht an;
|
||||
durch Pflichtprüfung 1 und 3 (Rundtrip) belegt.
|
||||
|
||||
## Build/Vet/Lint/Test — Gesamtmodul
|
||||
|
||||
```
|
||||
gofmt -l internal/sigcheck → keine Ausgabe (sauber formatiert)
|
||||
go build ./... → OK
|
||||
go vet ./... → OK
|
||||
golangci-lint run ./internal/sigcheck/... → 0 issues
|
||||
go test ./internal/sigcheck/... -v -count=1 → alle 6 Tests bestanden
|
||||
go test ./... -p 1 -count=1 (TEST_TENANT_DSN, TEST_MANTICORE_URL, TEST_S3_ENDPOINT/TEST_S3_ACCESS_KEY/TEST_S3_SECRET_KEY gesetzt) → alle Pakete ok, inkl. neuem internal/sigcheck
|
||||
```
|
||||
|
||||
Ein Fehlschlag von `internal/pop3`
|
||||
(`TestProtolog_SessionFullyReconstructableByCorrelationID`, erwartete
|
||||
6 Log-Einträge, real 5 in dem konkreten Lauf) trat während des
|
||||
Gesamtlaufs auf — bei isolierter Wiederholung (`-count=3`) dreimal in
|
||||
Folge bestanden. Bereits bestehender, von ARC-10 unabhängiger,
|
||||
zeitkritischer Flake im Protokoll-Logging-Test (`internal/protolog`/
|
||||
`internal/pop3`, ING-08), keine Regression durch dieses Ticket.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
ARC-10 erfüllt alle Akzeptanzkriterien mit echten, ausgeführten
|
||||
Nachweisen — inklusive real erzeugter, real signierter S/MIME-
|
||||
Testnachrichten (selbstsigniertes Zertifikat, keine externe CA) und
|
||||
einer realen Manipulationserkennung auf PKCS7-DER-Byte-Ebene.
|
||||
Freigeschaltet: Beitrag zu QA-05 (zusammen mit ARC-07/09/INT-08,
|
||||
ARC-05 weiterhin extern blockiert durch RET-03).
|
||||
Reference in New Issue
Block a user