Stempel waktu dan waktu tepercaya

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

Sekilas pandang

Stempel waktu tidak mencatat “kapan ini ditandatangani.” Yang dibuktikannya lebih sempit sekaligus lebih kuat: bahwa sepotong data tertentu sudah ada sebelum suatu momen tertentu, disaksikan oleh pihak selain penanda tangan. Perbedaan inilah inti nilai waktu tepercaya, dan justru di sinilah sering terjadi salah paham.

Mengapa ini penting

Waktu penandatanganan di dalam sebuah tanda tangan hanyalah apa pun yang diklaim komputer penanda tangan. Jam bisa salah karena ketidaksengajaan maupun disengaja. Jika satu-satunya bukti tentang kapan hanyalah pernyataan penanda tangan itu sendiri, penanda tangan dapat memberi tanggal lebih awal atau lebih lambat pada sebuah dokumen sesuka hati. Sertifikat yang dicabut kemarin dapat dibuat seolah-olah menandatangani tahun lalu. “Kapan” bukan sekadar detail. Ia menentukan apakah tanda tangan yang dibuat dengan sertifikat yang kini kedaluwarsa atau kini dicabut masih berlaku. Dan jika waktu tepercaya salah, setiap argumen validitas jangka panjang yang dibangun di atasnya akan runtuh.

Versi singkatnya

• Waktu penandatanganan yang berasal dari penanda tangan sendiri adalah sebuah klaim, bukan bukti. Klaim ini sangat mudah dipalsukan.
• Sebuah stempel waktu RFC 3161 adalah token bertanda tangan dari sebuah Otoritas Stempel Waktu (TSA) yang mengikat hash data Anda ke waktu milik TSA.
• Bukti yang diberikannya sangat spesifik: data sudah ada sebelum waktu yang dinyatakan oleh TSA. Bukan momen pembuatan yang persis — melainkan sebuah batas atas.
• Token tersebut mengembalikan nonce Anda dan message imprint Anda, sehingga token itu tidak mungkin merupakan replay dan tidak mungkin merujuk ke data yang berbeda.
• Sebuah stempel waktu dokumen menerapkan mekanisme yang sama pada seluruh PDF, menjangkarkan semua yang ada di bawahnya — tanda tangan dan bukti validasi yang tertanam di dalamnya — ke suatu momen tepercaya.

Bagaimana NextPDF menanganinya

NextPDF memperlakukan stempel waktu sebagai sesuatu yang harus diverifikasi, bukan sekadar diperoleh. Meminta sebuah token hanyalah bagian kecil dari pekerjaan ini. Sikap mesin ini jelas: token yang belum diverifikasi bukanlah bukti.

Saat mesin membubuhkan stempel waktu pada sebuah tanda tangan, ia mengirimkan hash data dan nonce acak yang baru ke TSA; data aslinya tidak pernah dikirim. Token yang dikembalikan kemudian diperiksa terhadap seluruh rangkaian properti yang membuatnya bermakna: status otoritasnya adalah “granted”, nonce di dalam token cocok dengan yang dikirim, message imprint di dalam token cocok dengan hash yang dikirim, tanda tangan kriptografis token itu sendiri terverifikasi, jenis konten token adalah jenis stempel waktu, dan waktu yang dinyatakan berada dalam toleransi yang dapat diterima. Setiap penyimpangan menghasilkan kegagalan keras dengan alasan bertipe. Tidak ada jalur “tampaknya cukup mendekati”. Stempel waktu dokumen mengikuti aturan yang sama, diterapkan pada keseluruhan berkas alih-alih pada nilai sebuah tanda tangan.

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

Bagaimana stempel waktu tepercaya diperoleh dan apa yang dibuktikannya: sebuah hash beserta nonce dikirim ke TSA, TSA mengembalikan token bertanda tangan yang mengikat hash tersebut ke waktunya, dan verifikator mengonfirmasi ikatan itu sebelum memperlakukannya sebagai bukti bahwa data sudah ada sebelum waktu tersebut.

Apa kata bukti

Evidence § Standard-backed Evidence: Standard-backed Definisinya presisi. Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 mendefinisikan layanan stempel waktu sebagai layanan yang menyediakan bukti bahwa suatu item data sudah ada sebelum suatu titik waktu tertentu — sebuah batas atas, bukan momen pembuatan. Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 mendefinisikan konten TSTInfo token: sebuah message imprint (hash dari data Anda), sebuah waktu pembuatan, sebuah nomor seri, dan sebuah nonce opsional. Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 menyatakan kesimpulan yang dapat ditarik verifikator saat verifikasi berhasil: bahwa item data sudah ada sebelum waktu di dalam token — tidak lebih dan tidak kurang.

Untuk PDF, Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 menetapkan stempel waktu dokumen: rentang byte mencakup seluruh berkas kecuali nilai Contents, hash tersebut dikirim ke otoritas stempel waktu, dan token RFC 3161 yang dikembalikan — sebagaimana diperbarui oleh Spec Spec: RFC 5816 RFC 5816 — ditempatkan di dalam Contents. Ini adalah disiplin rentang byte yang sama seperti pada tanda tangan, tetapi diterapkan pada waktu, bukan identitas. Dan Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 adalah alasan mengapa hal ini penting untuk ketahanan jangka panjang: waktu tepercayalah yang memungkinkan validator membuktikan bahwa sebuah tanda tangan dapat dipercaya pada saat ia dibuat, bahkan setelah sertifikat kedaluwarsa.

Mesin NextPDF mengirimkan hash dan nonce, tidak pernah data aslinya, lalu memverifikasi token yang dikembalikan terhadap status, nonce, message imprint, tanda tangan token, jenis konten, dan toleransi waktu sebelum memperlakukannya sebagai bukti.

Human-factors note: Human-factors note

Halaman ini diawali dengan klaim yang tepat — stempel waktu membuktikan bahwa data sudah ada sebelum suatu waktu, menurut pihak ketiga — karena kesalahan yang paling umum dan paling mahal di sini adalah melebih-lebihkannya sebagai “bukti momen penandatanganan yang persis.” Menyatakan klaim yang benar dan lebih sempit terlebih dahulu adalah peringatan yang mencegah penyalahgunaan tersebut, ditempatkan sebelum mekanismenya.

Contoh praktis

Anda tidak merakit token stempel waktu secara manual. Yang penting adalah titik integrasi kepercayaan. TSA adalah komponen yang Anda konfigurasikan dan lindungi, karena waktunya menjadi bukti Anda.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

Poin pentingnya adalah bahwa mesin mengirim sebuah hash, bukan dokumennya, sehingga TSA tidak pernah melihat konten Anda. Dan mesin memverifikasi responsnya. TSA yang tidak dapat Anda autentikasi bukanlah waktu tepercaya. Ia hanyalah jam lain.

Kesalahpahaman umum

Jebakannya muncul ketika stempel waktu dibaca sebagai “ini ditandatangani tepat pukul 14:32 pada tanggal ini.” Stempel waktu bukan pencatat waktu peristiwa penandatanganan. Ia membuktikan bahwa data sudah ada paling lambat pada waktu milik TSA, yaitu batas atas yang ditetapkan oleh pihak ketiga. Data tersebut bisa dibuat kapan saja sebelum waktu itu. Jebakan kedua adalah mengasumsikan bahwa server stempel waktu mana pun memberi Anda waktu tepercaya. Token yang tanda tangannya tidak dapat Anda verifikasi, atau yang otoritasnya tidak Anda percayai, tidak membuktikan apa pun. Ia hanyalah jam yang tidak ada alasan bagi Anda untuk mempercayainya. Waktu tepercaya berasal dari TSA yang dapat Anda autentikasi dan token yang telah Anda verifikasi, bukan dari sekadar meminta sebuah angka kepada server.

Batas dan cakupan

NextPDF menyusun permintaan, hanya mengirim hash, dan memverifikasi token yang dikembalikan. Ia tidak menjamin otoritas di baliknya. Akurasi TSA, validitas sertifikatnya sendiri, dan tingkat keterpercayaannya merupakan properti layanan tersebut dan konfigurasi penerapan Anda, bukan properti mesin. Stempel waktu mengikat sebuah hash ke sebuah waktu. Ia tidak menyatakan apa pun tentang makna data, identitas penanda tangan, atau apakah sertifikat penanda tangan valid. Hal-hal itu merupakan pemeriksaan terpisah yang dibahas di Memvalidasi tanda tangan dengan benar. Mesin tidak dapat menjadikan TSA yang tidak layak dipercaya menjadi layak dipercaya. Halaman ini juga tidak menetapkan bobot hukum tertentu apa pun untuk sebuah stempel waktu; hal itu bergantung pada status TSA dan yurisdiksinya. Cara waktu tepercaya digunakan kembali untuk menjaga sebuah tanda tangan tetap dapat diverifikasi selama beberapa dekade dibahas di Validasi jangka panjang.

Ketersediaan stempel waktu per tingkatan:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — sebuah stempel waktu RFC 3161 yang terverifikasi pada nilai tanda tangan, terhadap sebuah TSA yang disediakan oleh penerapan.
Enterprise	○ Menambahkan stempel waktu dokumen yang digunakan oleh B-LT dan B-LTA untuk menjangkar bukti validasi yang tertanam dan untuk menggerakkan loop pembaruan arsip.

Dokumen terkait

• Validasi jangka panjang — bagaimana stempel waktu dokumen menyegel bukti yang tertanam dan memperbaruinya dari waktu ke waktu.
• Profil baseline PAdES — letak stempel waktu tanda tangan (B-T) dan stempel waktu dokumen (B-LTA) dalam urutan tingkatan.
• Tanda tangan berkualifikasi, dijelaskan — letak stempel waktu berkualifikasi dalam gambaran kepercayaan eIDAS.

Glosarium

• Stempel waktu (RFC 3161) — token bertanda tangan dari sebuah TSA yang mengikat hash data ke waktu TSA, membuktikan bahwa data sudah ada sebelum waktu tersebut.
• Otoritas Stempel Waktu (TSA) — layanan tepercaya yang menerbitkan token stempel waktu.
• TSTInfo — struktur konten token: message imprint, waktu pembuatan, nomor seri, dan nonce opsional.
• Message imprint — hash dari data yang distempel waktu, dikembalikan di dalam token.
• Nonce — nilai acak baru yang dikirim bersama permintaan dan dikembalikan di dalam token, sehingga responsnya tidak mungkin merupakan replay.
• Stempel waktu dokumen — sebuah stempel waktu RFC 3161 atas seluruh PDF (sebagaimana diperbarui oleh RFC 5816), menjangkarkan tanda tangan dan buktinya ke suatu momen tepercaya.