Zusammenfassung

  • RFC 3125 verlangte eine Policy-OID und den Hash einer definitiven Spezifikation im Signaturprozess, damit der Prüfer genau die referenzierten Regelbytes anwenden konnte.
  • Korrekte Signatur und korrekter Hash beendeten die Prüfung nicht: Zeitraum, Commitment, Zertifikate, Sperrstatus, Zeit, Attribute, Algorithmen, Anerkennung und Ergebnis blieben getrennt.

Die Kryptografie enthielt nicht das gesamte Geschäft

Eine Signatur kann zeigen, dass Bytes unter Schlüssel und Algorithmus verifizieren. Ein Vertrag fragt weiter: War das Zertifikat für diesen Zweck zulässig? Lag die Erstellung im Zeitraum? Bedeutete sie Zustimmung oder Empfang? Welche Sperr- und Zeitnachweise waren erforderlich?

RFC 3125 erschien im September 2001 als Experimental. Sie nannte das Regelwerk für Erstellung und Validierung Signature Policy. Ein rechtlicher oder vertraglicher Kontext konnte eine Policy anerkennen. Die RFC selbst erzeugte diese Anerkennung nicht.

Policy Issuer, Signer, Verifier, Arbitrator und Trust Service Provider blieben getrennte Rollen. Der Issuer definierte Anforderungen, der Signer verpflichtete sich auf die Referenz, der Verifier wandte sie an, der Arbitrator konnte später erneut prüfen. Ein gemeinsames Artefakt bedeutete keine gemeinsame Autorität.

Die OID verwies auf Regeln, ersetzte sie aber nicht

Die Policy brauchte eine Object Identifier, eine Spezifikation und eine definitive Form mit eindeutiger Binärkodierung. Der Signer lieferte deren Hash; der Verifier prüfte ihn.

OID bestimmte Identität, Hash bestimmte Bytes. ASN.1 und DER boten optional eine deterministische maschinenlesbare Form. Ein mehrdeutiger Name konnte so nicht unbemerkt mehrere Fassungen vertreten.

Doch eine OID war kein Gütesiegel. Hashgleichheit zeigte, dass beide Seiten dasselbe Regelwerk nutzten. Sie belegte weder Zuständigkeit des Issuers noch externe Verfahrensschritte oder Anerkennung durch Gericht und Partner. Deshalb musste die Policy auch menschenlesbar sein.

Gültigkeit erhielt sichtbare Parameter

Die Struktur enthielt Signing Period, Common Rules und Commitment Rules. Außerhalb des Zeitraums konnte eine mathematisch korrekte Signatur die Erstellungsregel verletzen.

Gemeinsame Regeln betrafen Pflichten, Zertifikat-, Zeit- und Attributvertrauen sowie Algorithmen. Commitment Rules passten sie an Zustimmung, Empfang oder eine im Nachrichtensinn enthaltene Verpflichtung an. Erst nach Policy-Fassung und Commitment konnte der passende Trust Path entstehen.

Eine Chain konnte in einem Anwendungsfeld gelten und in einem anderen nicht. Ein Schlüssel konnte vor einer Algorithmusgrenze zulässig und danach unzulässig sein. Das nackte Wort „gültig“ löschte diese Parameter.

Vertrauensdienste lieferten Teilbelege

Certification und Registration Authorities, Repositories, Timestamp Authorities, Status Responder und Attribute Authorities konnten beteiligt sein. Die Policy wählte Trust Points, Pfade, Sperrbelege, Zeiten und Rollen.

Ein Zertifikat verband Schlüssel und Behauptung. Ein Status bezog sich auf Zertifikat und Zeit. Ein Timestamp belegte vorherige Existenz. Ein Attribut stützte eine Rolle. Keines entschied allein über das Geschäft.

Eine reproduzierbare Prüfung musste Responses, Zeiten, Software und verbrauchende Regel speichern. Nur ein grünes Ergebnis ließ sich später nicht schlichten.

Der Policy-Hash beobachtete nicht jedes Verfahren

CMS-Attribute, Zertifikatreferenzen und eingebettete Zertifikate waren maschinell prüfbar. Key Custody, interne Freigabe und menschliche Schritte konnten außerhalb liegen.

Der Hash identifizierte das Regelbuch; er bewies nicht jede darin verlangte Handlung. „Gültig unter OID X“ bedeutete daher nicht automatisch Vertretungsmacht, Annahme, Zahlung oder Erfüllung. Dafür brauchte es andere Evidenz.

Algorithmen machten die Entscheidung historisch

RFC 3125 betonte Private-Key-Schutz und nachlassende Algorithmusstärke. Implementierungen sollten modular sein; Policies konnten Algorithmus und Schlüssellänge begrenzen.

Spätere Prüfung brauchte damalige Fassung, Zeitraum, Timestamps und Migrationsregel. Nachträgliche Deprecation beantwortete die Behandlung alter Evidenz nicht allein.

RFC 3126 behandelte langfristige Formate, RFC 3161 Zeitstempel. RFC 2630, 2634, 2459 und 2560 bildeten CMS-, S/MIME-, PKIX- und Statuskontext; RFC 5280 und 5652 folgten später. Keine Quelle beweist einen benannten RFC-3125-Einsatz.

Experimental war kein Deployment-Bericht

Conformance verlangte Verarbeitung nach der identifizierten Policy. Das war eine Pflicht für konforme Teilnehmer, keine Marktstatistik.

Der belegbare Beitrag war eine nachvollziehbare Kette aus OID, definitiver Form, eindeutiger Kodierung, Hash, Commitment und Trust Conditions. Adoption, Interoperabilität und Rechtswirkung brauchen eigene Quellen.

Der vollständige Beleg enthielte Objekt, Signatur, Zertifikat, OID, Policy, Hash, Zeitraum, Commitment, Pfade, Sperrstatus, Zeiten, Attribute, Algorithmen und Verifier-Ausgabe, danach den Vertrag, der die Policy anerkannte. Kryptografie schloss eine Rechnung; die Policy bestimmte ihre Relevanz.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3125.txt
  2. https://www.rfc-editor.org/info/rfc3125
  3. https://datatracker.ietf.org/doc/rfc3125/
  4. https://www.rfc-editor.org/rfc/rfc3126.txt
  5. https://www.rfc-editor.org/rfc/rfc2630.txt
  6. https://www.rfc-editor.org/rfc/rfc2634.txt
  7. https://www.rfc-editor.org/rfc/rfc2459.txt
  8. https://www.rfc-editor.org/rfc/rfc2560.txt
  9. https://www.rfc-editor.org/rfc/rfc3161.txt
  10. https://www.rfc-editor.org/rfc/rfc2119.txt
  11. https://www.rfc-editor.org/rfc/rfc5280.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt