diff --git a/README.md b/README.md
index cf12232..ab86d5e 100644
--- a/README.md
+++ b/README.md
@@ -8,7 +8,7 @@
 
     sudo apt install make python3-pip
     pip3 install -U pip setuptools
-    pip3 install -U sphinx sphinxcontrib-bibtex
+    pip3 install -U sphinx
 
 If you're running macOS or another operating system, see the instructions at https://www.sphinx-doc.org/en/master/usage/installation.html
 
diff --git a/conf.py b/conf.py
index 036520a..e3685b2 100644
--- a/conf.py
+++ b/conf.py
@@ -36,9 +36,7 @@
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = [
-    'sphinxcontrib.bibtex',
-]
+extensions = []
 
 # The master toctree document.
 master_doc = 'index'
@@ -51,8 +49,6 @@
 # This pattern also affects html_static_path and html_extra_path.
 exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
 
-bibtex_bibfiles = ['refs.bib']
-
 
 # -- Options for HTML output -------------------------------------------------
 
diff --git a/refs.bib b/refs.bib
deleted file mode 100644
index 99b2f45..0000000
--- a/refs.bib
+++ /dev/null
@@ -1,21 +0,0 @@
-@phdthesis{afanasyev-phdthesis,
-	Author = {Alexander Afanasyev},
-	Date-Added = {2013-11-26 23:55:26 +0000},
-	Date-Modified = {2013-11-26 23:55:33 +0000},
-	Month = {December},
-	School = {UCLA},
-	Title = {Addressing Operational Challenges in {Named Data Networking} Through {NDNS} Distributed Database},
-	Year = {2013}
-}
-@techreport{testbed-key-management,
-	Author = {Chaoyi Bian and Zhenkai Zhu and Alexander Afanasyev and Ersin Uzun and Lixia Zhang},
-	Date-Added = {2013-11-26 23:53:25 +0000},
-	Date-Modified = {2013-11-27 00:02:23 +0000},
-	Institution = {NDN},
-	Month = {February},
-	Note = {\url{https://named-data.net/publications/techreports/trpublishkey-rev2/}},
-	Number = {NDN-0009, Revision 2},
-	Title = {Deploying Key Management on {NDN} Testbed},
-	Type = {Technical Report},
-	Year = {2013}
-}
diff --git a/signature.rst b/signature.rst
index 56c49ff..f7634f1 100644
--- a/signature.rst
+++ b/signature.rst
@@ -105,9 +105,7 @@
 The specific definition of the proper usage of the ``Name`` and ``KeyDigest`` options in the ``KeyLocator`` field is outside the scope of this specification.
 Generally, ``Name`` names the Data packet containing the corresponding certificate.
 However, it is up to the specific trust model to define whether this name is the full name of the Data packet or a prefix that can match multiple Data packets.
-For example, the hierarchical trust model :cite:`testbed-key-management` uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed to by ``KeyLocator`` (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked.
-
-.. _SignatureInfoNonce:
+For example, the `hierarchical trust model`_ uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed to by ``KeyLocator`` (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked.
 
 SignatureNonce
 ^^^^^^^^^^^^^^
@@ -119,8 +117,6 @@
 The ``SignatureNonce`` element adds additional assurances that a signature will be unique.
 The recommended minimum length for a ``SignatureNonce`` element is 8 octets.
 
-.. _SignatureTime:
-
 SignatureTime
 ^^^^^^^^^^^^^
 
@@ -131,8 +127,6 @@
 The value of the ``SignatureTime`` element is the timestamp of the signature, represented as the number of milliseconds since 1970-01-01T00:00:00Z (Unix epoch).
 This element can be used to indicate that the packet was signed at a particular point in time.
 
-.. _SignatureSeqNum:
-
 SignatureSeqNum
 ^^^^^^^^^^^^^^^
 
@@ -210,7 +204,7 @@
 
     It is the application's responsibility to define rules (a trust model) concerning when a specific issuer (``KeyLocator``) is authorized to sign a specific packet.
     While trust models are outside the scope of this specification, generally, trust models need to specify authorization rules between key names and Data packet names, as well as clearly define trust anchor(s).
-    For example, an application can elect to use a hierarchical trust model :cite:`testbed-key-management` to ensure Data integrity and provenance.
+    For example, an application can elect to use a `hierarchical trust model`_ to ensure Data integrity and provenance.
 
 .. _SignatureSha256WithEcdsa:
 
@@ -276,4 +270,4 @@
 The shared key used to generate the HMAC signature can be identified by the :ref:`KeyLocator` element, e.g., by using the ``Name`` according to the application's naming conventions.
 It is the application's responsibility to associate the shared key with the identities of the parties who hold the shared key.
 
-.. bibliography::
+.. _hierarchical trust model: https://named-data.net/publications/techreports/trpublishkey-rev2/