<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>PKI on Nalar</title>
    <link>https://nalar.dev/id/tags/pki/</link>
    <description>Recent content in PKI on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/pki/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik</title>
      <link>https://nalar.dev/id/certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik/</guid>
      <description>&lt;h1 id=&#34;certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik&#34;&gt;Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik&lt;/h1&gt;&#xA;&lt;p&gt;Certificate authority yang dipercaya publik dapat menerbitkan sertifikat yang secara sintaksis valid untuk sebuah domain meskipun penerbitan itu seharusnya tidak pernah terjadi. Validasi TLS path saja tidak dapat mengungkap kesalahan tersebut jika sertifikat berantai ke root tepercaya, cocok dengan nama yang diminta, masih dalam masa berlaku, dan memenuhi pemeriksaan kebijakan client lainnya.&lt;/p&gt;&#xA;&lt;p&gt;Certificate Transparency mengubah bukti yang tersedia di sekitar peristiwa itu. Alih-alih hanya mengandalkan catatan privat CA dan pengungkapan insiden di kemudian hari, ekosistem dapat mewajibkan penerbitan sertifikat meninggalkan bukti yang dapat diverifikasi secara kriptografis dalam log append-only publik. Log tidak memutuskan apakah sebuah sertifikat diotorisasi. Log membuat penerbitan dapat diamati dan membuat bentuk tertentu dari equivocation log dapat dideteksi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake</title>
      <link>https://nalar.dev/id/tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake/</guid>
      <description>&lt;h1 id=&#34;tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake&#34;&gt;TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake&lt;/h1&gt;&#xA;&lt;p&gt;Server TLS dapat memiliki private key yang valid dan menyajikan sertifikat yang membentuk chain ke root tepercaya, tetapi bukti status revokasinya tidak tersedia. OCSP stapling biasa tidak selalu mengubah kondisi tersebut menjadi kegagalan: client dapat meminta informasi status, tetapi dalam protokol stapling dasar server masih diperbolehkan tidak mengirim respons.&lt;/p&gt;&#xA;&lt;p&gt;Sifat opsional ini menciptakan batas keamanan. Intermediary aktif yang mampu menghalangi akses ke OCSP responder dapat memanfaatkan kebijakan client yang menerima pemeriksaan revokasi yang tidak konklusif. Ekstensi TLS Feature dari RFC 7633 mengubah sertifikat itu sendiri sehingga fitur TLS tertentu menjadi syarat penggunaan yang dapat diterima. Untuk OCSP stapling, sertifikat dapat menyatakan bahwa client yang patuh harus menerima bukti status yang diminta.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
