HOME
The Info List - Certificate Revocation List





A certificate revocation list (or CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted."[1]

Contents

1 Revocation states 2 Reasons for revocation 3 Publishing revocation lists 4 Revocation vs. expiration 5 Problems with CRLs 6 Authority revocation lists 7 See also 8 References 9 External links

Revocation states[edit] There are two different states of revocation defined in RFC 5280:

Revoked: A certificate is irreversibly revoked if, for example, it is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, misrepresentation of software behaviour, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen). Hold: This reversible status can be used to note the temporary invalidity of the certificate (e.g., if the user is unsure if the private key has been lost). If, in this example, the private key was found and nobody had access to it, the status could be reinstated, and the certificate is valid again, thus removing the certificate from future CRLs.

Reasons for revocation[edit] Reasons to revoke a certificate according to RFC 5280 p69[2] are:

unspecified (0) keyCompromise (1) CACompromise (2) affiliationChanged (3) superseded (4) cessationOfOperation (5) certificateHold (6) removeFromCRL (8) privilegeWithdrawn (9) AACompromise (10)

Note that value 7 is not used. Publishing revocation lists[edit] A CRL is generated and published periodically, often at a defined interval. A CRL can also be published immediately after a certificate has been revoked. A CRL is issued by a CRL issuer, which is typically the CA which also issued the corresponding certificates, but could alternatively be some other trusted authority delegated by the CA.[3] All CRLs have a lifetime during which they are valid; this timeframe is often 24 hours or less. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use. To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory (e.g., preinstalled in web browsers). The certificates for which a CRL should be maintained are often X.509/public key certificates, as this format is commonly used by PKI schemes. Revocation vs. expiration[edit] Expiration dates are not a substitute for a CRL. While all expired certificates are considered invalid, not all unexpired certificates should be valid. CRLs or other certificate validation techniques are a necessary part of any properly operated PKI, as mistakes in certificate vetting and key management are expected to occur in real world operations. In a noteworthy example, a certificate for Microsoft
Microsoft
was mistakenly issued to an unknown individual, who had successfully posed as Microsoft
Microsoft
to the CA contracted to maintain the ActiveX
ActiveX
'publisher certificate' system (VeriSign).[4] Microsoft
Microsoft
saw the need to patch their cryptography subsystem so it would check the status of certificates before trusting them. As a short-term fix, a patch was issued for the relevant Microsoft
Microsoft
software (most importantly Windows) specifically listing the two certificates in question as "revoked".[5] Problems with CRLs[edit] Best practices require that wherever and however certificate status is maintained, it must be checked whenever one wants to rely on a certificate. Failing this, a revoked certificate may be incorrectly accepted as valid. This means that to use a PKI effectively, one must have access to current CRLs. This requirement of on-line validation negates one of the original major advantages of PKI over symmetric cryptography protocols, namely that the certificate is "self-authenticating". Symmetric systems such as Kerberos also depend on the existence of on-line services (a key distribution center in the case of Kerberos). The existence of a CRL implies the need for someone (or some organization) to enforce policy and revoke certificates deemed counter to operational policy. If a certificate is mistakenly revoked, significant problems can arise. As the certificate authority is tasked with enforcing the operational policy for issuing certificates, they typically are responsible for determining if and when revocation is appropriate by interpreting the operational policy. The necessity of consulting a CRL (or other certificate status service) prior to accepting a certificate raises a potential denial-of-service attack against the PKI. If acceptance of a certificate fails in the absence of an available valid CRL, then no operations depending upon certificate acceptance can take place. This issue exists for Kerberos systems as well, where failure to retrieve a current authentication token will prevent system access. No comprehensive solutions to these problems are known, though there are multiple workarounds for various aspects, some of which have proven acceptable in practice.[citation needed] An alternative to using CRLs is the certificate validation protocol known as Online Certificate Status Protocol (OCSP). OCSP has the primary benefit of requiring less network bandwidth, enabling real-time and near real-time status checks for high volume or high-value operations. As of Firefox
Firefox
28, Mozilla have announced they are deprecating CRL in favour of OCSP.[6] CRL files may grow quite large over time e.g. in US government, for certain institution multiple megabytes. Therefore, incremental CRLs have been designed - see http://tools.ietf.org/html/rfc5280#section-5.2.4 a.k.a "Delta CRLs". However, only a few clients implement them (https://technet.microsoft.com/en-us/library/cc731104.aspx[verification needed]). Authority revocation lists [edit]

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2007) (Learn how and when to remove this template message)

An authority revocation list (ARL) is a form of CRL containing certificates issued to certificate authorities, contrary to CRLs which contain revoked end-entity certificates. See also[edit]

Trusted third party Web of trust Certificate server

References[edit]

^ "What is Certificate Revocation List (CRL)? - Definition from WhatIs.com". TechTarget. Retrieved October 26, 2017.  ^ RFC 5280, page 69, section 5.3.1, Reason Code ^ RFC 5280, Section 5, P.53 ^ Microsoft
Microsoft
warns of hijacked certificates - CNET News ^ Microsoft
Microsoft
Security Bulletin MS01-017 : Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard ^ "As of Firefox
Firefox
28, Firefox
Firefox
will not fetch CRLs during EV certificate validation". 

External links[edit]

RFC 3280 RFC 5280

v t e

Web browsers

Comparison

lightweight

History List

for Unix

Timeline Usage share

Features

Ad filtering Augmented browsing Bookmarks

Bookmarklet Live bookmark Smart Bookmarks

Browser extension Browser security Browser synchronizer

comparison

Cookies Download manager Favicon Incremental search Plug-in Privacy mode Tabs Universal Edit Button

Web standards

Acid tests Cascading Style Sheets HTML HTML5 JavaScript MathML SVG WebGL XHTML

Protocols

HTTP HTTPS OCSP SPDY SSL/TLS WebSocket WPAD

Related topics

BrowserChoice.eu CRL iLoo Internet suite Man-in-the-browser Mobile Web Offline reader PAC Pwn2Own Rich Internet application Site-specific browser Widget World Wide Web XML

Desktop

Blink-based

Brave Chrome Chromium Dragon Falkon Opera Sleipnir Slimjet SRWare Iron UC Browser Vivaldi Yandex Browser Sputnik SafeZone Whale

Gecko-based

AT&T Pogo Avant Camino Firefox

Conkeror GNU IceCat IceDragon Swiftfox Swiftweasel TenFourFox Timberwolf Tor Browser Waterfox xB Browser

Galeon Ghostzilla Goanna

Basilisk Pale Moon

K-Meleon Kazehakase Kirix Strata Lotus Symphony Lunascape Mozilla

Beonex Communicator Classilla Netscape SeaMonkey

Trident-based

AOL Explorer Avant Deepnet Explorer GreenBrowser Internet Explorer Lunascape Maxthon MediaBrowser MenuBox NeoPlanet NetCaptor SlimBrowser SpaceTime UltraBrowser WebbIE ZAC Browser

WebKit-based

Arora Avant Dooble Epic Flock Fluid iCab Konqueror Lunascape Maxthon Midori OmniWeb Origyn Web Browser Otter Browser QtWeb rekonq Safari Shiira SlimBoat surf Torch Uzbl Epiphany WebPositive xombrero

Text-based

ELinks Emacs/W3 Line Mode Browser Links Lynx w3m

Other

abaco Amaya Arachne Arena Charon Dillo eww Gazelle HotJava IBM Home Page Reader IBrowse KidZui Microsoft
Microsoft
Edge Mosaic Mothra NetPositive NetSurf Qihoo 360 Secure Browser

Mobile

Blink-based

Android Browser Chromium

Brave Chrome for Android Opera Mobile Silk

Firefox
Firefox
Focus for Android

Gecko-based

Firefox
Firefox
for Android MicroB Minimo Waterfox

WebKit-based

BOLT Dolphin Browser Chrome for iOS Firefox
Firefox
for iOS Firefox
Firefox
Focus for iOS Maxthon Mercury Browser Nokia Browser for Symbian Opera Coast Rockmelt Safari Steel

Other

Blazer CM Browser Deepfish Internet Explorer
Internet Explorer
Mobile Iris Browser Konqueror
Konqueror
Embedded Microsoft
Microsoft
Edge NetFront Opera Mini Skweezer Skyfire Teashark ThunderHawk UC Browser Vision WinWAP

Television and video game console

Gecko-based

Kylo

Presto-based

Internet Channel

WebKit-based

Google TV Nintendo 3DS Internet Browser Nintendo DS & DSi Browser NetFront Steam Overlay Wii U Internet Browser

Other

MSN TV

Software no longer in development shown in italics

Category Commons Internet portal Software portal

v t e

TLS and SSL

Protocols and technologies

Transport Layer Security / Secure Sockets Layer (TLS/SSL) Datagram Transport Layer Security (DTLS) Server Name Indication (SNI) Application-Layer Protocol Negotiation (ALPN) DNS-based Authentication of Named Entities (DANE) DNS Certification Authority Authorization (CAA) HTTPS HTTP Strict Transport Security
HTTP Strict Transport Security
(HSTS) HTTP Public Key Pinning (HPKP) OCSP stapling Perfect forward secrecy STARTTLS

Public-key infrastructure

Automated Certificate Management Environment (ACME) Certificate authority
Certificate authority
(CA) CA/Browser Forum Certificate policy Certificate revocation list (CRL) Domain-validated certificate (DV) Extended Validation Certificate
Extended Validation Certificate
(EV) Online Certificate Status Protocol (OCSP) Public key
Public key
certificate Public-key cryptography Public key
Public key
infrastructure (PKI) Root certificate Self-signed certificate

See also

Domain Name System Security Extensions (DNSSEC) Internet Protocol Security (IPsec) Secure Shell
Secure Shell
(SSH)

History

Export of cryptography from the United States Server-Gated Cryptography

Implementations

Bouncy Castle BoringSSL Botan cryptlib GnuTLS JSSE LibreSSL MatrixSSL mbed TLS NSS OpenSSL RSA BSAFE S2n SChannel SSLeay stunnel wolfSSL

Notaries

Certificate Transparency Convergence HTTPS
HTTPS
Everywhere Perspectives Project

Vulnerabilities

Theory

Man-in-the-middle attack Padding oracle attack

Cipher

Bar mitzvah attack

Protocol

BEAST BREACH CRIME DROWN Logjam POODLE
POODLE
(in regards to SSL 3.0)

Implementation

Certificate authority
Certificate authority
compromise Random number generator attacks FREAK goto fail Heartbleed Lucky Thirteen attack POODLE
POODLE
(in regards

.