BlockVoke – Fast, Blockchain-Based
Certiﬁcate Revocation for PKIs
and the Web of Trust
1School of Electronics Engineering and Computer Science,
Peking University, Beijing, China
2Institute of Computer Science,
University of Goettingen, Goettingen, Germany
illustrated by the recent revocation of 1.7 million certiﬁcates issued by
the Let’s Encrypt certiﬁcate authority. It is just as essential to get revo-
cation information to users in an eﬃcient and timely manner without
impacting their privacy. Existing approaches such as Certiﬁcate Revo-
cation Lists (CRLs) or the Online Certiﬁcate Status Protocol (OCSP)
fail with respect to either of those metrics, while approaches that try to
mitigate both, such as OCSP-Staple and Must-Staple suﬀer from soft-
failure modes and meager adoption rates. To address these issues, we
propose the BlockVoke scheme, which decentralizes revocations, allow-
ing certiﬁcate owners as well as CAs to revoke certiﬁcates, and distribute
revocation information rapidly. Our approach furthermore allows the
revocation of CA root certiﬁcates, which is not possible with traditional
approaches. The use of a blockchain as an underlying layer ensures the
continued availability and immutability of revocation information. Block-
Voke interacts favorably with approaches such as CRLite and Certiﬁcate
Revocation Vectors (CRV), allowing organizations to update revocation
ﬁlters with as little delay as required by their security policies. We also
demonstrate the cost-eﬃciency of our approach in comparison to other
approaches such as CRLs, showing its high feasibility.
Keywords: PKI ·Blockchain ·Certiﬁcate ·Revocation ·Web of Trust
Nowadays, Internet services and applications, such as e-commerce websites and
e-mail communication or messaging services, are not only essential to our daily
life, but also become more common and popular due to the progressing digitiza-
tion of society, e.g.,  and . X.509 certiﬁcates are used to secure those web
applications and ensure their authenticity, integrity, and conﬁdentiality. Public
⃝Springer Nature Switzerland AG 2020
W. Susilo et al. (Eds.): ISC 2020, LNCS 12472, pp. 315–333, 2020.
316 A. Garba et al.
key infrastructures (PKIs) ensure the correct association between a certiﬁcate
and its owner. The trust model of PKIs relies on hierarchically structured central
authorities , whereas the PGP Web of Trust (WoT) builds on a decentralized
structure . The vulnerability induced by the centralized and intransparent
structure of CAs regularly results in security incidents [4,9]. Meanwhile, the
PGP WoT is decentralized and does not suﬀer from these vulnerabilities. Yet,
the PGP WoT does neither provide suﬃcient certainty that the information
stated in a public key (certiﬁcate) is correct, since users do not carefully verify
them due to missing incentives or lack of punishments, nor is it resilient to Sybil
node attacks .
Certiﬁcates expire after a pre-determined lifetime. However, security inci-
dents or other events require a certiﬁcate revocation before its expiry date. A
certiﬁcate may be revoked after its corresponding private key is compromised,
the identiﬁcation of a ﬂaw in the underlying cryptographic system, or due to
issues related to internal PKI processes.
Recently, the non-proﬁt CA Let’s Encrypt (LE) announced the revocation of
3,048,289 certiﬁcates due to a bug in their Certiﬁcation Authority Authorization
(CAA) software – the so-called LE CAA rechecking bug [10,24,25]. Ultimately,
only 1,706,950 certiﬁcates were revoked, and the remaining certiﬁcates were left
to expire within the subsequent 90 days.
Even though WoT revocations do not depend on a CA, any revocation has to
be propagated within the network. This is done by a set of distributed peer-to-
peer (P2P) keyservers which synchronize with each other. However, due to their
limited number and reoccurring reliability issues, they potentially pose risks to
organizations relying on them [20,28].
Several mechanisms for certiﬁcate revocation exist such as Certiﬁcate Revo-
cation Lists (CRLs) , the Online Certiﬁcate Status Protocol (OCSP) ,
or OCSP extensions such as OCSP stapling  and OCSP Must-Staple .
Nonetheless, due to their centralized nature, these revocation mechanisms inherit
the same security concerns as the general PKI concept itself, e.g., single point
of failure (SPOF).
Alternative decentralized and more transparent alternatives – for both, PKIs
in general as well as the WoT – exist and are being tested, e.g., [12,18,30,45], but
are not widely used yet and suﬀer from diﬀerent disadvantages such as scalability
issues, privacy leaks, eﬃciency deﬁcits or low security guarantees.
Relying on CAs or WoT keyservers as gatekeepers to crucial information
such as certiﬁcate revocation data poses a risk not only to the everyday user,
but especially to big organizations with large IT-systems and thousands of users.
For them, a secure and timely revocation notiﬁcation channel for X.509 certiﬁ-
cates that does not impact user privacy is important. Therefore, a research gap
exists with respect to the design of such a system. This work ﬁlls the detected
gap and investigates the research question of how to enable secure, timely and
privacy preserving certiﬁcate revocation. Our proposed scheme is, in addition,
also decentralized, transparent, scalable and eﬃcient. The proposed BlockVoke
scheme addresses these issues by rapidly distributing revocation information and
BlockVoke – Blockchain-Based Certiﬁcate Revocation 317
decentralizing revocations, allowing certiﬁcate owners as well as CAs to revoke
An instantiation of our scheme is explained using the Bitcoin blockchain and
1-of-2 threshold multi-signature addresses , which, once created using certiﬁ-
cate speciﬁc public keys from both the certiﬁcate owner and the CA, will allow
either party to create a transaction on the blockchain revoking the certiﬁcate.
The remainder of this paper is structured as follows: Sect. 2introduces supple-
mentary literature and related work. Section3focuses on the functional details
of BlockVoke as a transparent and accountable certiﬁcate revocation mechanism,
while Sect. 4details speciﬁc properties as well as engagement processes. After-
wards, Sect. 5evaluates BlockVoke and discusses the ﬁndings. Finally, Sect. 6
concludes this work and provides an outlook on future work.
This section provides background information, supplementary literature, and
also introduces related work with previous approaches to solving the issue of
2.1 Certiﬁcate Revocation Mechanisms
Certiﬁcates expire after a pre-determined lifetime. However, security incidents
or other events may require a certiﬁcate revocation before its expiry date, e.g.,
after its corresponding private key is compromised, the identiﬁcation of a ﬂaw
in the underlying cryptographic system, due to an insecure key length, or due to
issues related to internal PKI processes . Compromised PGP keys or X.509
certiﬁcates enable an attacker to access initially secured data or perform MITM
attacks . CAs revoke certiﬁcates by issuing a signed revocation statement – as
a cryptographic proof – using their private key. Additionally, the CA ensures the
distribution of the revocation statement. In the context of the WoT, revocations
do not depend on a CA. Instead, the certiﬁcate owner revokes the certiﬁcate and
posts a corresponding revocation message to the PGP keyservers.
The most common X.509 certiﬁcate revocation mechanisms are illustrated in
Fig. 1and described in subsequent sections.
Certiﬁcate Revocation Lists (CRLs) are signed records of all revoked – but
not expired – certiﬁcates of a speciﬁc CA based on the certiﬁcates’ serial number
. Certiﬁcates listed in a CRL are not trusted by any browser. However, CRLs
are criticized as not being eﬃcient at dispersing the revocation information for
several reasons: First, clients are only interested in the validity of a single cer-
tiﬁcate – yet, they have to download the complete CRL. Second, each CA main-
tains its own CRL instead of a single global CRL for all CAs. Third, delays occur
between certiﬁcate revocation and adding the certiﬁcate to the CRL, resulting in
browsers trusting the certiﬁcate despite its revocation. Fourth, large numbers of
revocations, as illustrated by our initial Let’s Encrypt incident example, result
318 A. Garba et al.
Web Server CA
Web Server CA
Web Server CA
Client Client Client Client
a) CRL c) OCSP-Staple d) OCSP Must-Staple
Fig. 1. Certiﬁcate Revocation Mechanisms: [a] CRLs: The browser retrieves a signed
list of revoked certiﬁcates from the CA during the SSL/TLS negotiation; [b] OCSP:
The client requests the revocation status of a single certiﬁcate from the CA; [c] OSCP
stapling: The web server communicates with the CA to periodically receive signed
statements which prove that the corresponding certiﬁcate has not been revoked yet.
Alternatively, [b] serves as a fallback; [d] OCSP must-staple enforces [c] by removing
the fallback option [b]. If no valid OCSP response is available, the browser discards the
certiﬁcate; – Based on  and 
in large CRLs, which lead to additional latency and communication overhead
while loading websites .
Online Certiﬁcate Status Protocol (OCSP) addresses the CRL overhead
issue by allowing clients to query the CA directly and requesting the status
of a particular certiﬁcate instead of downloading the whole CRL . The CA
responds by sending a signed response along with the current certiﬁcate’s sta-
tus (revoked, not-revoked, or unknown) along with the validity period of the
certiﬁcate. Even though OCSP reduces the amount of transferred data, it still
results in additional overhead since the CA has to be queried before trusting the
certiﬁcate . Moreover, delays between revoking a certiﬁcate and listing the
certiﬁcate as revoked still occur .
In addition to the previously known issues, OCSP introduces a privacy issue.
The CA can proﬁle clients by correlating their browser activities based on the
IP address with the requested certiﬁcates.
OCSP Stapling –alsoknownasTLS Certiﬁcate Status Request –addresses
OCSP’s communication overhead with the CA as well as the privacy issue men-
tioned above . Instead of the client sending an OCSP request to the CA, the
web server serving a certiﬁcate periodically requests the most-recent certiﬁcate
revocation status updates from the CA. The CA responds with a signed state-
ment for the certiﬁcates of the requesting web server, additionally stapling a
cryptographic proof to the certiﬁcate, which is then presented to a client during
the TLS/SSL negotiations. The CA’s signed statement is only valid for a pre-
deﬁned period and thus cannot be used indeﬁnitely by a malicious web server.
As a result, OCSP stapling reduces communication overhead and addresses the
BlockVoke – Blockchain-Based Certiﬁcate Revocation 319
Fig. 2. General Blockchain Structure – Based on 
issue of CAs proﬁling clients based on their browsing activities. In case a web
server cannot provide an OCSP staple proof, the client can still fallback to nor-
Nevertheless, OCSP stapling still does not solve all issues of certiﬁcate revo-
cation. For example, CAs operate using a hierarchical trust model where a root
CA signs the certiﬁcate of a sub-ordinate CA, and so on. Neither OCSP nor
OCSP stapling incorporates the revocation status for the end-entity certiﬁcate.
An extension proposal exists to address this limitation by allowing the server
to incorporate multiple certiﬁcate statuses in a single response, although this
approach is not widely adopted .
Finally, the OCSP stapling Must Staple Extension enforces the existence of
a valid OCSP response to be presented by the web server – otherwise, TLS/SSL
negotiations are aborted. Furthermore, the OCSP protocol also enforces the
Must Staple Extension and addresses attack scenarios where an attacker is able
to block clients’ OCSP requests or web server OCSP requests forcing them to
fallback to less secure certiﬁcate validation mechanisms. However, according to
, out of 500,000,000 certiﬁcates tested in 2018 only 0.02% supported the
OCSP Must Staple Extension.
2.2 Blockchain Technology
Figure 2presents the general structure of a blockchain and subsequently blocks
as used by, e.g., the Bitcoin , or Ethereum blockchains . A blockchain con-
sists of a sequentially ordered number of blocks that record transaction events,
e.g., transfer of a cryptocurrency from one person to another. Transactions are
cryptographically signed and represent an incremental list of records, consistent
over the network, time-stamped, and veriﬁable . Blocks are linked by hashes
of their previous ancestor block, thereby chaining all blocks together. As a result,
changing information in one block, results in a hash mismatch of the succeeding
block. Thus, tampering with one block requires the recalculation of all succeeding
blocks. Blocks are publicly available and synchronized via a global, distributed,
and decentralized P2P storage system.
The technological foundations of blockchains result in properties relevant for
secure, transparent, eﬃcient, and decentralized certiﬁcate revocation. i) Decen-
tralization: Data is stored and processed in a decentralized and distributed man-
ner. Consensus is determined by the majority of network participants based on
320 A. Garba et al.
the conformity of the network rules. ii)Immutability:Conﬁrmedtransactions
are appended to the blockchain. Once recorded, transactions cannot be changed
later on. Furthermore, they are tamper-resistant and prevent unnoticed manip-
ulation of data. iii)Transparency:Informationstoredonapublicblockchainis
globally available and provides transparency to all users. iv) Openness: The P2P
network is open; anyone can join or leave the network at any time. v)Security:
Security of blockchains is achieved based on cryptographically signed statements
and information in conjunction with the distributed and decentralized consensus
mechanism as well as redundant and transparent P2P data storage.
2.3 Related Work
Besides the general revocation mechanisms presented in the previous section,
many more exist and have been proposed in earlier research. In the context of
traditional PKI-related revocation, systems such as Certiﬁcate Revocation Trees
andCertiﬁcateRevocationSystems exist, while non-research organiza-
tions and entities proposed solutions such as CRLset . Especially the latter
two suﬀer from bandwidth and latency problems and require the client to fetch
revocation details from pre-deﬁned servers .
Larisch et al.  propose CRLite, a revocation mechanism that “aggregates
revocation information for all known, valid TLS certiﬁcates on the web, and
stores them in a space-eﬃcient ﬁlter cascade data structure”  based on Bloom
Filters. The system is implemented in Firefox nightly and is distributed to all
browsers with small (580KB) daily updates. However, the system is prone to
single point of failure attacks since it relies on a centralized system design. Due
to being updated daily, there is also a certain amount of latency between the
revocation of certiﬁcates and users receiving these revocations.
Besides the classical centralized approaches, various decentralized solutions
using blockchain technology emerged in recent times. CertLedger isa
blockchain-based PKI which records the complete SSL/TLS certiﬁcate lifecycle
on the blockchain, including issuance, validation, and revocation of certiﬁcates,
thereby circumventing SPOF issues as well as transparency-related drawbacks
of previous systems. However, CertLedger operates its specialized blockchain,
which incurs signiﬁcant growth in storage (ca. 512GB per year), resulting in
storage and network communication overhead. Moreover, clients do not store
the complete blockchain and only access block headers. Thus, they cannot con-
ﬁrm whether they receive a proof referring to the most recent revocation state
of a certiﬁcate without making a request to a full node, which might lie. Finally,
operating their special-purpose blockchain implies that CertLedger cannot lever-
age security guarantees of established public blockchain platforms.
Yakubov et al., andFromknechtetal., propose further blockchain-
based models for issuing, revoking, and validating X.509 digital certiﬁcates. The
proposed models manage the entire certiﬁcate lifecycle via a blockchain. While
Yakubov et al. rely on Ethereum-based smart contracts, Fromknecht et al. use
Namecoin, which is based on Bitcoin. Similarly, CertChain implementsa
X.509 digital certiﬁcate self-audit and operation service on a blockchain. It stores
BlockVoke – Blockchain-Based Certiﬁcate Revocation 321
the entire certiﬁcate history from registration to revocation. The proposed sys-
tem makes entire revoked certiﬁcates publicly visible, while CertChain leverages
the advantages of blockchain to provide decentralized tamper-evident public cer-
Despite their decentralized nature, these systems require users/clients to
either download the complete blockchain or rely on full nodes to provide the
relevant information to clients, which results in network structures that are still
prone to manipulation. Also, the proposed methods do not provide eﬃcient meth-
ods for clients with storage constraints to query certiﬁcate revocation statuses.
Traditional PKI systems are based on trusted CAs that sign certiﬁcates, main-
tain CRLs, and provide OSCP proofs for certiﬁcates they issued. As previously
mentioned, the current mechanisms of certiﬁcate revocation are subject to SPOF
 risk as well as other security and privacy issues, while the WoT suﬀers from
disadvantages of its own. In this section, we describe the lifecycle of a certiﬁcate
using the blockchain-based BlockVoke certiﬁcate revocation system. The lifecy-
cle consists of three main parts. First, a certiﬁcate signing request is made by
the future certiﬁcate owner, which is subsequently used by the CA to create the
certiﬁcate. Finally, the certiﬁcate either expires or is revoked prematurely.
Throughout this section, we assume an instantiation of our scheme on the
Bitcoin blockchain, using 1-of-2 multi-signature addresses, which allow spending
with either of two diﬀerent public keys. The general structure remains the same
even when instantiated on other blockchain platforms or through smart con-
tracts. First, we describe the BlockVoke scheme as it applies to the revocation
of SSL/TLS certiﬁcates. After that, we describe its applicability to WoT-based
systems, such as PGP. An overview of the whole process is given in Fig. 3.
3.1 Certiﬁcate Signing Request
Creating a CSR generally follows the procedure of creating any regular SSL/TLS
CSR. Our approach, however, requires the addition of a new attribute, which
contains the public key corresponding to a Bitcoin address owned by the certiﬁ-
cate owner – illustrated as step 1 in Fig. 3.
3.2 Certiﬁcate Creation
Again, the creation and signing procedure of the certiﬁcate follows that of any
regular SSL/TLS certiﬁcate. In addition, using the public key corresponding to
a Bitcoin address, the CA uses its own Bitcoin public key and the certiﬁcate
owner’s key to create a 1-of-2 multi-signature address, which can be spent from
with either of the two public keys. The resulting address is added to the certiﬁcate
as an extension ﬁeld. If the CA publishes Certiﬁcate Revocation Vectors (CRV)
322 A. Garba et al.
Fig. 3. Overview of the certiﬁcate lifecycle, from creation to blockchain based revoca-
as described in , it also adds its own public key to the ﬁeld. These are steps
2 and 3 in Fig. 3.
Once the certiﬁcate owner receives the certiﬁcate, it is used as any other
certiﬁcate, as indicated by step 4 in Fig. 3.
The extension ﬁeld allows users attempting to validate the certiﬁcate to look up
past transactions originating from this multi-signature address. If any such trans-
action exists, the certiﬁcate is considered revoked. The creation and the process
of adding this transaction to the blockchain (the so-called mining process) are
indicated by step 5 in Fig. 3.
The actual revocation is performed either by the certiﬁcate owner or the
CA. To revoke a certiﬁcate, the party performing the revocation creates a Bitcoin
transaction, sending a small amount into the multi-signature address speciﬁed in
the extension ﬁeld of the certiﬁcate. After transmitting this transaction, they cre-
ate a second transaction, spending the funds they just sent to the multi-signature
address back to their wallet. This transaction also contains an OP RETURN script
opcode containing necessary information concerning the revocation. During this
step, it is not necessary to wait for the ﬁrst transaction to be conﬁrmed since
Bitcoin allows the spending of unconﬁrmed change. For both transactions, a suf-
ﬁcient miners’ fee should be added to ensure the timely conﬁrmation of both
The OP RETURN script opcode allows embedding arbitrary information in Bit-
coin transactions, with a limited size of up to 40 Bytes. The ﬁrst ten of these
bytes are speciﬁed to be BlockVoke followed by a zero byte. As a result, it easy
BlockVoke – Blockchain-Based Certiﬁcate Revocation 323
to scan the blockchain for revocation transactions even for unknown certiﬁcates.
This is followed by the ﬁrst 16 Bytes of the certiﬁcate’s ﬁngerprint, allowing
users to conﬁrm that this transaction actually pertains to the certiﬁcate they
are trying to validate. It is then followed by a four-byte integer indicating the cer-
tiﬁcate’s date of issuance in days since 2020-02-02. One additional byte encodes
the reason for the revocation, following the RFC 5280  revocation codes as
given in Table 1.
If the CA that issued the certiﬁcate is publishing CRVs, the last nine bytes
contain ﬁrst a three-byte unsigned integer for the revocation number (RN) and
ﬁnally six bytes containing a unique identiﬁer for the CA. This information is
added only in case the CA revokes the certiﬁcate, as can be conﬁrmed through
the public key that was added to the certiﬁcate’s extension ﬁeld.
As revocation information is instantly broadcast over the Bitcoin P2P net-
work, users and entities building their own revocation lists or ﬁlters can instantly
update their ﬁlters to include the newly revoked certiﬁcate. Examples of such
entities may include companies, universities, or other organizations, which have
stringent security requirements that demand a higher update rate than, e.g.,
the daily updates provided by the CRLite  implementation currently being
tested by Mozilla in Firefox Nightly builds .
We estimate that a revocation transaction on Bitcoin using a single input and
output, plus an OP RETURN operation has a size of up to 283 Bytes, depending
on the OP RETURN payload’s size.
3.4 CA Root Certiﬁcates
Usually, the revocation of CA root certiﬁcates poses diﬃculties as they are self-
signed, and there exists no key that is eligible to revoke them. With our scheme,
a separate key tied to a blockchain address is used for revocation. Therefore, the
BlockVoke revocation mechanism applies as well to CA root certiﬁcates, making
it possible to revoke them in case of compromise or other reasons.
3.5 Web of Trust Keys
In the WoT, no central authorities exist to provide trust in cryptographic keys.
Instead, users mutually sign their keys after, ideally, carefully conﬁrming each
others’ identities. Users then determine how much they trust other users’ keys
by checking whether there is a path of transitively trusted signatures leading up
to it .
The BlockVoke scheme for certiﬁcate revocation is also applicable to keys in
the WoT with minor modiﬁcations. Since there is no certiﬁcate authority, only
the key owner can publish a revocation. Due to this, a regular Bitcoin address can
be used instead of a multi-signature address. The key owner directly generates
a Bitcoin address and stores it in a User Attribute Packet  that is part of an
OpenPGP key. From there on, a revocation is performed as speciﬁed above for
324 A. Garba et al.
Tabl e 1 . Certiﬁcate revocation codes according to RFC 5280 .
Code Reason Code Reason
0Unspeciﬁed 6Cessation of operation
1Key compromise 7Certiﬁcate hold
2CA compromise 8Remove from CRL
3Aﬃliation changed 9Privilege withdrawn
4Key compromise 10 AA compromise
In this section, we give an analysis of various properties of the BlockVoke scheme.
First, we detail the security properties of our scheme.
4.1 Basic Security Properties
The primary security properties of certiﬁcates using our scheme remain unaf-
fected as BlockVoke is only concerned with the revocation process. It does this
by announcing and preserving revocations through a blockchain platform. Thus,
it is possible to also employ traditional revocation publication methods such as
OSCP or CRLs in parallel, where required.
The ﬁngerprint provided in revocation transactions allows users to conﬁrm
that the transaction is intended to revoke the speciﬁc certiﬁcate, while the fact
that the transaction originates from the address speciﬁed within the certiﬁcate
guarantees that the revocation is legitimate. Allowing for ﬁngerprint veriﬁcation
mitigates the possible scenario that an attacker gains access to the wallet keys of
a certiﬁcate owner and attempts to randomly revoke their certiﬁcates as a form
of Denial-of-Service attack, without actually knowing which certiﬁcates belong
to a particular certiﬁcate owner.
4.2 Timeliness of Revocations
In contrast to many other blockchain-based schemes, BlockVoke does not require
its users to wait until revocation transactions are conﬁrmed before acting on
them. The transactions themselves are suﬃcient to allow the corresponding cer-
tiﬁcate to be added to revocation lists or CRLite-based ﬁlters without delay. The
purpose of adding them to the blockchain is to ensure the global and continued
availability of these revocations, as the lifetime of transactions that exist merely
in the transaction pool of the Bitcoin P2P network is limited.
Because revocations can be processed as soon as they are broadcast through
the network, attacks on the underlying blockchain also have only a limited impact
on BlockVoke. If the transactions do not get mined before falling out of the
transaction pool, revocations may be lost at some point in the future, unless the
CA or another party rebroadcasts them.
BlockVoke – Blockchain-Based Certiﬁcate Revocation 325
4.3 Comparison with CertLedger
CertLedger moves the entire certiﬁcate lifecycle onto a new, special-purpose
blockchain . While presenting a comprehensive solution to certiﬁcate issuance
and revocation, the approach has certain drawbacks.
First, the use of a custom blockchain means that is not possible for the scheme
to inherit the security properties of existing public blockchains. In the case of
BlockVoke, the computational eﬀort spent on securing the Bitcoin blockchain by
miners also guarantees the future persistence of revocations on this blockchain.
Another issue concerns the privacy-preserving aspect of CertLedger. The
state of a certiﬁcate changes to revoked by triggering a state update operation in
a smart contract. Only full nodes are able to see these updates directly as most
clients only download block headers, which are then used to verify certiﬁcate
state proofs generated by full nodes. CertLedger claims to preserve client privacy
as a state proof can be sent to the client together with the certiﬁcate when
establishing a connection. This way, no request regarding this certiﬁcate has to
be made to any third party. However, if an attacker takes control of a domain
and compromises the key, a situation which certiﬁcate revocation should remedy,
the attacker can bundle an outdated certiﬁcate state proof as long as clients do
not check with a third party full node to ensure that the received state proof is
up to date.
When storing data on a blockchain, the size of transactions and the fees they
incur are important factors to consider. Table 2shows the costs of BlockVoke
revocation transactions on the Bitcoin as well as the Ethereum platform.
As described in Sect. 3.3 and presented in Table2, we estimate an optimal
revocation transaction in the Bitcoin network to have a size below 283 bytes
with a payload size of 40 bytes. As our approach does not depend on fast trans-
action processing, it is not necessary to gain a very high mining priority for our
revocation transactions by paying high fees. Based on data for March 2020, the
cost for a transaction average around $0.001751 per byte. Thus, a BlockVoke
revocation transaction of 283 bytes on the Bitcoin platform costs $0.496.
The costs for an Ethereum transaction are calculated as illustrated in Eq. 1,
where 21000 gas are the fees paid for any transaction, and each byte of payload
costs 68 gas. Based on the 40-byte payload of a BlockVoke revocation, the overall
transaction results in an Ethereum gas demand of 23720. As shown in Table 2
and based on the average Ether price for March 2020, this results in a price of ca.
$0.07 per BlockVoke revocation transaction on the Ethereum platform. Thus, it
is seven times cheaper than the Bitcoin platform.
Fee = 21000 gas + 68 gas ∗size of txdata in bytes (1)
The size of a minimal Ethereum transaction is 107 bytes, in addition to the up
to 40-byte payload of BlockVoke data [35,47].
326 A. Garba et al.
In addition to the costs for the revocation transaction, there has to be a
transaction funding the BlockVoke address. This transaction is usually smaller
and therefore costs less. However, Ethereum multi-signature transactions are
implemented using smart contracts and therefore require two transactions to be
made – ﬁrst, the transaction triggering the smart contract; second, the trans-
action of the smart contract that transfers the funds. Therefore, we need two
107-byte funding transactions.
We further analyze the impact of transaction size and fees in Sect. 5.
Tabl e 2 . Transaction fee comparison between Bitcoin and Ethereum based on the aver-
age transaction fee prices per byte for Bitcoin and the average gas price for Ethereum
in March 2020 – Sources: [5–7] and [16,17,35,47]
Platform Min. TX Size Avg. TX Cost
Bitcoin 283 bytes $0.496
Bitcoin (Funding) 193 bytes $0.338
Ethereum 147 bytes $0.070
Ethereum (Funding) 2 ×107 bytes $0.124
Privacy can be considered from two perspectives: The privacy of the certiﬁcate
owner who might be revoking their certiﬁcate and the privacy of users who
attempt to verify whether a certiﬁcate is still valid.
Certiﬁcate Owner. The privacy impact on certiﬁcate owners is not commonly
considered, but we will shortly explore the topic in the following. In the context
certiﬁcate is revoked. Therefore, unless the certiﬁcate is revoked, our scheme has
no impact on certiﬁcate owner privacy. If a certiﬁcate is revoked, we can again
consider two separate aspects. The ﬁrst aspect is the data contained within the
revocation transaction’s payload. It contains the ﬁngerprint of the certiﬁcate,
the date of issuance, and the certiﬁcate authority. This information should have
little impact on the privacy of the certiﬁcate owner. It can only be matched to
a certiﬁcate when the certiﬁcate and thus its ﬁngerprint is already known. The
only additional information gained from it is the revocation reason, which is
intended to be known by users attempting to use the certiﬁcate.
Another aspect is the issue of general blockchain privacy. Revoking a cer-
tiﬁcate using our scheme requires the creation of a transaction on a blockchain.
Therefore the usual considerations about transaction traceability apply .
BlockVoke – Blockchain-Based Certiﬁcate Revocation 327
User. Our scheme has no impact on user privacy. Users running a full node
receive all revocations without leaking information about which certiﬁcates they
might be interested in. Users downstream of organizations building, e.g., CRLite
ﬁlters based on revocations from our scheme, will experience no privacy impact
from the use of BlockVoke.
Auditability is given as all revocations are publicly stored on the blockchain.
The following sections focus on evaluating the BlockVoke protocol. In Sect. 5.1
and Sect. 5.2, we analyze storage size and costs for diﬀerent certiﬁcate revocation
scenarios in the context of PKIs and the WoT on the Ethereum and Bitcoin
Bit ﬁrst, we discuss how fast a BlockVoke revocation statement propagates
through the system. After revoking a certiﬁcate – for both cases, PKI and WoT –
the revocation statement is posted to the blockchain in the form of a transac-
tion. The revocation transaction is pushed to the pool of pending transactions
before being mined into the next block of the Bitcoin or Ethereum blockchain.
Technically, a revocation transaction does not have to be mined to be valid in
the context of BlockVoke. Therefore, the lower boundary of time that it takes to
publish a revocation transaction is almost instantly. However, an upper bound
depends on the conﬁrmation time of transactions in both networks.
The Bitcoin network aims to publish a new block every ten minutes (the
so-called block time). The larger the transaction fee attached to a revocation
transaction, the higher the probability that a miner will pick up the transaction
as soon as possible to include it into the next block to receive the transaction fee
for doing so. A Bitcoin transaction is usually considered conﬁrmed after six con-
secutive blocks, i.e., after 60 min. However, the median transaction conﬁrmation
time for transactions that include suﬃcient fees varies between ﬁve and thirty
minutes for the ﬁrst block .
The Ethereum network aims to publish a new block every 12–15 s and is
therefore much faster than the Bitcoin network. A 2018 study suggests that less
than 1% of all transactions take more than ten minutes to be conﬁrmed, while
72% are conﬁrmed within 30 s, or less .
Next, we present three case study examples to evaluate cost, eﬃciency, and
storage requirements of BlockVoke in diﬀerent real-life scenarios. The calcula-
tions are based on the transaction cost and storage size estimates presented
earlier in Sect. 4.4.
5.1 Case-Study I – Let’s Encrypt CAA Bug March 2020
In Sect. 1, we presented the Let’s Encrypt CAA bug, which forced LE to revoke
3,048,289 of its certiﬁcates. 1,706,950 were actually revoked while the remainder
328 A. Garba et al.
was left to expire within the next 90 days. Table3presents the costs and storage
size requirements of revoking the 1,706,950 LE certiﬁcates via BlockVoke. Assum-
ing a Bitcoin-based implementation, BlockVoke needs ca. 812.5 MB of storage
for the revocation and funding transactions as well as roughly $1,423,596 in
transaction fees. Given a block time of ten minutes and a block size limit of
one megabyte, all 1.7 million certiﬁcates could have been revoked in less than
136 h – ignoring any further regular transactions which are processed in paral-
lel. An Ethereum-based implementation requires only 616 MB and costs around
$331,148 in fees. Due to the shorter block time (12–15) and a transaction limit
which is imposed by a gas limit (10,000,000 gas at the time of writing this work),
Ethereum could handle the complete set of revocations in less than 47 h – again,
ignoring any further regular transactions.
Tabl e 3. BlockVoke revocation and funding fees as well as storage size requirements
for revoking 1,706,950 certiﬁcates involved in the Let’s Encrypt CAA Bug of March
Storage Size TX Cost
Bitcoin (Revocation) 283 bytes $0.496 483.07 MB $846,647.20
Bitcoin (Funding) 193 bytes $0.338 329.44 MB $576,949.10
Ethereum (Revocation) 147 bytes $0.070 250.92 MB $119,486.50
Ethereum (Funding) 2×107 bytes $0.124 365.29 MB $211,661.80
Table 4goes even one step further and assumes the compromise of the LE
root certiﬁcate which requires to revoke all existing LE certiﬁcates. On March 31,
2020 LE listed around 124.533 million active and valid certiﬁcates . Revoking
all of them at once results in ca. 59.28 GB of storage and $103.8 million in fees on
the Bitcoin, and 44.96 GB of storage and $24.159 million in fees on the Ethereum
Tabl e 4 . Transaction fees and storage size requirements for the hypothetical scenario
of revoking all 124.533 million valid LE certiﬁcates as of March 31, 2020.
Storage Size TX Cost
Bitcoin (Revocation) 283 bytes $0.496 35.24 GB $61,768,386
Bitcoin (Funding) 193 bytes $0.338 24.03 GB $42,092,154
Ethereum (Revocation) 147 bytes $0.070 18.31 GB $8,717,310
Ethereum (Funding) 2×107 bytes $0.124 26.65 GB $15,442,092
BlockVoke – Blockchain-Based Certiﬁcate Revocation 329
It is necessary to put the calculations above into context. Even though the
time, storage, and transaction costs seem to disqualify blockchains as foundations
for PKIs, it is important to keep in mind that the two scenarios presented above
are extreme cases. Revoking 1.7 million – yet alone 124.5 million certiﬁcates –
never happened before and is thus not comparable with day-to-day operating
costs. Moreover, the cost of $24.159 million to safely revoke all compromised
certiﬁcates of a complete CA is cost-eﬃcient, given the size and potential security
implications. As a point of comparison, the US-company Cloudﬂare estimated
that they spend $400,000 per month to distribute their growing CRL [41,45].
This also leaves aside the fact that BlockVoke allows the direct revocation of the
root certiﬁcate, making it even less likely that such a high number of certiﬁcates
ever needs to be revoked.
Moreover, despite the timespan to add all transactions to the blockchain,
the approach is also very time-eﬃcient. As mentioned at the beginning of this
section – a revocation is already valid once a revocation transaction is posted to
the transaction pool. Adding it to a valid blockchain block is only required
for subsequent actions. Nevertheless, adding several gigabytes of data to a
blockchain with a public consensus mechanism and slow block times is a tedious
process. Finally, due to a limited maximum lifetime of certiﬁcates, full nodes do
not have to process all past transactions anymore since their content becomes
irrelevant after some time (e.g., at the latest after two years) and only remains
relevant in the context of maintaining the underlying blockchain’s security guar-
5.2 Case-Study II – Revoking the Web of Trust
Our second case study scenario concerns key revocation in the context of the
WoT. Unfortunately, no statistics exist with regards to the daily, weekly, or
monthly amount of revoked certiﬁcates. However, performedananalysisof
the WoT based on a snapshot from October 2014 and found 2,966,965 keys, which
were neither expired nor revoked. Similar to the root certiﬁcate compromise of
LE, we calculated the storage requirements and transaction fees for the scenario
of revoking the complete WoT. The results are presented in Table 5.Again,
Tabl e 5 . Transaction fees and storage size requirements for the hypothetical scenario
of revoking all 2,966,965 valid WoT keys existing in October, 2014.
Bitcoin (Revocation) 283 bytes $0.496 839.65 MB $1,471,614.64
Bitcoin (Funding) 193 bytes $0.338 572.62 MB $1,002,834.17
Ethereum (Revocation) 147 bytes $0.070 436.14 MB $207,687.55
Ethereum (Funding) 2×107 bytes $0.124 634.93 MB $367,903.66
330 A. Garba et al.
the same considerations regarding time, storage size, and overall costs for this
operation apply as presented in the previous section.
Relying on CAs or WoT keyservers as gatekeepers to crucial information such
as certiﬁcate revocations poses a risk not only to the everyday user but espe-
cially to organizations with large IT-systems and thousands of users. Existing
revocation mechanisms such as Certiﬁcate Revocation Lists (CRLs), the Online
Certiﬁcate Status Protocol (OCSP), and further OCSP extensions are subject
to various security and privacy challenges. CRLs are being criticized as being
an ineﬃcient method of disseminating revocation information; OCSP faces crit-
ical privacy concerns, and its extensions such as OCSP-staple and Must-staple
have minimal adoption rates. On the other hand, the WoT is subject to various
security challenges of its own.
BlockVoke addresses these issues by utilizing blockchain technology to enable
secure, transparent, eﬃcient, and decentralized certiﬁcate revocation using the
Bitcoin or the Ethereum blockchain. The scheme relies on a three-stage lifecycle.
First, a certiﬁcate signing request is made by the future certiﬁcate owner, which
is subsequently used by the CA to create the certiﬁcate in the second step.
Finally, the certiﬁcate either expires or is revoked prematurely. The BlockVoke
scheme is applicable to the revocation of X.509 certiﬁcates as well as OpenPGP
keys used in the context of the WoT.
Usually, the revocation of CA root certiﬁcates poses diﬃculties as they are
self-signed and there exists no key that is eligible to revoke them. BlockVoke
ties a separate key to a blockchain address, which enables the revocation of such
certiﬁcates. Revocation information is stored as part of revocation transactions
on the Bitcoin or Ethereum network by embedding payload data into the trans-
action. Our payload is limited to the size of up to 40 bytes and thus very storage
eﬃcient. As revocation information is instantly broadcast over the correspond-
ing P2P networks, users and entities building their own revocation lists or ﬁlters
instantly receive updates for their ﬁlters to include the newly revoked certiﬁcate.
Furthermore, we detail the protocol parameters and various properties of our
scheme related to security, timeliness, cost, eﬃciency, and auditability. Likewise,
we discuss upper- and lower-bounds of revocation times. Finally, we evaluate
BlockVoke in diﬀerent real-life case-studies and provide estimates on storage
size and revocation costs for these scenarios as well as a proof-of-concept imple-
mentation of the protocol for the Bitcoin and Ethereum platform.
For future work, we plan to implement and deploy the BlockVoke protocol
on the Bitcoin as well as Ethereum blockchain and evaluate real-world use-cases.
Moreover, we will further analyze the option to invoke smart contracts instead
of plain blockchain transactions. Finally, we will research implementations on
alternative blockchain platforms with faster transaction processing times as well
as lower transaction fees.
BlockVoke – Blockchain-Based Certiﬁcate Revocation 331
1. Bitcoin Wiki - Multisignature (2019). https://en.bitcoin.it/w/index.php?title=
2. Baldi, M., Chiaraluce, F., Frontoni, E., Gottardi, G., Sciarroni, D., Spalazzi, L.:
Certiﬁcate validation through public ledgers and blockchains. In: Proceedings of
the First Italian Conference on Cybersecurity, ITASEC 2017, pp. 156–165 (2017)
3. Basin, D.A., Cremers, C., Kim, T.H., Perrig, A., Sasse, R., Szalachowski, P.:
Design, analysis, and implementation of ARPKI: an attack-resilient public-key
infrastructure. IEEE Trans. Depend. Secure Comput. 15(3), 393–408 (2018)
4. Berkowsky, J.A., Hayajneh, T.: Security issues with certiﬁcate authorities. In: 2017
IEEE 8th Annual Ubiquitous Computing, Electronics and Mobile Communication
Conference (UEMCON), pp. 449–455. IEEE (2017)
5. Blockchain Explorer - Blockchain.com: Bitcoin - Average Block Size (MB) (2020).
6. Blockchain Explorer - Blockchain.com: Bitcoin - Average Transactions per Block
7. Blockchain Explorer - Blockchain.com: Bitcoin - Fees per Transaction (USD)
(2020). https://www.blockchain.com/charts/fees-usd-per-transaction. Accessed 1
8. Blockchain Explorer - Blockchain.com: Bitcoin - Median Conﬁrmation Time
(2020). https://www.blockchain.com/charts/median-conﬁrmation-time. Accessed
1 Apr 2020
9. Bugzilla: Bugzilla #1311713 - Comodo: CA Comodo used broken OCR and issued
certiﬁcates to the wrong people (2016). https://bugzilla.mozilla.org/show bug.cgi?
id=1311713. Accessed 19 Mar 2020
10. Bugzilla: Bugzilla #1619179 - Let’s Encrypt: Incomplete revocation for CAA
rechecking bug (2020). https://bugzilla.mozilla.org/show bug.cgi?id=1619179#c7.
Accessed 18 Mar 2020
11. Callas, J. and PGP Corporation and Donnerhacke, L. and IKS GmbH and Finney,
H. and PGP Corporation and Shaw, D. and Thayer, R.: OpenPGP Message For-
mat. IETF RFC4880, November 2007. Accessed 24 Mar 2020
12. Chen, J., Yao, S., Yuan, Q., He, K., Ji, S., Du, R.: CertChain: public and eﬃcient
certiﬁcate audit based on blockchain for TLS connections. In: IEEE INFOCOM -
IEEE Conference on Computer Communications, pp. 2060–2068. IEEE (2018)
13. Chung, T., et al.: Is the web ready for OCSP must-staple? In: Proceedings of the
Internet Measurement Conference 2018, pp. 105–118 (2018)
14. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., Polk, W.: Internet
X.509 Public Key Infrastructure Certiﬁcate and Certiﬁcate Revocation List (CRL)
Proﬁle. IETF RFC5280, May 2008. Accessed 18 Mar 2020
15. Eastlake, D.: Transport Layer Security (TLS) Extensions: Extension Deﬁnitions.
IETF RFC6066, January 2011. Accessed 18 March 2020
16. Etherscan.io: Ether Daily Price (USD) Chart (2020). https://etherscan.io/chart/
etherprice. Accessed 31 Mar 2020
17. Etherscan.io: Ethereum Average Gas Price Chart (2020). https://etherscan.io/
chart/gasprice. Accessed 31 Mar 2020
18. Fromknecht, C., Velicanu, D., Yakoubov, S.: A Decentralized Public Key Infras-
tructure with Identity Retention. IACR Cryptology ePrint Archive, p. 803 (2014)
332 A. Garba et al.
19. Hallam-Baker, P.: X.509v3 Extension: OCSP Stapling Required - Draft-
hallambaker-muststaple-00 (2012). https://tools.ietf.org/html/draft-hallambaker-
muststaple-00. Accessed 18 Mar 2020
20. Hansen, R.J.: SKS Keyserver Network Under Attack (2019). https://gist.github.
com/rjhansen/67ab921ﬀb4084c865b3618d6955275f. Accessed 25 Mar 2020
21. Horst, H.A., Miller, D.: Digital Anthropology. A&C Black, London (2013)
22. Hu, Q., Asghar, M.R., Brownlee, N.: Checking certiﬁcate revocation eﬃciently
using certiﬁcate revocation guard. J. Inf. Secur. Appl. 48, 102356 (2019)
23. ImperialViolet: Revocation Checking and Chrome’s CRL (2012). https://www.
imperialviolet.org/2012/02/05/crlsets.html. Accessed 26 Mar 2020
24. Hoﬀman-Andrews, J.: Let’s Encrypt - 2020.02.29 CAA Rechecking Bug (2020).
Accessed 18 Mar 2020
25. JamesLE: Let’s Encrypt - Revoking Certain Certiﬁcates on March 4 (2020).
114864. Accessed 18 Mar 2020
26. J.C. Jones: CRLite: Speeding Up Secure Browsing (2020). https://blog.mozilla.
org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/. Accessed 19
27. Khare, R., Rifkin, A.: Weaving a web of trust. World Wide Web J. 2(3), 77–112
28. Klafter, R., Swanson, E.: Evil 32: Check Your GPG Fingerprints (2014). https://
evil32.com/. Accessed 25 Mar 2020
29. Kocher, P.C.: On certiﬁcate revocation and validation. In: Hirchfeld, R. (ed.) FC
1998. LNCS, vol. 1465, pp. 172–177. Springer, Heidelberg (1998). https://doi.org/
30. Kubilay, M.Y., Kiraz, M.S., Mantar, H.A.: CertLedger: a new PKI model with
certiﬁcate transparency based on blockchain. Comput. Secur. 85, 333–352 (2019)
31. Larisch, J., Choﬀnes, D., Levin, D., Maggs, B.M., Mislove, A., Wilson, C.: CRLite:
a scalable system for pushing all TLS revocations to all browsers. In: 2017 IEEE
Symposium on Security and Privacy (SP), pp. 539–556. IEEE (2017)
32. Leiding, B.: Link topological analysis of the PGP web of trust. Bachelor’s Thesis,
University of Rostock, Rostock, Germany (2015)
33. Leiding, B., Cap, C.H., Mundt, T., Rashidibajgan, S.: Authcoin: validation and
authentication in decentralized networks. In: The 10th Mediterranean Conference
on Information Systems - MCIS 2016, Paphos, Cyprus, September 2016
34. Let’s Encrypt: Let’s Encrypt - Statistics (2020). https://letsencrypt.org/de/stats/.
Accessed 06 Apr 2020
35. Song, L.: Signing an Ethereum Transaction the Hard Way (2018). https://
hard-way/. Accessed 06 Apr 2020
36. Liu, Y., et al.: An end-to-end measurement of certiﬁcate revocation in the web’s
PKI. In: Proceedings of the 2015 Internet Measurement Conference, pp. 183–196.
37. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System (2008). https://
bitcoin.org/bitcoin.pdf. Accessed 15 Mar 2020
38. Naor, M., Nissim, K.: Certiﬁcate revocation and certiﬁcate update. IEEE J. Sel.
Areas Commun. 18(4), 561–570 (2000)
39. Perlman, R.: An overview of PKI trust models. IEEE Network 13(6), 38–43 (1999)
40. Pettersen, Y.: The Transport Layer Security (TLS) Multiple Certiﬁcate Status
Request Extension. IETF RFC6961, June 2013. Accessed 22 March 2020
BlockVoke – Blockchain-Based Certiﬁcate Revocation 333
41. Prince, M.: The Hidden Costs of Heartbleed (2014). https://blog.cloudﬂare.com/
42. Ron, D., Shamir, A.: Quantitative analysis of the full bitcoin transaction graph.
In: Sadeghi, A.R. (ed.) FC 2013. LNCS, vol. 7859, pp. 6–24. Springer, Heidelberg
(2013). https://doi.org/10.1007/978-3-642-39884-1 2
43. Santesson, S., Myers, M., Malpani, A., Galperin, S., Adams, C.: X. 509 Inter-
net Public Key Infrastructure Online Certiﬁcate Status Protocol - OCSP. IETF
RFC6960, June 2013. Accessed 18 Mar 2020
44. Singh, H.J., Haﬁd, A.S.: Prediction of transaction conﬁrmation time in Ethereum
blockchain using machine learning. In: Prieto, J., Das, A., Ferretti, S., Pinto, A.,
Corchado, J. (eds.) BLOCKCHAIN 2019. AISC, vol. 1010, pp. 126–133. Springer,
Cham (2020). https://doi.org/10.1007/978-3-030-23813-1 16
45. Smith, T., Dickinson, L., Seamons, K.: Let’s revoke: scalable global certiﬁcate
revocation. In: 27th Annual Network and Distributed System Security Symposium,
NDSS 2020. The Internet Society (2020)
46. Su, K., Li, J., Fu, H.: Smart city and the applications. In: International Confer-
ence on Electronics, Communications and Control (ICECC), pp. 1028–1031. IEEE
47. Wood, G.: Ethereum Yellow Paper: A Secure Decentralized Generalised Trans-
action Ledger - BYZANTIUM VERSION 7e819ec - 2019–10-20 (2019). https://
ethereum.github.io/yellowpaper/paper.pdf . Accessed 06 Apr 2020
48. Yakubov, A., Shbair, W., Wallbom, A., Sanda, D., et al.: A blockchain-based
PKI management framework. In: The First IEEE/IFIP International Workshop on
Managing and Managed by Blockchain (Man2Block) Colocated with IEEE/IFIP
NOMS 2018, Tapei, Tawain 23–27 April 2018 (2018)