In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker could exploit such a compromised or misissued certificate until expiry. Hence, revocation is an important part of a public key infrastructure. Revocation is performed by the issuing certificate authority, which produces a cryptographically authenticated statement of revocation.

For distributing revocation information to clients, the timeliness of the discovery of revocation (and hence the window for an attacker to exploit a compromised certificate) trades off against resource usage in querying revocation statuses and privacy concerns. If revocation information is unavailable (either due to an accident or an attack), clients must decide whether to fail-hard and treat a certificate as if it is revoked (and so degrade availability) or to fail-soft and treat it as unrevoked (and allow attackers to sidestep revocation).

Due to the cost of revocation checks and the availability impact from potentially-unreliable remote services, Web browsers limit the revocation checks they will perform, and will fail soft where they do. Certificate revocation lists are too bandwidth-costly for routine use, and the Online Certificate Status Protocol presents connection latency and privacy issues. Other schemes have been proposed but have not yet been successfully deployed to enable fail-hard checking.

ACME

Automatic Certificate Management Environment

CA

certificate authority

CA/B

CA/Browser Forum

CRL

certificate revocation list

CRV

certificate revocation vector

OCSP

Online Certificate Status Protocol

PKI

public key infrastructure

TLS

Transport Layer Security

The Heartbleed vulnerability, which was disclosed in 2014, triggered a mass revocation of certificates, as their private keys may have been leaked. GlobalSign revoked over 50% of their issued certificates. StartCom was criticised for issuing free certificates but then charging for revocation.^[1]

A 2015 study found an overall revocation rate of 8% for certificates used on the Web,^[2] though this may have been elevated due to Heartbleed.^[3]

แม้ว่าความปลอดภัยของเว็บจะเป็นสิ่งสำคัญสำหรับเบราว์เซอร์ ส่วนใหญ่ แต่เนื่องจากความหน่วงและความต้องการแบนด์วิดท์ที่เกี่ยวข้องกับ OCSP และ CRL เบราว์เซอร์จึงจำกัดการตรวจสอบสถานะใบรับรอง^{[ 4 ]}ในปี 2015 Google Chromeตรวจสอบเฉพาะ ใบรับรอง Extended Validation เท่านั้น เบราว์เซอร์บนมือถือไม่ได้ทำการตรวจสอบความถูกต้อง และไม่มีเบราว์เซอร์ใดตรวจสอบใบรับรองทั้งหมดอย่างสมบูรณ์^{[ 5 ]} Chrome และ Firefox ทำการตรวจสอบแบบพุชสำหรับโดเมนจำนวนเล็กน้อยที่ถือว่ามีความสำคัญ^{[ 6 ]} Chrome เรียกสิ่งเหล่านี้ว่าCRLsetsและในปี 2025 ครอบคลุมการเพิกถอนประมาณ 1% โดยมีค่าใช้จ่ายในการดาวน์โหลดรายวัน 600 kB ^{[ 7 ]}เบราว์เซอร์มีความเห็นไม่ตรงกันในกรณีพิเศษเกี่ยวกับความถูกต้องของใบรับรอง ซึ่งอาจทำให้ผู้ใช้ที่มีประสบการณ์สับสนได้^{[ 8 ]}

จำนวนใบรับรองในWeb PKIเพิ่มขึ้นอย่างมหาศาลในช่วงปลายทศวรรษ 2010 จาก 30 ล้านใบในเดือนมกราคม 2017 เป็น 434 ล้านใบในเดือนมกราคม 2020 ปัจจัยสำคัญในการเติบโตนี้คือLet's Encrypt ที่ให้ ใบรับรองที่ตรวจสอบโดเมนได้ฟรีขนาดของชุดใบรับรองที่อาจถูกเพิกถอนได้นั้นกำหนดข้อกำหนดเกี่ยวกับความสามารถในการปรับขนาดของกลไกการเพิกถอน^{[ 4 ]}

Chuat et al. (2020)เรียกการเพิกถอนว่า "เป็นเรื่องที่ท้าทายอย่างมาก" ^{[ 9 ]}ในปี 2022 RFC 9325 ระบุว่าการเพิกถอนใบรับรองเป็นปัญหาสำคัญที่มี "วิธีแก้ปัญหาที่สมบูรณ์และมีประสิทธิภาพ" แนะนำให้ใช้ OCSP และ OCSP stapling เป็น "พื้นฐานสำหรับวิธีแก้ปัญหาที่เป็นไปได้" ^{[ 10 ]}

Firefox ได้นำ CRLite มาใช้กับผู้ใช้เดสก์ท็อปทั้งหมดในปี 2025 นี่เป็นการนำการตรวจสอบการเพิกถอนการปกป้องความเป็นส่วนตัวที่ครอบคลุมมาใช้ในเว็บเบราว์เซอร์เป็นครั้งแรก^{[ 7 ]}

การเพิกถอนใบรับรองถือเป็น "เครื่องมือสำคัญ" ในการจัดการกับการโจมตีและการรั่วไหลโดยไม่ได้ตั้งใจ RFC 9325 กำหนดข้อกำหนดเชิงบรรทัดฐานสำหรับการใช้งาน TLS ให้มีวิธีการบางอย่างในการไม่เชื่อถือใบรับรอง^{[ 10 ]}หากไม่มีการเพิกถอน ผู้โจมตีสามารถใช้ใบรับรองที่ถูกบุกรุกเพื่อปลอมตัวเป็นเจ้าของจนกว่าจะหมดอายุ^{[ 4 ]}

การเพิกถอนอาจไม่จำเป็นสำหรับใบรับรองที่มีอายุสั้นพอสมควร โดยประมาณอยู่ในช่วงไม่กี่ชั่วโมงถึงไม่กี่วัน ซึ่งเทียบได้กับอายุการตอบสนองของ OCSP การออกใบรับรองบ่อยครั้งที่เกี่ยวข้องมักต้องใช้ระบบอัตโนมัติ (เช่น โปรโตคอล ACME) และอาจสร้างภาระให้กับองค์ประกอบโครงสร้างพื้นฐานอื่นๆ (เช่น บันทึกความโปร่งใส) ^{[ 11 ]}ใบรับรองที่มีอายุสั้นยังก่อให้เกิดความซับซ้อนในการกลับมาเชื่อมต่อ TLS อีกครั้ง แม้ว่าจะไม่จำเป็นต้องแก้ไขไม่ได้ก็ตาม^{[ 12 ]}

การเพิกถอนอาจเริ่มต้นโดยผู้ถือใบรับรอง (เช่น อาจทราบว่าคีย์ส่วนตัวถูกบุกรุก) ซึ่งแจ้งให้ CA ทราบ จากนั้น CA จะสร้างและแจกจ่ายการรับรองที่ได้รับการตรวจสอบความถูกต้องทางคริปโตกราฟีว่าใบรับรองได้ถูกเพิกถอนแล้ว^{[ 13 ]}ข้อกำหนด CA/B ยังอนุญาตให้ CA เพิกถอนใบรับรองได้เองหาก CA ทราบถึงความเป็นไปได้ของการบุกรุก^{[ 14 ]}ใครก็ได้สามารถส่งหลักฐานดังกล่าวได้^{[ 15 ]}

สถานะการเพิกถอนมักจะไม่ได้รับการเก็บรักษาและจัดเก็บไว้นานเกินกว่าวันหมดอายุของใบรับรอง ทำให้การวิจัยและการตรวจสอบพฤติกรรมการเพิกถอนทำได้ยาก^{[ 16 ]}ข้อเสนอหนึ่งในการแก้ปัญหานี้คือการส่ง 'ใบรับรองหลังการเพิกถอน' ไปยังบันทึก Certificate Transparency สำหรับการเพิกถอนแต่ละครั้ง ซึ่งจะช่วยให้สามารถดำเนินการเพิกถอนได้โดยไม่ต้องมีการดำเนินการใดๆ จาก CA ^{[ 17 ]}ข้อเสนอทางเลือกอีกข้อหนึ่งซึ่งอิงตาม Certificate Transparency เช่นกัน คือการส่ง CRV ไปยังบันทึก CT โดย CA ^{[ 18 ]}

หากสถานะการเพิกถอนไม่พร้อมใช้งาน (ซึ่งอาจเป็นไปโดยเจตนาหรือเกิดจากการโจมตี) ลูกค้าจะเผชิญกับภาวะกลืนไม่เข้าคายไม่ออกเมื่อประเมินใบรับรอง: อาจล้มเหลวแบบอ่อนและถือว่าใบรับรองยังคงใช้งานได้ หรืออาจล้มเหลวแบบรุนแรงและถือว่าใบรับรองถูกเพิกถอน นี่เป็นการแลกเปลี่ยนระหว่างความปลอดภัยและความพร้อมใช้งาน: การล้มเหลวแบบอ่อนจะทำให้เกิดการโจมตีแบบลดระดับในขณะที่การล้มเหลวแบบรุนแรงจะทำให้ เกิด การปฏิเสธการให้บริการ (จากการโจมตี) หรือทำให้ไม่สามารถใช้งานได้^{[ 19 ]}

ผู้โจมตีที่มีความสามารถในการนำเสนอใบรับรองที่ถูกบุกรุกมีแนวโน้มที่จะสามารถป้องกันไม่ให้ไคลเอนต์ทำการตรวจสอบสถานะการเพิกถอนทางออนไลน์ได้ ในกรณีนี้ การทำงานแบบ fail-soft จะไม่มีการป้องกันใดๆ เลย เบราว์เซอร์ได้เลือกด้านนี้ของปัญหาและเลือกความพร้อมใช้งานมากกว่าความปลอดภัย^{[ 20 ]}

การล้มเหลวอย่างรุนแรงอาจนำไปสู่ช่องทางการโจมตีแบบปฏิเสธการให้บริการแบบใหม่ ตัวอย่างเช่น หากไคลเอ็นต์คาดหวัง OCSP stapling และล้มเหลวอย่างรุนแรงในกรณีอื่น การปฏิเสธการให้บริการต่อผู้ตอบสนอง OCSP จะถูกขยายไปสู่การปฏิเสธการให้บริการต่อบริการทั้งหมดที่ต้องการใช้การตอบสนอง OCSP เหล่านั้น^{[ 11 ]}

มีสองสถานการณ์สำหรับการประเมินการใช้ทรัพยากร ได้แก่ สภาวะปกติ และเหตุการณ์การเพิกถอนจำนวนมาก แผนการเพิกถอนควรมีประสิทธิภาพภายใต้สภาวะปกติ และใช้งานได้ในระหว่างเหตุการณ์การเพิกถอนจำนวนมาก^{[ 4 ]}

การเรียกข้อมูลการเพิกถอนทำให้เกิดค่าใช้จ่ายด้านแบนด์วิดท์และเวลาแฝงสำหรับลูกค้า^{[ 21 ]}

ในระหว่าง เหตุการณ์ Heartbleedครั้งใหญ่ในปี 2014 ซึ่งอัตราการเพิกถอนเพิ่มขึ้นจาก 1% เป็น 11% Cloudflareประเมินว่าแบนด์วิดท์ที่GlobalSignใช้ในการแจกจ่าย CRL อาจมีค่าใช้จ่าย 400,000 ดอลลาร์สหรัฐ (เทียบเท่ากับ 540,000 ดอลลาร์สหรัฐในปี 2025 ^{[ 22 ]} ) ^{[ 23 ]}

หากสถานะการเพิกถอนไม่ได้รับการดึงข้อมูลใหม่ทุกครั้งที่ตรวจสอบ (เช่น เนื่องจากการแคชหรือการดึงข้อมูลเป็นระยะ) จะเกิดความล่าช้าระหว่างการเพิกถอนใบรับรองและการรับประกันว่าไคลเอนต์ทั้งหมดจะรับทราบการเพิกถอน ซึ่งทำให้เกิดการแลกเปลี่ยนระหว่างความหน่วง ประสิทธิภาพ และความปลอดภัย: เวลาแคชที่นานขึ้นหรือการอัปเดตที่น้อยลงจะใช้ทรัพยากรน้อยลงและลดความหน่วง แต่หมายความว่าใบรับรองที่ถูกบุกรุกสามารถถูกนำไปใช้ในทางที่ผิดได้นานขึ้น^{[ 24 ]}

ลูกค้าที่ทำการตรวจสอบแบบดึงข้อมูลอาจทำให้ข้อมูลการท่องเว็บของผู้ใช้รั่วไหลไปยังบุคคลที่สาม ซึ่งก็คือผู้จัดจำหน่ายข้อมูลการเพิกถอน^{[ 25 ]}

เป็นที่พึงปรารถนาที่จะหลีกเลี่ยงการสร้างบุคคลที่สามที่เชื่อถือได้ใน PKI หากผู้กระทำการภายในโครงการสามารถตรวจสอบได้ลูกค้า (หรือตัวแทนที่ทำหน้าที่แทนลูกค้า) สามารถตรวจสอบได้อย่างพิสูจน์ได้ว่าผู้กระทำการนั้นประพฤติตนอย่างถูกต้อง^{[ 26 ]}

การกระจายสถานะการเพิกถอนที่สร้างภาระหนักให้กับ CA อาจไม่ประสบความสำเร็จ โดยเฉพาะอย่างยิ่งหาก CA ไม่สามารถได้รับผลประโยชน์ที่ชดเชยจากการดำเนินการ การลดจำนวนฝ่ายที่ต้องทำการเปลี่ยนแปลงเพื่อนำไปใช้ยังช่วยให้การใช้งานง่ายขึ้นด้วย โดยอาจเกี่ยวข้องกับ CA ลูกค้า ผู้ดูแลระบบเซิร์ฟเวอร์ และผู้ผลิตซอฟต์แวร์เซิร์ฟเวอร์ความเข้ากันได้ในอนาคตเป็นดาบสองคม กล่าวคือ ลูกค้าและเซิร์ฟเวอร์เก่าจะไม่ถูกรบกวนจากระบบใหม่ แต่ผู้ใช้อาจไม่รู้ตัวว่าพวกเขากำลังพลาดประโยชน์ของการเพิกถอน^{[ 27 ]}

มีสถาปัตยกรรมหลักสามแบบสำหรับวิธีที่ไคลเอ็นต์เข้าถึงสถานะการเพิกถอน ได้แก่แบบดึง (pull-based)ซึ่งไคลเอ็นต์จะดึงสถานะการเพิกถอนในเวลาตรวจสอบความถูกต้องแบบผลัก (push-based)ซึ่งไคลเอ็นต์จะดึงสถานะการเพิกถอนก่อนการตรวจสอบความถูกต้องและแคชไว้ และแบบ ช่วยเหลือโดย เครือข่าย (network-assisted ) ซึ่งการตรวจสอบการเพิกถอนจะถูกรวมเข้ากับโปรโตคอล TLS อย่างแน่นหนา และอาจไม่จำเป็นต้องมีการตรวจสอบแยกต่างหาก^{[ 28 ]}

การตรวจสอบแบบดึงข้อมูลมักมีปัญหาเรื่องความล่าช้าและความพร้อมใช้งาน ลูกค้าที่ทำการตรวจสอบแบบดึงข้อมูลมักจะแคชการตอบกลับไว้ในช่วงเวลาสั้นๆ การตรวจสอบแบบดึงข้อมูลอย่างเดียวร่วมกับ failing-soft ไม่ได้เพิ่มความปลอดภัย^{[ 29 ]}

การตรวจสอบแบบพุชมีประสิทธิภาพแบนด์วิดท์น้อยกว่าการตรวจสอบแบบพูล แต่ได้ความพร้อมใช้งานและความเป็นส่วนตัวเพิ่มขึ้น สามารถใช้วิธีการที่แตกต่างกันได้ในแต่ละใบรับรอง ทำให้สามารถปรับแต่งการแลกเปลี่ยนได้อย่างละเอียด: ทั้งGoogle ChromeและMozilla Firefoxทำการตรวจสอบแบบพุชกับชุดใบรับรองที่สำคัญจำนวนเล็กน้อย^{[ 29 ]}

รายการเพิกถอนใบรับรอง (CRL) จะแสดงรายการใบรับรองที่ถูกเพิกถอน ใบรับรองเหล่านี้ได้รับการตรวจสอบความถูกต้องทางการเข้ารหัสโดย CA ที่ออกใบรับรอง^{[ 30 ]}

CRL มีปัญหาเรื่องความสามารถในการปรับขนาด และขึ้นอยู่กับว่าไคลเอ็นต์สามารถเข้าถึงเครือข่ายได้เพียงพอเพื่อดาวน์โหลดก่อนที่จะตรวจสอบสถานะของใบรับรอง^{[ 10 ]}

CRL ประกอบด้วยข้อมูลเกี่ยวกับใบรับรองทั้งหมดที่ถูกเพิกถอนโดย CA ซึ่งหมายความว่าผู้จัดจำหน่ายและลูกค้าต้องเสียค่าใช้จ่ายในการถ่ายโอนข้อมูลที่อาจไม่เกี่ยวข้อง^{[ 31 ]}การศึกษาในปี 2015 พบว่าใบรับรองโดยเฉลี่ยมี CRL ขนาด 51 kB และ CRL ที่ใหญ่ที่สุดมีขนาด 76 MB ^{[ 2 ]}

โปรโตคอลสถานะใบรับรองออนไลน์ (OCSP) อนุญาตให้ไคลเอ็นต์สอบถามเซิร์ฟเวอร์ ( ผู้ตอบ OCSP ) เกี่ยวกับสถานะของใบรับรองแบบโต้ตอบได้ โดยจะได้รับการตอบกลับที่ได้รับการตรวจสอบความถูกต้องทางการเข้ารหัสโดย CA ที่ออกใบรับรอง^{[ 30 ]}โปรโตคอลนี้ได้รับการออกแบบมาเพื่อแก้ไขปัญหาเกี่ยวกับ CRL ^{[ 31 ]}การตอบกลับ OCSP โดยทั่วไปจะมีขนาดน้อยกว่า 1 กิโลไบต์^{[ 32 ]}

OCSP ประสบปัญหาเรื่องความสามารถในการปรับขนาด เนื่องจากต้องอาศัยการเข้าถึงเครือข่ายของไคลเอ็นต์ในขณะที่ตรวจสอบสถานะการเพิกถอนใบรับรอง นอกจากนี้ ผู้ตอบสนอง OCSP ต้องสามารถเข้าถึงได้และสร้างการตอบสนองที่ใช้งานได้ มิฉะนั้นการตรวจสอบจะล้มเหลว และไคลเอ็นต์ต้องเลือกระหว่างการล้มเหลวแบบอ่อนและการล้มเหลวแบบแข็ง หน่วยงานออกใบรับรองหลายแห่งไม่ได้เผยแพร่การตอบสนอง OCSP ที่มีประโยชน์สำหรับใบรับรองระดับกลาง^{[ 10 ]}

เมื่อมีการร้องขอไปยังผู้ตอบสนองเพื่อตอบสนองต่อการเข้าชมของผู้ใช้ ผู้ตอบสนอง OCSP สามารถเรียนรู้เกี่ยวกับการเข้าชมของผู้ใช้ ซึ่งเป็น ปัญหา ด้านความเป็นส่วนตัวนอกจากนี้ยังทำให้เกิดความล่าช้าในการเชื่อมต่อ เนื่องจากต้องสอบถามผู้ตอบสนองก่อนจึงจะสามารถใช้การเชื่อมต่อใหม่ได้^{[ 19 ]}

การศึกษาในปี 2018 พบว่า 1.7% ของคำขอไปยังผู้ตอบสนองไม่สามารถใช้งานได้ในระดับเครือข่าย และอีกประมาณ 2% ทำให้เกิดการตอบสนอง OCSP ที่ใช้ไม่ได้ โดยมีความแตกต่างกันอย่างมากระหว่าง CA และมุมมองของไคลเอ็นต์^{[ 33 ]}

OCSP stapling เป็นส่วนขยายของ TLS ที่ให้การตอบสนอง OCSP แก่ไคลเอ็นต์พร้อมกับใบรับรองเมื่อเริ่มต้นการเชื่อมต่อ^{[ 31 ]}

OCSP stapling สามารถแก้ปัญหาความท้าทายในการปฏิบัติงานของ OCSP ได้ กล่าวคือ การร้องขอเครือข่ายเพิ่มเติมที่ทำให้เกิดความล่าช้าและการลดทอนความเป็นส่วนตัว^{[ 34 ]}อย่างไรก็ตาม อาจมีความเสี่ยงต่อการโจมตีแบบลดระดับโดยผู้โจมตีแบบ on-path ^{[ 10 ]} RFC 7633 กำหนดส่วนขยายที่ฝังข้อกำหนดลงในใบรับรองที่จะต้องแนบไปกับคำตอบ OCSP ที่ถูกต้อง^{[ 35 ]}ด้วยส่วนขยายนี้ การแนบใบรับรองจะมีประสิทธิภาพในกรณีที่ใบรับรองถูกบุกรุกหลังจากออกอย่างถูกต้องแล้ว อย่างไรก็ตาม หากใบรับรองสามารถออกผิดพลาดได้หากไม่มีส่วนขยาย การแนบใบรับรองอาจไม่ให้ความปลอดภัยใดๆ^{[ 36 ]}

นอกเหนือจากไคลเอนต์และ CA ที่เปิดใช้งานการผูกมัดและส่วนขยาย must-staple แล้ว ผู้ดูแลระบบเซิร์ฟเวอร์ยังต้องดำเนินการเพื่อสนับสนุนการผูกมัดโดยการดึงการตอบสนองเป็นประจำและส่งให้กับไคลเอนต์ในระหว่างการจับมือ ในปี 2018 มีเพียง Firefox เท่านั้นที่รองรับ must-staple และเว็บเซิร์ฟเวอร์ที่ใช้มากที่สุดสองตัว ( Apache httpdและNginx ) ก็ไม่รองรับการผูกมัด OCSP เลย^{[ 37 ]}

CRLite ใช้การแสดงสถานะใบรับรองแบบคงที่ที่บีบอัดสูงสำหรับไคลเอ็นต์โดยใช้ตัวกรองการค้นหาสมาชิกโดยประมาณทำให้การผลิต การแจกจ่าย และการค้นหามีประสิทธิภาพ^{[ 38 ]} CRLite อนุญาตให้ไคลเอ็นต์ล้มเหลวได้ และเนื่องจากไคลเอ็นต์ทั้งหมดดึงข้อมูลเดียวกัน CRLite จึงไม่มีข้อกังวลด้านความเป็นส่วนตัว^{[ 24 ]}

CRLite สามารถใช้งานได้ โดยต้องการเพียงตัวรวบรวมข้อมูลเพื่อดึง CRL จาก CA จากนั้นจัดเตรียมตัวกรองแบบเรียงลำดับและการอัปเดตให้กับตัวกรอง และให้ไคลเอนต์ใช้งาน ไม่จำเป็นต้องมีการดำเนินการใดๆ จาก CA และผู้ถือใบรับรองก็ไม่จำเป็นต้องดำเนินการใดๆ เช่นกัน^{[ 24 ]}ตัวรวบรวมข้อมูลไม่จำเป็นต้องเป็นบุคคลที่สามที่เชื่อถือได้ตัวกรองแบบเรียงลำดับสามารถตรวจสอบได้เพื่อพิสูจน์ว่าสะท้อนถึง CRL ที่ป้อนเข้ามาอย่างถูกต้อง^{[ 39 ]} CA ส่วนตัวยังต้องการการจัดการพิเศษภายใน CRLite ด้วย^{[ 40 ]}ข้อมูลจาก Firefox ชี้ให้เห็นว่า 5% ของใบรับรองไม่ได้อยู่ในบันทึก CT อาจเนื่องมาจาก CA ส่วนตัวหรือความล่าช้าในการรวม^{[ 41 ]}

ในการออกแบบเริ่มต้น CRLite เป็นตัวกรอง Bloom แบบเรียง ลำดับ^{[ 38 ]}ตัวกรองเดี่ยวที่สร้างจากรายการใบรับรองที่ถูกเพิกถอนจะทำให้เกิดผลบวกเท็จในกรณีของโดเมนแบบเปิด นี่เป็นปัญหาที่แก้ไขไม่ได้สำหรับการตรวจสอบการเพิกถอน อย่างไรก็ตาม โดยการใช้Certificate Transparencyเพื่อแจงนับใบรับรองที่ยังไม่หมดอายุทั้งหมด จะสามารถสร้างรายการผลบวกเท็จที่ครบถ้วนได้ จากนั้นจะใช้รายการนี้เพื่อสร้างตัวกรองที่สอง ซึ่งจะถูกตรวจสอบหากใบรับรองตรงกับตัวแรก (และดังนั้นจึงมีโดเมนที่เล็กกว่าอย่างเคร่งครัด) หากตัวกรองที่สองไม่ตรงกัน แสดงว่าเป็นผลบวกจริงและใบรับรองถูกเพิกถอน อย่างไรก็ตาม การตรงกันในตัวกรองที่สองอาจเป็นผลลบเท็จ ซึ่งจำเป็นต้องใช้ตัวกรองที่สาม และต่อไปเรื่อยๆ เนื่องจากจักรวาลมีจำกัดและโดเมนของแต่ละตัวกรองลดลงอย่างเคร่งครัดในแต่ละขั้นตอน กระบวนการนี้จึงสร้างตัวกรองแบบเรียงลำดับที่มีจำนวนจำกัด^{[ 42 ]}

สถานะการเพิกถอนใบรับรองทั้งหมดใน Web PKI ในเดือนมกราคมนั้นคาดว่าจะมีขนาด 10 MB เมื่อใช้ Bloom filter cascade โดยมีการอัปเดต 580 kB ต่อวัน ในเดือนมีนาคม 2018 ขนาดดังกล่าวเพิ่มขึ้นเป็น 18 MB ^{[ 29 ]}ในการจำลองด้วยใบรับรอง 100 ล้านใบ อัตราการหมดอายุรายวัน 1% และอัตราการเพิกถอน 2% CRLite ต้องการพื้นที่เริ่มต้น 3.1 MB จากนั้น 408 kB ต่อวันสำหรับการอัปเดต^{[ 43 ]} Mozilla ในการทดลองใช้ CRLite พบในปี 2024 ว่าอัตราการดาวน์โหลดเฉลี่ยอยู่ที่ 26 MB ในช่วง 10 วัน^{[ 38 ]}

ต่อมา CRLite ได้รับการปรับปรุงให้ใช้อัลกอริทึมใหม่ที่มีประสิทธิภาพมากขึ้น เรียกว่าclubcardsซึ่งช่วยลดการใช้ข้อมูล รวมถึงการสังเกตว่าการเพิกถอนไม่ได้กระจายอย่างสม่ำเสมอทั่ว CA (เช่น CA บางแห่งมีอัตราการเพิกถอนสูงกว่า CA อื่นๆ อย่างต่อเนื่อง) หรือตลอดช่วงเวลา (เช่น เนื่องจากเหตุการณ์การเพิกถอนจำนวนมาก) และการแบ่งส่วนใบรับรองตามพารามิเตอร์เหล่านี้จะช่วยเพิ่มประสิทธิภาพได้^{[ 44 ]}การดาวน์โหลดข้อมูลทดสอบการเป็นสมาชิก clubcard ครั้งแรกในปี 2024 มีขนาด 7.0 MB ครอบคลุมใบรับรองที่ถูกต้อง 903 ล้านใบและใบรับรองที่ถูกเพิกถอน 8.7 ล้านใบ การอัปเดตซึ่งสร้างขึ้นทุกหกชั่วโมงมีขนาดเฉลี่ย 95.5 kB แต่สามารถบีบอัดเหลือ 26.0 kB ได้ ด้วยการแบ่งส่วนเฉพาะผู้ออกใบรับรองเท่านั้น จะอยู่ภายใน 12% ของขอบเขตล่างตามทฤษฎี ด้วยการแบ่งส่วนที่ซับซ้อนมากขึ้นโดยใช้ทั้งวันหมดอายุ/วันออกใบรับรองด้วย ปริมาณที่เหลือที่จะใช้ประโยชน์ได้จะสูงถึง 116% ^{[ 45 ]}

หลังจากการทดลองใช้งานเบื้องหลังฟีเจอร์แฟล็กของการออกแบบ CRLite ครั้งแรกใน Firefox เวอร์ชัน 68 ^{[ 38 ]} Mozilla ได้นำการออกแบบที่แก้ไขแล้วมาใช้ใน Firefox เวอร์ชัน 137 และในเดือนสิงหาคม 2025 ได้ปิดใช้งาน OCSP สำหรับใบรับรองที่ตรวจสอบโดเมนใน Firefox 142 ^{[ 7 ]}ทำให้การเปลี่ยนไปใช้ CRLite ในการใช้งานจริงมีประสิทธิภาพ^{[ 46 ]}ในการทดสอบในห้องปฏิบัติการ พบว่าการตรวจสอบการเพิกถอนใช้เวลาเพียง 10 ไมโครวินาทีต่อใบรับรอง และจากข้อมูลภาคสนาม เวลาเฉลี่ยในการจับมือ TLS ลดลงจาก 172.4 มิลลิวินาทีเหลือ 143.4 มิลลิวินาที ซึ่งเป็นผลมาจากการไม่จำเป็นต้องดึงการตอบสนอง OCSP ^{[ 45 ]}

Let's Revoke ใช้เวกเตอร์บิตของสถานะการเพิกถอน (เรียกว่าเวกเตอร์การเพิกถอนใบรับรองหรือ CRV) เพื่อให้ไคลเอนต์สามารถเรียกสถานะการเพิกถอนจำนวนมากได้อย่างมีประสิทธิภาพ^{[ 4 ]} CA สร้าง CRV สำหรับใบรับรองของตนเอง โดยมี CRV หนึ่งรายการต่อวันหมดอายุ การบำรุงรักษา CRV สำหรับ CA เป็นไปตามจำนวนใบรับรองที่ออก CA ต้องเพิ่มฟิลด์ใหม่ หมายเลขการเพิกถอน ลงในใบรับรองที่ออกแต่ละใบ ทำให้สามารถระบุใบรับรองจาก CA เดียวกันได้ด้วยคู่ของวันหมดอายุของใบรับรองและหมายเลขการเพิกถอน คู่นี้ช่วยให้ไคลเอนต์สามารถค้นหาบิตที่ให้สถานะของใบรับรองที่ระบุภายใน CRV ได้อย่างมีประสิทธิภาพ CRV อาจถูกบีบอัด คาดว่าจะบีบอัดได้ดีมาก เนื่องจากบิตส่วนใหญ่จะไม่ได้ตั้งค่าไว้เกือบตลอดเวลา เนื่องจาก CRV แต่ละรายการเชื่อมโยงกับวันหมดอายุที่กำหนดไว้ CRV เก่าจึงสามารถถูกทิ้งได้อย่างมีประสิทธิภาพ การอัปเดต CRV จะถูกจัดเป็นชุด โดยมีการประทับเวลาและลงนามในการอัปเดตเพื่อแจกจ่ายให้กับไคลเอนต์^{[ 47 ]}การอัปเดตอาจอยู่ในรูปแบบใดรูปแบบหนึ่งจากสามรูปแบบ โดยตัวเลือกที่เหมาะสมที่สุดจะขึ้นอยู่กับอัตราการเพิกถอน ซึ่งช่วยให้สามารถดำเนินการตามปกติได้อย่างมีประสิทธิภาพและจัดการเหตุการณ์เพิกถอนจำนวนมากได้^{[ 48 ]}

คาดว่า CRV จะมีขนาดเล็กพอที่จะเปิดใช้งานการตรวจสอบแบบพุช แต่ไคลเอ็นต์ที่มีข้อจำกัดมากกว่าอาจยังคงทำการตรวจสอบแบบพูล โดยเข้าถึง CRV ที่เลือกไว้เท่านั้น หรือเลื่อนการดึงข้อมูล CRV ออกไปจนกว่าจะมีการตรวจสอบความถูกต้องของใบรับรอง^{[ 49 ]}ไคลเอ็นต์ที่ใช้ Let's Revoke กับการตรวจสอบแบบพุชสามารถล้มเหลวอย่างรุนแรงสำหรับใบรับรองใดๆ ที่มีหมายเลขการเพิกถอน^{[ 24 ]}ผลกระทบต่อความเป็นส่วนตัวและความพร้อมใช้งานของ Let's Revoke ขึ้นอยู่กับสถาปัตยกรรม: หากการตรวจสอบทั้งหมดเป็นแบบพุช จะไม่มีการรั่วไหลของความเป็นส่วนตัวและลดความเสี่ยงต่อการโจมตีแบบปฏิเสธการให้บริการหรือการหยุดทำงาน อย่างไรก็ตาม หากใช้การตรวจสอบแบบพูล ข้อมูลบางอย่างเกี่ยวกับกิจกรรมของผู้ใช้จะรั่วไหล (ในรูปแบบของ CRV ที่เข้าถึง) และ CRV อาจไม่สามารถเข้าถึงได้ในเวลาตรวจสอบความถูกต้อง^{[ 24 ]}

ในการจำลองด้วยใบรับรอง 100 ล้านใบ อัตราการหมดอายุรายวัน 1% และอัตราการเพิกถอน 2% Let's Revoke ต้องการการจัดสรรเริ่มต้น 2.2 MB จากนั้น 114 kB ต่อวันสำหรับการอัปเดต^{[ 50 ]}

Let's Revoke ยังไม่ได้รับการใช้งานอย่างแพร่หลาย^{[ 10 ]}นอกเหนือจากการใช้งานฝั่งไคลเอ็นต์แล้ว ยังต้องการให้ CA ทำการเปลี่ยนแปลงการดำเนินงาน^{[ 51 ]}และไม่ได้ให้ข้อมูลมากเท่ากับ CRL หรือ OCSP (เพียงบิตต่อใบรับรองสำหรับความถูกต้อง) CRL หรือ OCSP อาจยังคงใช้เพื่อเสริม Let's Revoke และให้ข้อมูลเพิ่มเติมนั้น^{[ 52 ]}การใช้งานสามารถทำได้ทีละ CA โดยไคลเอ็นต์จะได้รับประโยชน์จากพฤติกรรม fail-hard ทีละน้อย เนื่องจากประสิทธิภาพของ CRV เหนือกว่า CRL และการตอบสนองของ OCSP ทำให้ CA อาจได้รับแรงจูงใจในการใช้งาน Let's Revoke ^{[ 51 ]}

เทคนิค การเรียกค้นข้อมูลส่วนตัวสามารถบรรเทาความกังวลเรื่องความเป็นส่วนตัวได้ด้วยการตรวจสอบแบบดึงข้อมูล^{[ 53 ]}แทนที่จะให้ไคลเอนต์ทำการตรวจสอบการเพิกถอนเอง มิดเดิลบ็อกซ์อาจทำแทน โดยรวมศูนย์ต้นทุนการตรวจสอบการเพิกถอนและกระจายต้นทุนนั้นไปทั่วการเชื่อมต่อจำนวนมาก ไคลเอนต์ไม่จำเป็นต้องจัดสรรพื้นที่จัดเก็บข้อมูลสำหรับการเพิกถอน^{[ 54 ]}ข้อเสนออีกประการหนึ่งเกี่ยวข้องกับการออกอากาศข้อมูลการเพิกถอนทางวิทยุFM ^{[ 42 ]}

• "ข้อกำหนดพื้นฐานสำหรับการออกและการจัดการใบรับรองที่ได้รับการยอมรับจากสาธารณะ" (PDF) CA /Browser Forum 14 ธันวาคม 2022
• Bruhner, Carl Magnus; Linnarsson, Oscar; Nemec, Matus; Arlitt, Martin; Carlsson, Niklas (2022). "การเปลี่ยนเวรยาม: การจัดการใบรับรองและกุญแจสาธารณะบนอินเทอร์เน็ต"การวัดแบบพาสซีฟและ แอ คทีฟ บันทึกการบรรยายในวิทยาการคอมพิวเตอร์ เล่มที่ 13210 หน้า  50–80 doi : 10.1007 /978-3-030-98785-5_3 ISBN 978-3-030-98784-8.
• Chuat, Laurent; Abdou, Abdelrahman; Sasse, Ralf; Sprenger, Christoph; Basin, David; Perrig, Adrian (2020). "SoK: การมอบหมายและการเพิกถอน จุดเชื่อมโยงที่ขาดหายไปในห่วงโซ่ความเชื่อมั่นของเว็บ" การประชุมวิชาการด้านความปลอดภัยและความเป็นส่วนตัวแห่งยุโรปของ IEEE ประจำปี 2020 (EuroS&P)หน้า  624–638 . arXiv : 1906.10775 . doi : 10.1109/EuroSP48549.2020.00046 . ISBN 978-1-7281-5087-1S2CID 215827701​ ​
• ชุง แทจุง; ล็อก เจย์; จันดราเซการัน บาลากฤษณัน; ชอฟฟ์เนส เดวิด; เลวิน เดฟ; แม็กส์ บรูซ เอ็ม.; มิสเลิฟ อลัน; รูลา จอห์น; ซัลลิแวน นิค; วิลสัน คริสโต (2018). "เว็บพร้อมสำหรับ OCSP Must-Staple แล้วหรือยัง?" (PDF) . รายงานการประชุม Internet Measurement Conference 2018.หน้า  105–118 . doi : 10.1145/3278532.3278543 . ISBN 9781450356190. S2CID  53223350 .
• Durumeric, Zakir; Li, Frank; Kasten, James; Amann, Johanna; Beekman, Jethro; Payer, Mathias; Weaver, Nicolas; Adrian, David; Paxson, Vern; Bailey, Michael; Halderman, J. Alex (2014). "The Matter of Heartbleed". รายงานการประชุมวิชาการด้านการวัดผลทางอินเทอร์เน็ต ปี 2014หน้า  475–488 . doi : 10.1145/2663716.2663755 . ISBN 9781450332132S2CID 142767​ ​
• Hallam-Baker, Phillip (ตุลาคม 2015). ส่วนขยายคุณสมบัติความปลอดภัยของเลเยอร์การขนส่ง (TLS) X.509v3 . IETF . doi : 10.17487 /RFC7633 . RFC 7633 .
• Kogan, Dmitry; Corrigan-Gibbs, Henry (สิงหาคม 2021). "การค้นหาบล็อกลิสต์ส่วนตัวด้วยเช็คลิสต์" . การประชุมวิชาการด้านความปลอดภัย USENIX ครั้งที่ 30 (USENIX Security 21) . สมาคม USENIX . หน้า  875–892 . ISBN 978-1-939133-24-3.
• Korzhitskii, Nikita; Carlsson, Niklas (2021). " สถานะการเพิกถอนบนอินเทอร์เน็ต" การวัด แบบพาสซีฟและแอคทีฟ บันทึกการบรรยายในวิทยาการคอมพิวเตอร์ เล่มที่ 12671 หน้า  175–191 arXiv : 2102.04288 doi : 10.1007/978-3-030-72582-2_11 ISBN 978-3-030-72581-5. S2CID  231846906 .
• คอร์ชิตสกี, นิกิตา; เนเม็ค, มาตุส; คาร์ลสัน, นิคลาส (2022) "เอกสารรับรองเพื่อความโปร่งใสในการเพิกถอน" arXiv : 2203.02280 .{{cite journal}}: การอ้างอิงวารสารต้องใช้|journal=( ความช่วยเหลือ )
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: ระบบที่ปรับขนาดได้สำหรับการส่งการเพิกถอน TLS ทั้งหมดไปยังเบราว์เซอร์ทั้งหมด" การประชุมวิชาการ IEEE ว่าด้วยความปลอดภัยและความเป็นส่วนตัว (SP) ปี 2017หน้า  539–556 . doi : 10.1109/sp.2017.17 . ISBN 978-1-5090-5533-3. S2CID  3926509 .
• Leibowitz, Hemi; Ghalwash, Haitham; Syta, Ewa; Herzberg, Amir (2021). "CTng: ใบรับรองที่ปลอดภัยและความโปร่งใสในการเพิกถอน"คลังเอกสารอิเล็กทรอนิกส์ด้านการเข้ารหัสลับ
• Liu, Yabing; Tome, Will; Zhang, Liang; Choffnes, David; Levin, Dave; Maggs, Bruce; Mislove, Alan; Schulman, Aaron; Wilson, Christo (2015). "การวัดการเพิกถอนใบรับรองแบบครบวงจรใน PKI ของเว็บ". รายงานการประชุม Internet Measurement Conference ปี 2015.หน้า  183–196 . doi : 10.1145/2815675.2815685 . ISBN 9781450338486. S2CID  1955346 .
• Prince, Matthew (17 เมษายน 2557). "ต้นทุนที่ซ่อนเร้นของ Heartbleed" . บล็อก Cloudflare . Cloudflare .
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (พฤศจิกายน 2022). ข้อแนะนำสำหรับการใช้ งานTransport Layer Security (TLS) และ Datagram Transport Layer Security (DTLS) อย่างปลอดภัย IETF . doi : 10.17487/RFC9325 . RFC 9325 .
• Schanck, John (2025). Clubcards สำหรับ WebPKI: การทดสอบการเพิกถอนใบรับรองขนาดเล็กในทางทฤษฎีและการปฏิบัติ 2025 IEEE Symposium on Security and Privacy (SP). doi : 10.1109/SP61157.2025.00128 .
• Schanck, John (19 สิงหาคม 2025b). "CRLite: การตรวจสอบการเพิกถอนใบรับรองที่รวดเร็ว เป็นส่วนตัว และครอบคลุมใน Firefox – Mozilla Hacks - บล็อกสำหรับนักพัฒนาเว็บ" . Mozilla Hacks – บล็อกสำหรับนักพัฒนาเว็บ. สืบค้นเมื่อ19 สิงหาคม 2025 .
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: Scalable Global Certificate Revocation". Proceedings 2020 Network and Distributed System Security Symposium . doi : 10.14722/ndss.2020.24084 . ISBN 978-1-891562-61-7. S2CID  211268930 .
• Szalachowski, Pawel; Chuat, Laurent; Lee, Taeho; Perrig, Adrian (2016). "RITM: การเพิกถอนในระหว่างกระบวนการ". การประชุมวิชาการนานาชาติ IEEE ครั้งที่ 36 ว่าด้วยระบบคอมพิวเตอร์แบบกระจาย (ICDCS) ปี 2016.หน้า  189–200 . arXiv : 1604.08490 . doi : 10.1109/ICDCS.2016.91 . ISBN 978-1-5090-1483-5S2CID 761560​ ​
• Wazan, AS; Laborde, R.; Chadwick, DW; Barrere, F.; Benzekri, A. (11 กันยายน 2017). "การตรวจสอบความถูกต้องของการเชื่อมต่อ TLS โดยเว็บเบราว์เซอร์: ทำไมเว็บเบราว์เซอร์ยังคงไม่เห็นด้วย?" . การประชุมวิชาการด้านซอฟต์แวร์คอมพิวเตอร์และการประยุกต์ใช้งานประจำปีครั้งที่ 41 ของ IEEE (COMPSAC) . หน้า  665–674 . doi : 10.1109/COMPSAC.2017.240 . ISBN 9781538603673S2CID 28599113​ ​