Begleitnotiz · kein Kernfeature

Interner RFC-3161-Zeitstempeldienst.

Jeder CodeB-Tenant bringt einen internen RFC-3161-Zeitstempel-Endpunkt unter /csc/v2/signatures/tsa mit. Ein DER-TimeStampReq geht rein, ein DER-TimeStampResp kommt zurück — signiert von einem tenant-eigenen Responder-Zertifikat, das die Plattform bei der ersten Anfrage für Sie erzeugt. Das ist die Ergänzung zum externen TSA-Proxy unter /csc/v2/signatures/timestamp, der an einen öffentlichen TSA weiterleitet (standardmäßig Sectigo). Beide fallen in den Umfang der fortgeschrittenen elektronischen Signatur. Keiner ist eIDAS-qualifiziert.

Umfangserklärung. Das interne TSA-Zertifikat ist vom Tenant selbstsigniert — es ist kein qualifizierter TSA nach ETSI EN 319 421, und die ausgestellten Token sind keine qualifizierten elektronischen Zeitstempel nach Verordnung (EU) 910/2014 Artikel 41. Nutzen Sie sie so, wie Sie jeden RFC-3161-Token von einem internen Unternehmens-TSA nutzen würden: um in PAdES-B-T-/-B-LT-/-B-LTA-Hüllen einen Zeit-existiert-Beweis für interne oder vertraglich gebundene Audit-Trails zu fixieren.

Zwei TSA-Optionen — pro Deployment wählbar.

Externer TSA-Proxy

POST /csc/v2/signatures/timestamp

Leitet an die TSA-URL weiter, die in HKLM\SOFTWARE\CodeB\TSAURL hinterlegt ist.
Standard bei leerem Registry-Wert: http://timestamp.sectigo.com/qualified.
Verpackt in eine JSON-Request/Response-Hülle mit base64-kodiertem Token — bequem für den Browser-Signer.
Vertrauenskette folgt dem vorgelagerten TSA (weit verbreitete kommerzielle Roots).

Interner TSA-Aussteller

POST /csc/v2/signatures/tsa

Antwortet mit einem vollen DER-TimeStampResp, signiert vom eigenen TSA-Responder-Zertifikat des Tenants.
Erzeugt das Responder-Zertifikat automatisch bei der ersten Anfrage — kein Betreiber-Setup nötig.
Hält die gesamte Vertrauenskette im Tenant — nützlich für luftisolierte oder souveräne Deployments.
Nicht qualifiziert. Verlassende Parteien benötigen das TSA-Zertifikat des Tenants in ihrer Vertrauensliste.

POST `/csc/v2/signatures/tsa` Offen #

Vollständiges RFC-3161-Wire-Protokoll. Kein Bearer erforderlich — RFC 3161 §1.4 beschreibt TSAs als typischerweise offene Dienste. Die Host-Rate-Limits bleiben aktiv.

Anfrage

Content-Type: application/timestamp-query
Body:            DER-kodierter TimeStampReq
                 (INTEGER version, MessageImprint {AlgorithmIdentifier hashAlgo, OCTET STRING hashedMessage},
                  OBJECT IDENTIFIER reqPolicy OPTIONAL,
                  INTEGER nonce OPTIONAL,
                  BOOLEAN certReq DEFAULT FALSE,
                  Extensions extensions OPTIONAL)

Antwort

Content-Type: application/timestamp-reply
Body:            DER-kodierter TimeStampResp
                 (PKIStatusInfo status, TimeStampToken timeStampToken OPTIONAL)

Bei Erfolg ist PKIStatus gleich 0 (granted). Das TimeStampToken ist ein vollständiges CMS-SignedData, dessen eContent die TSTInfo-Struktur trägt (Version, Policy, MessageImprint-Echo, INTEGER-Serial, GeneralizedTime genTime, Nonce-Echo).

Unterstützte Hash-Algorithmen

2.16.840.1.101.3.4.2.1 — SHA-256 (32 Bytes)
2.16.840.1.101.3.4.2.2 — SHA-384 (48 Bytes)
2.16.840.1.101.3.4.2.3 — SHA-512 (64 Bytes)

Andere Algorithmen werden mit PKIStatus=2 (rejection), failInfo=0 (badAlg) abgelehnt.

Fehler-Antworten (RFC 3161 §2.4.2)

failInfo = 0 (badAlg) — nicht unterstützte Hash-Algorithmus-OID.
failInfo = 5 (badDataFormat) — Body fehlt, ist nicht parsebar oder die MessageImprint-Hash-Länge passt nicht zum deklarierten Algorithmus.
failInfo = 25 (systemFailure) — TSA-Credential nicht ladbar oder Serial-Counter nicht verfügbar.

Beispiel

openssl ts -query -data document.pdf -sha256 -no_nonce -out req.tsq
curl -H "Content-Type: application/timestamp-query" \
     --data-binary @req.tsq \
     https://phone.aloaha.com/csc/v2/signatures/tsa \
     -o resp.tsr
openssl ts -reply -in resp.tsr -text

TSA-Responder-Zertifikat #

Das Zertifikat, das jedes von diesem Endpunkt ausgestellte TimeStampToken signiert. Automatisch bei der ersten Anfrage erzeugt (kein Betreiber-Schritt nötig) und unter App_Data/<tenant>/tsa-cert/tsa.pfx persistiert. Der private Schlüssel wird per DPAPI im LocalMachine-Scope verpackt, sodass ein Wiederherstellen des Ordners auf einem anderen Host den Schlüssel nicht öffnet.

Zertifikatsprofil

Subject DN: CN=<tenant> TSA Responder, O=Aloaha Limited, C=MT
Schlüsselalgorithmus: EC P-256 (id-ecPublicKey, Kurve secp256r1)
Signatur: ECDSA mit SHA-256 (1.2.840.10045.4.3.2)
Gültigkeit: 5 Jahre ab Erzeugung
Extension: ExtendedKeyUsage critical, Werte ausschließlich id-kp-timeStamping. Gemäß RFC 3161 §2.3 MUSS die EKU vorhanden sein, MUSS critical sein und DARF nur id-kp-timeStamping enthalten.
Extension: KeyUsage critical, Werte digitalSignature + nonRepudiation.
Extension: BasicConstraints critical, CA:FALSE.
Extension: SubjectKeyIdentifier (SHA-1 über SubjectPublicKeyInfo).

Serial-Counter

Jeder ausgestellte Token bekommt eine frische, monoton steigende INTEGER-Serial. Der Counter liegt unter App_Data/<tenant>/tsa-cert/serial.counter (ASCII-Dezimal, unter Datei-Lock inkrementiert). Werte werden zur TSTInfo.serialNumber im Token — nicht zur Serial des Responder-Zertifikats.

Automatische Neu-Erzeugung

Der Credential-Loader prüft bei jeder Anfrage NotAfter > UtcNow. Wenn das Responder-Zertifikat weniger als 30 Tage bis zum Ablauf hat oder bereits abgelaufen ist, wird eine neue PFX erzeugt und der Counter läuft weiter (unter dem alten Zertifikat ausgestellte Token bleiben verifizierbar, bis die verlassende Partei das alte Zertifikat aus ihrer Trust-Liste entfernt).

Betriebshinweise #

Responder-Zertifikat abrufen

Das öffentliche Responder-Zertifikat (base64 DER) wird über /csc/v2/credentials/info mit dem Tenant-TSA-Slug als credentialID ausgeliefert — derselbe Mechanismus wie für Signer-Credentials. Verlassende Parteien nehmen es einmalig in ihre PDF-Reader- / TSA-Trust-Liste auf, danach validiert jedes weitere Token aus diesem Tenant.

Nonce- und Policy-Behandlung

Trägt die Anfrage eine nonce-INTEGER, spiegelt die TSTInfo sie wörtlich zurück (RFC 3161 §2.4.2 Replay-Schutz). Ohne Nonce ist der Token bezüglich desselben MessageImprint deterministisch. Die in TSTInfo.policy ausgegebene Policy-OID ist eine private OID, die das Profil dieses internen TSA dokumentiert (Best-Effort-Genauigkeit, selbstsigniertes Responder-Zertifikat) — sie kollidiert bewusst mit keiner eIDAS-qualifizierten Policy-OID.

Rate Limiting und Observability

Der Endpunkt sitzt hinter demselben Pro-IP-Bucket wie der Rest von /csc.ashx (30 Requests pro Minute pro Aktion). Jede Ausstellung emittiert eine [METRIC] csc.tsa.issued-Logzeile; jede Ablehnung emittiert [METRIC] csc.tsa.rejected reason=<badAlg|badDataFormat|cred|parse|body_empty|crash>. Traces tragen Tenant-Slug, Hash-Algorithmus, Hash-Präfix (8 Bytes hex), Nonce-Präfix und die zugewiesene TSTInfo-Serial.

Wann welchen Endpunkt

Interne Audit-Trails, luftisolierte Tenants, souveräne Deployments → interner TSA. Die Vertrauenskette verlässt nie Ihre Infrastruktur.
Dokumente, die von Dritten validiert werden, die kommerziellen Roots vertrauen → externer TSA-Proxy (Sectigo Standard, oder zeigen Sie die Registry auf einen TSA, mit dem Sie eine Beziehung haben).
Zeitstempel soll in einer PAdES-B-T-PDF landen, die im Browser gebaut wird → der externe TSA-Proxy ist das, was sign.html nutzt — er liefert einen base64-Token in einer kleinen JSON-Hülle.
Standard-RFC-3161-Client (OpenSSL, digiseal, pyHanko) soll auf eine TSA-URL zeigen → auf den internen Endpunkt zeigen lassen. Er spricht das Wire-Protokoll direkt.

Standards & Verweise #

RFC 3161 — Time-Stamp Protocol. Wire-Format für TimeStampReq, TimeStampResp, TimeStampToken, TSTInfo und die oben genannten PKIStatusInfo-/-PKIFailureInfo-Fehlercodes.
RFC 5816 — ESSCertIDv2-Update für die RFC-3161-Signing-Certificate-Referenz.
RFC 5652 — Cryptographic Message Syntax (das CMS-SignedData, das die TSTInfo umhüllt).
RFC 5280 — Internet-X.509-PKI-Profil (KeyUsage-, EKU-, BasicConstraints-Behandlung am Responder-Zertifikat).
ETSI EN 319 421 — Policy- und Sicherheitsanforderungen für TSAs. Referenziert zur Umfangsklarstellung: Dieser interne TSA ist mit diesem Standard nicht konform, denn das erforderte einen akkreditierten Vertrauensdiensteanbieter und einen überwachten Responder-Schlüssel.
ETSI EN 319 422 — TSA-Profile und -Protokolle.
Verordnung (EU) 910/2014 — Artikel 41 (elektronische Zeitstempel) und 42 (qualifizierte elektronische Zeitstempel). Token dieses Endpunkts fallen unter Art. 41 — zulässig als Beweismittel, aber ohne die Genauigkeitsvermutung, die qualifizierte Zeitstempel genießen.

Verwandt auf dieser Seite: CSC v2 API · Externer TSA-Proxy · Browser-Signer · Alle öffentlichen APIs

Fragen? Fragen Sie uns.