Sertifikat yang dipercaya secara publik dapat valid secara sintaksis, memiliki tanda tangan yang benar, tetapi tetap tidak diharapkan. Otoritas sertifikat dapat menerbitkannya untuk subjek yang keliru, sebuah akun dapat dikompromikan, atau proses otorisasi dapat gagal. Certificate Transparency (CT) menambahkan visibilitas publik pada penerbitan sertifikat agar sertifikat semacam itu tidak harus tetap tersembunyi dari operator domain yang terdampak.

RFC 9162 menetapkan Certificate Transparency Version 2.0. Mekanisme utamanya adalah log publik append-only yang ditopang Merkle tree. Otoritas sertifikat dan pengirim lain dapat mengirim sertifikat atau precertificate ke log, sedangkan monitor dapat memeriksa entri untuk sertifikat yang berkaitan dengan domain yang mereka pantau.

CT tidak menentukan apakah suatu penerbitan telah diotorisasi. CT membuat penerbitan terlihat dan menyediakan struktur kriptografis untuk mengaudit perilaku log.

SCT adalah komitmen dari log

Ketika log CT menerima pengiriman sertifikat atau precertificate yang valid, log mengembalikan Signed Certificate Timestamp (SCT). SCT ditandatangani oleh log dan mengikat log untuk memasukkan entri terkait ke Merkle tree dalam Maximum Merge Delay (MMD) milik log tersebut.

Perbedaan ini penting. SCT bukan bukti bahwa entri sudah berada dalam suatu keadaan tree tertentu. SCT adalah komitmen bertanda tangan bahwa pengiriman yang diterima akan dimasukkan dalam batas waktu yang dinyatakan.

Alur sederhananya:

sertifikat / precertificate
            |
            v
         CT log
            |
            +----> SCT
            |
            v
    Merkle tree append-only

Klien dapat memverifikasi SCT memakai parameter log yang relevan. Monitor dan auditor kemudian dapat memeriksa apakah entri yang dijanjikan muncul di log.

Merkle tree membuat riwayat log dapat diaudit

Log CT disusun sebagai Merkle tree biner. Hash leaf mengikat masing-masing entri log, sedangkan hash internal menggabungkan node anak hingga satu root hash mengikat keadaan tree.

Struktur ini mendukung dua jenis bukti yang berbeda.

Inclusion proof menunjukkan bahwa leaf tertentu merupakan bagian dari tree yang direpresentasikan oleh root hash tertentu. Verifikator menggabungkan hash leaf dengan node pada jalur bukti, lalu memeriksa apakah root hasil perhitungan sama dengan root yang diharapkan.

Consistency proof menghubungkan keadaan tree lama dengan keadaan yang lebih baru. Bukti ini memungkinkan verifikator memeriksa bahwa tree lama merupakan prefix dari tree baru, bukan riwayat yang telah ditulis ulang.

Ukuran bukti tersebut ringkas dibandingkan mengunduh setiap entri hanya untuk memverifikasi satu inclusion atau satu transisi antar-keadaan tree.

Signed Tree Head mengikat keadaan log

Log CT secara berkala menandatangani informasi yang menggambarkan Merkle tree saat ini. Dalam RFC 9162, Signed Tree Head (STH) mencakup identitas log, ukuran tree, root hash, timestamp, dan tanda tangan log atas data tree head.

Ukuran tree dan root hash mengidentifikasi keadaan tertentu dari struktur append-only. STH yang lebih baru dapat diperiksa terhadap keadaan sebelumnya dengan consistency proof.

Hal ini tidak membuat log mustahil berperilaku buruk. Log yang tidak jujur dapat mencoba menyajikan tampilan yang tidak konsisten kepada pihak berbeda. RFC 9162 secara eksplisit menempatkan split view sebagai persoalan yang perlu diperhatikan. Karena itu, membandingkan keadaan tree yang diamati dan mengaudit konsistensinya merupakan pekerjaan terpisah dari sekadar memverifikasi satu tanda tangan log yang valid.

Monitoring menargetkan penerbitan yang tidak diharapkan

Log publik berguna karena operator domain dan monitor independen dapat mencari entri sertifikat yang terkait dengan nama yang mereka awasi. Sertifikat yang tidak diharapkan kemudian dapat memicu investigasi dan proses remediasi yang sudah ada, misalnya bekerja dengan CA penerbit untuk melakukan pencabutan.

Log tidak memberi label bahwa sebuah sertifikat sah atau berbahaya. Log mencatat pengiriman yang diterima dan membukanya untuk pemeriksaan. Keputusan otorisasi tetap berada di luar log CT.

Batas ini menjaga CT tetap berfokus pada transparansi, bukan penegakan kebijakan. Visibilitas dapat menampilkan penerbitan yang memerlukan perhatian, tetapi proses PKI di sekitarnya yang menentukan tindakan berikutnya.

Inclusion dan consistency menjawab pertanyaan berbeda

Semua Merkle proof mudah dianggap setara, padahal pernyataan keamanannya berbeda.

Inclusion proof menjawab apakah entri tertentu terikat pada root tree tertentu. Consistency proof menjawab apakah tree yang lebih baru memperluas tree lama tanpa mengubah prefix lama.

Kedua bukti tersebut, jika berdiri sendiri, tidak menetapkan bahwa sertifikat memang semestinya diterbitkan. Demikian pula, SCT hanya menetapkan komitmen bertanda tangan dari log sesuai aturan protokol; SCT tidak mengesahkan otorisasi di balik sertifikat.

Pemisahan pernyataan ini mencegah pemberian jaminan kepada CT yang sebenarnya berasal dari validasi sertifikat, kebijakan CA, atau pemeriksaan kontrol domain.

Transparansi melengkapi validasi sertifikat

Validasi sertifikat biasa dan CT menangani permukaan kegagalan yang berbeda. Validasi jalur memeriksa properti seperti tanda tangan, trust anchor, nama, dan batas validitas. CT menyediakan catatan publik serta mekanisme audit di sekitar penerbitan.

Kombinasi tersebut berguna karena sertifikat dapat lolos validasi kriptografis biasa tetapi tetap tidak diharapkan secara operasional. CT memberi pihak yang terdampak tempat untuk mengamati penerbitan dan alat kriptografis untuk memeriksa riwayat append-only milik log.

Hasilnya bukan pencegahan setiap penerbitan yang buruk. CT menyediakan lapisan publikasi yang dapat diverifikasi, membuat aktivitas sertifikat publik lebih mudah dipantau, dan menempatkan komitmen historis log di bawah audit kriptografis.

Cybersecurity PKI Certificate Transparency TLS Certificates