Sertifikat TLS dapat lolos validasi chain biasa dan tetap perlu diawasi secara publik. Certificate Transparency (CT) menambahkan visibilitas tersebut dengan menempatkan sertifikat atau precertificate pada log publik yang dirancang untuk audit. Model keamanannya lebih presisi daripada sekadar pernyataan bahwa sertifikat sudah dicatat: CT memisahkan janji bertanda tangan dari log dengan bukti berikutnya bahwa entri yang dijanjikan benar-benar masuk ke Merkle tree milik log.
RFC 9162 mendeskripsikan CT versi 2.0. Log yang sesuai merupakan Merkle tree append-only. Saat menerima pengajuan sertifikat atau precertificate, log mengembalikan Signed Certificate Timestamp (SCT). SCT adalah komitmen bertanda tangan yang terkait dengan pengajuan yang diterima dan sebuah timestamp. SCT sendiri bukan Merkle inclusion proof.
SCT adalah komitmen dengan batas waktu
Setelah menerbitkan SCT, log wajib memasukkan entri terkait dalam Maximum Merge Delay (MMD). MMD merupakan parameter log, sehingga janji tersebut memiliki rentang waktu yang terbatas dan bukan tanggal masa depan yang tidak ditentukan.
Perbedaan ini penting saat verifikasi. SCT dapat diperiksa secara kriptografis terhadap kunci log dan material sertifikat yang terkait, tetapi validasi SCT yang berhasil hanya menetapkan bahwa log menandatangani komitmen tersebut. Hasil itu belum menetapkan bahwa tree tertentu yang terbit kemudian memuat entri tersebut.
Klien atau monitor dapat mengaudit properti kedua setelah waktu yang memadai berlalu. Jika log tidak dapat menyediakan bukti bahwa entri dimasukkan sesuai janji, SCT bertanda tangan menjadi bukti yang terkait dengan kegagalan log memenuhi komitmennya.
CT dengan demikian menghasilkan dua pertanyaan terpisah:
- Apakah log yang disebut menerbitkan SCT valid untuk sertifikat atau precertificate ini?
- Apakah entri yang dijanjikan muncul pada authenticated tree berikutnya dalam interval yang diwajibkan?
Menyamakan kedua pemeriksaan tersebut menghilangkan bagian penting dari model akuntabilitas protokol.
Inclusion proof menghubungkan entri ke root tree
Merkle inclusion proof menunjukkan bahwa entri tertentu berkontribusi pada root Merkle tree tertentu. Bukti memuat sibling hash yang diperlukan untuk menghitung kembali jalur dari leaf terpilih menuju root. Verifier menggabungkan hash entri dengan jalur tersebut lalu membandingkan root yang dihasilkan dengan state tree yang telah diautentikasi.
Pada CT v2, state tree yang relevan direpresentasikan oleh Signed Tree Head (STH). STH mengikat ukuran tree dan root hash ke tanda tangan log. Inclusion proof hanya memiliki nilai keamanan jika dikaitkan dengan state tree terautentikasi yang benar; root arbitrer yang diberikan tanpa autentikasi log yang diharapkan tidak memadai.
Hasilnya adalah pernyataan konkret bagi verifier: entri sertifikat atau precertificate yang dipilih tercakup dalam tree yang direpresentasikan oleh STH tersebut.
Buktinya ringkas karena verifier tidak perlu memperoleh seluruh entri log lain untuk memeriksa keanggotaan. Struktur Merkle tree mengurangi bukti menjadi jalur hash berukuran logaritmik terhadap ukuran tree.
Consistency proof menjaga riwayat append-only
Inklusi menjawab pertanyaan keanggotaan pada satu state tree. Pemeriksaan itu tidak menetapkan bahwa log mempertahankan riwayat lama saat tree bertambah.
CT memakai Merkle consistency proof untuk pemeriksaan terpisah tersebut. Dengan tree lama dan tree baru, consistency proof yang valid menunjukkan bahwa tree baru memperluas tree lama tanpa mengubah atau menghapus entri lama. Monitor dapat membandingkan state tree terautentikasi dari waktu ke waktu, bukan mempercayai klaim log bahwa riwayatnya append-only.
Pemisahan antara inclusion dan consistency penting secara operasional. Sebuah log dapat menempatkan entri pada satu tampilan tree tetapi tetap berperilaku salah dengan menyajikan riwayat yang saling tidak kompatibel. Pemeriksaan inklusi dan konsistensi mencakup mode kegagalan yang berbeda.
RFC 9162 juga mencatat masalah yang lebih sulit: log yang tidak jujur dapat menyajikan tampilan berbeda kepada pihak yang berbeda. Perbandingan observasi antarklien atau monitor independen relevan untuk mendeteksi perilaku semacam itu. Struktur data inti CT membuat state bertanda tangan yang saling bertentangan berguna sebagai bukti, tetapi verifier yang sepenuhnya terisolasi dari pengamat lain tidak otomatis mendeteksi setiap strategi split-view.
CT membuka visibilitas penerbitan, bukan memberi persetujuan
Log publik mencatat material sertifikat yang diterima. Log tidak menentukan bahwa sertifikat memang diminta secara sah oleh pemilik domain, dan inklusi tidak mengubah sertifikat yang salah terbit menjadi sertifikat yang terotorisasi.
Properti ini merupakan bagian inti CT. Visibilitas memungkinkan monitor memeriksa entri baru dan menandai sertifikat yang terkait dengan domain yang diawasi. Tindakan korektif tetap berada di luar mekanisme logging: operator domain mungkin perlu berkoordinasi dengan certification authority, konsumen sertifikat, atau peserta PKI lain setelah penerbitan mencurigakan terdeteksi.
Validasi sertifikat normal juga tetap terpisah. RFC 9162 secara eksplisit memisahkan validasi SCT dari validasi sertifikat server dan chain-nya. SCT yang valid tidak memperbaiki sertifikat kedaluwarsa, hostname yang tidak cocok, chain yang tidak dipercaya, atau kegagalan lain pada validasi sertifikat biasa.
CT menambahkan kemampuan audit pada PKI; CT bukan pengganti validasi PKI.
Pengiriman dan audit memakai jalur berbeda
Informasi CT dapat mencapai klien TLS melalui mekanisme protokol yang terkait dengan sertifikat atau handshake. Protokol juga mengizinkan pengambilan bukti inklusi dari log pada waktu berikutnya.
Pengambilan langsung memiliki biaya privasi. Jika klien TLS meminta inclusion proof kepada log untuk sertifikat yang baru ditemuinya, permintaan tersebut dapat mengungkap server yang dihubungi klien. RFC 9162 karena itu mencatat manfaat privasi ketika server TLS menyediakan inclusion proof, alih-alih mewajibkan setiap klien melakukan kueri langsung ke log.
Tradeoff tersebut menegaskan satu aspek deployment: verifikasi kriptografis tidak menghapus paparan metadata. Sumber material bukti dan waktu pengambilannya tetap menjadi bagian dari desain privasi.
Batas yang berguna adalah akuntabilitas
Certificate Transparency tidak menjanjikan bahwa setiap sertifikat yang tercatat bersifat sah, dan SCT saja bukan bukti inklusi final. Kekuatannya berasal dari rangkaian pernyataan yang dapat diperiksa secara independen.
SCT merekam janji bertanda tangan dari log. Inclusion proof mengikat entri yang dijanjikan ke authenticated tree. Consistency proof mengikat state tree yang berurutan menjadi riwayat append-only. Monitoring membuat penerbitan tak terduga terlihat, sementara validasi sertifikat TLS biasa tetap menegakkan aturannya sendiri.
Pemisahan peran tersebut membuat batas keamanan CT eksplisit: sistem mengubah penerbitan sertifikat dan perilaku log menjadi peristiwa publik yang dapat diaudit secara kriptografis tanpa memperlakukan transparansi sebagai otorisasi.