Memvalidasi tanda tangan dengan benar

Spec Spec: RFC 5280, §6 RFC 5280 §6 Spec Spec: RFC 6960 RFC 6960 Spec Spec: RFC 5652 RFC 5652 Evidence ✓ Test-backed Evidence: Test-backed

Sekilas pandang

“Tanda tangan valid” biasanya hanya berarti satu hal sudah diperiksa: perhitungan matematisnya cocok. Validasi yang benar memeriksa setidaknya lima hal independen, dan salah satunya bisa gagal dengan cara yang membuat tanda centang hijau tidak bermakna. Halaman ini menyajikan jaringan pemeriksaan secara lengkap dan menjelaskan mengapa jawaban yang parsial bisa berbahaya.

Mengapa ini penting

Satu nilai boolean adalah keluaran paling berbahaya dalam keseluruhan topik ini. Ini mendorong pembaca untuk menganggap “valid” sebagai “dapat dipercaya,” padahal “valid” mungkin hanya berarti bahwa byte tidak diubah — oleh kunci dari sertifikat yang kedaluwarsa tiga tahun lalu, dicabut bulan lalu, dan berantai ke otoritas yang tidak Anda kenali. Masing-masing hal tersebut merupakan pemeriksaan terpisah. Perangkat lunak yang melaporkan satu nilai boolean diam-diam telah memutuskan pemeriksaan mana yang penting, dan memutuskannya untuk Anda. Dalam konteks yang teregulasi atau kontraktual, “alat menyatakan valid” bukanlah pembelaan jika alat tersebut hanya memverifikasi properti yang paling murah.

Versi singkatnya

Validasi yang lengkap menjawab lima pertanyaan terpisah. Kelimanya bersifat independen — lolos pada satu pertanyaan tidak mengatakan apa pun tentang yang lainnya:

1. Integritas — apakah byte yang ditandatangani masih menghasilkan hash yang sama dengan nilai yang dicakup oleh tanda tangan? (Hitung ulang digest byte-range; bandingkan.)
2. Keaslian — apakah tanda tangan kriptografis terverifikasi terhadap kunci publik dalam sertifikat penanda tangan, atas atribut yang ditandatangani?
3. Jalur sertifikat — apakah sertifikat tersebut berantai ke trust anchor yang Anda pilih, dengan setiap mata rantai valid?
4. Waktu — apakah sertifikat berada dalam jendela validitasnya pada waktu yang relevan, dan apakah waktu tersebut tepercaya alih-alih ditetapkan sendiri?
5. Pencabutan — apakah sertifikat tidak dicabut pada waktu tersebut, berdasarkan bukti (OCSP/CRL) yang benar-benar dapat Anda peroleh atau yang sudah tertanam?

Status “valid” yang tidak melakukan kelima pemeriksaan tersebut adalah jawaban tidak lengkap yang tampak seperti jawaban lengkap.

Bagaimana NextPDF menanganinya

Pendekatan NextPDF adalah bahwa setiap pertanyaan bersifat terpisah dan masing-masing harus dijawab secara eksplisit. Sebuah pertanyaan tidak pernah diringkas menjadi satu flag yang optimistis, dan tidak pernah dilewati secara diam-diam hanya karena suatu pemeriksaan dianggap merepotkan. Hal ini ditegakkan melalui pengujian. Itulah sebabnya halaman ini ditandai sebagai test-backed alih-alih standard-backed: perilakunya dijaga oleh suite pengujian, bukan hanya diargumentasikan dari satu klausul.

Integritas dan keaslian diuji secara menyeluruh dari ujung ke ujung. Suite menggunakan sertifikat yang diketahui untuk menandatangani struktur signed-attributes yang sesungguhnya, lalu memverifikasi tanda tangan dengan kunci publik yang cocok di sejumlah vektor waktu. Jadi, perubahan yang merusak struktur kanonis akan menggagalkan pengujian. Validasi jalur sertifikat dijaga oleh pengujian yang sengaja merusak satu byte tanda tangan dan memastikan bahwa hasilnya tidak valid disertai alasan terstruktur — bukan eksepsi yang dibuang, melainkan kegagalan yang tercatat secara eksplisit. Verifikasi token timestamp dipecah menjadi langkah-langkah terpisah — decode, signer info, signed attributes, message digest, certificate binding, key usage, signature, produced-at — dan setiap langkah diuji secara tersendiri, sehingga “timestamp terverifikasi” berarti setiap langkah telah terverifikasi. Soft-failure pencabutan (responder yang tidak dapat dijangkau) dibedakan, baik dalam kode maupun dalam pengujian, dari “dicabut” yang definitif. Keduanya tidak pernah disatukan menjadi jawaban yang sama.

1. Integrity Recompute the byte-range digest and compare it to the value the signature covers.
2. Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
3. Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
4. Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
5. Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Lima pertanyaan independen yang dijawab oleh validasi tanda tangan PDF yang benar, secara berurutan. Masing-masing terpisah: lolos pada satu pertanyaan tidak mengatakan apa-apa tentang yang lainnya, dan melewatkan salah satunya membuat hasil keseluruhan menjadi tidak lengkap.

Apa yang dikatakan bukti

Evidence ✓ Test-backed Evidence: Test-backed Perilaku ini ditopang oleh pengujian, dan pengujian tersebut mengimplementasikan apa yang disyaratkan oleh standar.

Integritas mengikuti Spec Spec: ISO 32000-2, §12.8.1 ISO 32000-2 §12.8.1 : digest dihitung ulang atas rentang byte dan dibandingkan dengan nilai yang tersimpan, dan perbedaan apa pun berarti tanda tangan tidak valid. Keaslian atas atribut yang ditandatangani dicakup oleh pengujian integrasi yang menandatangani sekumpulan signed-attributes yang sesungguhnya dan memverifikasinya dengan kunci publik yang cocok di sejumlah vektor waktu. Pertanyaan jalur sertifikat mengacu pada Spec Spec: RFC 5280, §6.1 RFC 5280 §6.1 : jalur yang valid berawal dari trust anchor, dan Spec Spec: RFC 5280, §6.2 RFC 5280 §6.2 menyatakan bahwa algoritma tersebut mendefinisikan kondisi minimum agar suatu jalur dianggap valid — sebuah unit test path validator memastikan bahwa tanda tangan yang dirusak menghasilkan valid = false dengan alasan eksplisit, bukan penerimaan secara diam-diam.

Urutan pencabutan mengikuti Spec Spec: RFC 6960, §3.2 RFC 6960 §3.2 : sebelum sebuah klien menerima respons pencabutan yang ditandatangani sebagai valid, klien itu HARUS memastikan bahwa tanda tangan respons itu sendiri valid dan bahwa penanda tangan saat ini berwenang — dan Spec Spec: RFC 6960, §4.2.2.2 RFC 6960 §4.2.2.2 mendefinisikan kewenangan tersebut sebagai delegasi id-kp-OCSPSigning yang diterbitkan langsung oleh CA yang bersangkutan. Jadi, jawaban pencabutan yang belum divalidasi terhadap penanda tangan yang berwenang dan dapat diverifikasi adalah tidak berarti. Pemeriksaan certificate-binding mengikuti Spec Spec: RFC 5035, §5.4.2 RFC 5035 §5.4.2 : jika hash sertifikat dalam atribut signing-certificate-v2 yang ditandatangani tidak cocok dengan sertifikat yang digunakan untuk memverifikasi tanda tangan, tanda tangan harus dianggap tidak valid. Hal ini menutup celah substitusi, ketika sebuah tanda tangan terverifikasi terhadap sertifikat yang dipilih oleh penyerang. Token timestamp itu sendiri diverifikasi dengan gaya Spec Spec: RFC 5652 RFC 5652 sebagai objek CMS, langkah demi langkah, dengan setiap langkah diuji secara tersendiri.

Human-factors note: Human-factors note

Pesan utama — “valid” saja tidak lengkap; jawaban yang benar adalah lima jawaban yang terpisah — dinyatakan sebelum daftar pemeriksaan, karena kesalahan yang paling umum dan paling mahal adalah bertindak berdasarkan satu nilai boolean tunggal. Pembaca yang menyerap hanya kalimat itu pun sudah diperingatkan terhadap jebakan tersebut, itulah sebabnya kalimat itu muncul sebelum mekanismenya alih-alih setelahnya.

Contoh praktis

Bagian yang instruktif bukanlah sebuah panggilan API. Bagian itu adalah pertanyaan yang harus dapat Anda jawab sebelum Anda bertindak berdasarkan suatu hasil. Perlakukan ini sebagai daftar periksa yang akan menjadi acuan penilaian dalam suatu peninjauan.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Jika ada baris yang berbunyi “saya tidak tahu,” status yang jujur bukanlah “valid.” Statusnya adalah “belum dapat ditentukan” — dan memperlakukan keduanya sebagai hal yang sama adalah kekeliruan yang ingin dicegah oleh halaman ini.

Kesalahpahaman yang umum

Jebakannya adalah menyamakan “valid secara kriptografis” dengan “dapat dipercaya.” Integritas dan keaslian secara bersama-sama hanya membuktikan byte ini ditandatangani oleh pemegang kunci ini. Keduanya tidak mengatakan apa pun tentang apakah sertifikat kunci itu tepercaya, masih berlaku, atau belum dicabut. Sebuah dokumen yang ditandatangani dengan sertifikat yang dibuat sendiri bisa saja “valid secara kriptografis” namun tidak bernilai apa pun. Jebakan sebaliknya adalah memperlakukan pemeriksaan pencabutan yang tidak dapat ditentukan (responder offline) sebagai lolos — atau sebagai gagal. Statusnya bukan keduanya. Statusnya tidak diketahui, dan validator yang benar melaporkannya sebagai tidak diketahui alih-alih menebak ke salah satu arah. Tanda centang hijau yang menyembunyikan pemeriksaan mana saja di antara kelima pemeriksaan itu yang sebenarnya dijalankan bukanlah sebuah hasil validasi. Itu adalah keputusan yang dibuat oleh orang lain atas nama Anda.

Batasan dan ruang lingkup

NextPDF melakukan dan menguji pemeriksaan struktural dan kriptografis. NextPDF tidak memilih trust anchor Anda atau menjamin kebijakan yang dibangun di atasnya. Sertifikat mana yang Anda percayai adalah keputusan penerapan yang tidak dapat dibuat oleh mesin. Rantai yang tervalidasi ke anchor yang seharusnya tidak Anda percayai tetaplah validasi yang tidak dapat Anda andalkan. Bukti pencabutan hanya dapat diperiksa jika bukti tersebut dapat diperoleh atau tertanam. Responder yang offline menghasilkan “tidak dapat ditentukan,” dan mengubahnya menjadi sebuah keputusan adalah pilihan kebijakan, bukan pilihan mesin. Halaman ini menjelaskan jaringan pemeriksaan, bukan kecukupan hukum. Apakah tanda tangan yang tervalidasi memiliki efek hukum tertentu bergantung pada sertifikat, penanda tangan, yurisdiksi, dan kewajibannya. Bagaimana bukti yang tertanam menjaga agar pemeriksaan-pemeriksaan ini tetap dapat dijawab seiring waktu dibahas dalam Validasi jangka panjang; mekanisme byte-range di balik pemeriksaan integritas dibahas dalam Bagaimana tanda tangan tersimpan dalam PDF.

Ketersediaan tingkatan untuk permukaan validasi:

Signature validation checks — edition availability

Edition	Availability
Core	○ Integritas dan keaslian atas signed attributes, ditambah RFC 5280 §6 validasi jalur sertifikat terhadap trust anchor yang disediakan.
Pro	○ Menambahkan verifikasi token timestamp RFC 3161 — pertanyaan trusted-time, yang diuraikan menjadi langkah-langkah yang diperiksa secara independen.
Enterprise	○ Menambahkan evaluasi pencabutan (OCSP/CRL) dan validasi terhadap material jangka panjang yang tertanam, dengan hasil yang tidak dapat ditentukan dibedakan dari hasil yang definitif.

Dokumen terkait

• Validasi jangka panjang — bagaimana bukti yang tertanam menjaga agar pemeriksaan waktu dan pencabutan tetap dapat dijawab bertahun-tahun kemudian.
• Bagaimana tanda tangan tersimpan dalam PDF — mekanisme byte-range yang dihitung ulang oleh pemeriksaan integritas.
• Timestamp dan waktu tepercaya — apa yang membuat pertanyaan “waktu” dapat dijawab dengan sesuatu selain jam milik penanda tangan.

Glosarium

• Pemeriksaan integritas — menghitung ulang digest byte-range dan membandingkannya dengan nilai yang dicakup oleh tanda tangan.
• Pemeriksaan keaslian — memverifikasi tanda tangan kriptografis terhadap kunci publik dalam sertifikat penanda tangan, atas signed attributes.
• Signed attributes — atribut CMS terautentikasi (content-type, message-digest, signing-time, signing-certificate-v2) yang menjadi dasar penghitungan tanda tangan yang sebenarnya.
• Validasi jalur sertifikat — membangun dan memeriksa rantai dari sertifikat penanda tangan ke trust anchor yang dipilih (RFC 5280 §6).
• Trust anchor — otoritas sertifikat yang telah Anda putuskan untuk dipercaya; akar dari jalur yang dapat diterima.
• Pemeriksaan pencabutan — menentukan apakah suatu sertifikat dicabut pada waktu yang relevan, melalui OCSP atau CRL.
• Tidak dapat ditentukan — hasil pencabutan yang bukan “baik” maupun “dicabut” karena buktinya tidak dapat diperoleh; bukan lolos dan bukan gagal.