Prüfpakete laden
Eine oder mehrere Prüfpaket-Dateien (JSON) auswählen oder in dieses Fenster ziehen. Mehrere Pakete desselben Kontos werden zusätzlich als Siegelfolge geprüft. Neu geladene Pakete kommen zu den bisherigen hinzu.
Keine Pakete geladen.
Ergebnis maschinenlesbar (JSON)
Dasselbe Ergebnis als Text, für Skripte und Assistenzsysteme. Das Gesamturteil lautet gueltig, ungueltig oder unvollstaendig.
{}
Was geprüft wird und was nicht
Geprüft wird nach der Spezifikation des Siegelformats v1 und, für Siegel je Mitglied eines Unternehmens, v2:
- Format des Pakets und des Siegeldokuments (ctx mytid-month-seal-v1 oder mytid-month-seal-v2, alle Felder),
- Siegel-Hash über die kanonische Form (RFC 8785),
- Schlüssel: keyId ist der SHA-256 des mitgelieferten öffentlichen Schlüssels,
- Signatur des Siegels (ECDSA P-256, SHA-256) und Gleichlauf der DER-Form,
- entriesRoot aus allen Einträgen samt Feldsalzen (Merkle-Baum nach RFC 6962), auch bei geschwärzten Feldern,
- entryCount,
- Urheber-Signaturen der Einträge (mytid-entry-v1, mytid-storno-v1), soweit der Schlüssel im Paket liegt und die Felder offen sind,
- bei Siegeln je Mitglied (v2): jeder Eintrag gehört laut Erfassungssignatur dem Mitglied (owner gleich member),
- Schlüsselübergaben (mytid-key-rotation-v1),
- bei mehreren Paketen die Siegelfolge: Verkettung über prevSeal, Lücken, Ablösung über supersedes, Schlüsselwechsel; bei v2 je Mitglied.
Nicht geprüft werden kann hier:
- der Zeitpunkt der Versiegelung. Pakete der Version 1 enthalten keinen Zeitanker; sealedAt stammt von der Geräteuhr.
- der Sperrstatus des Schlüssels. Er steht im Transparenzprotokoll und ist offline nicht abrufbar.
- ob die erfassten Zeiten stimmen. Ein gültiges Siegel belegt nur, dass die Einträge unverändert sind, seit der Inhaber des Schlüssels sie gesiegelt hat.
- wem ein Schlüssel gehört. Den Fingerabdruck mit einer unabhängigen Angabe des Inhabers vergleichen.