Use https for all external links

Change-Id: I4ee473737b911885cf32bc417310b04645610cde
diff --git a/intro.rst b/intro.rst
index 944c340..d1c877a 100644
--- a/intro.rst
+++ b/intro.rst
@@ -8,8 +8,8 @@
 
 - `NDN Protocol Design Principles <https://named-data.net/project/ndn-design-principles/>`__
 
-- `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
+- `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <https://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
 
-- `"SNAMP: Secure Namespace Mapping to Scale NDN Forwarding" by Alexander Afanasyev, Cheng Yi, Lan Wang, Beichuan Zhang, and Lixia Zhang, 18th IEEE Global Internet Symposium, April 2015 <http://named-data.net/publications/snamp-ndn-scalability/>`__
+- `"SNAMP: Secure Namespace Mapping to Scale NDN Forwarding" by Alexander Afanasyev, Cheng Yi, Lan Wang, Beichuan Zhang, and Lixia Zhang, 18th IEEE Global Internet Symposium, April 2015 <https://named-data.net/publications/snamp-ndn-scalability/>`__
 
-- `"NDN Technical Memo: Naming Conventions" by NDN Project Team. NDN, Technical Report NDN-0022 <http://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>`__
+- `"NDN Technical Memo: Naming Conventions" by NDN Project Team. NDN, Technical Report NDN-0022 <https://named-data.net/publications/techreports/ndn-tr-22-2-ndn-memo-naming-conventions/>`__
diff --git a/ndnspec-refs.bib b/ndnspec-refs.bib
index befcbb3..99b2f45 100644
--- a/ndnspec-refs.bib
+++ b/ndnspec-refs.bib
@@ -1,14 +1,3 @@
-%% This BibTeX bibliography file was created using BibDesk.
-%% http://bibdesk.sourceforge.net/
-
-
-%% Created for Alex Afanasyev at 2013-11-26 16:02:26 -0800 
-
-
-%% Saved with string encoding Unicode (UTF-8) 
-
-
-
 @phdthesis{afanasyev-phdthesis,
 	Author = {Alexander Afanasyev},
 	Date-Added = {2013-11-26 23:55:26 +0000},
@@ -16,17 +5,17 @@
 	Month = {December},
 	School = {UCLA},
 	Title = {Addressing Operational Challenges in {Named Data Networking} Through {NDNS} Distributed Database},
-	Year = {2013}}
-
+	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{http://named-data.net/techreports.html}},
+	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},
-	Bdsk-Url-1 = {http://named-data.net/techreports.html}}
+	Year = {2013}
+}
diff --git a/signature.rst b/signature.rst
index dcf9c65..0d2d712 100644
--- a/signature.rst
+++ b/signature.rst
@@ -218,7 +218,7 @@
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ``SignatureSha256WithEcdsa`` defines an ECDSA public key signature that is calculated over the SHA-256 hash of the "signed portion" of an Interest or Data packet.
-This signature algorithm is defined in `RFC 5753, Section 2.1 <http://tools.ietf.org/html/rfc5753#section-2.1>`__.
+This signature algorithm is defined in `RFC 5753, Section 2.1 <https://tools.ietf.org/html/rfc5753#section-2.1>`__.
 All NDN implementations MUST support this signature type with the NIST P-256 curve.
 
 * The TLV-VALUE of ``SignatureType`` is 3
@@ -241,7 +241,7 @@
 This type of signature, if verified, provides very strong assurances that a packet was created by the claimed producer (authentication/provenance) and was not tampered with while in transit (integrity).
 The ``KeyDigest`` option in :ref:`KeyLocator` is defined as the SHA-256 digest of the DER encoding of the ``SubjectPublicKeyInfo`` for an EC key as defined by `RFC 5480 <https://tools.ietf.org/html/rfc5480>`__.
 
-The value of ``SignatureValue`` of ``SignatureSha256WithEcdsa`` is a DER-encoded ``Ecdsa-Sig-Value`` structure as defined in `RFC 3279, Section 2.2.3 <http://tools.ietf.org/html/rfc3279#section-2.2.3>`__.
+The value of ``SignatureValue`` of ``SignatureSha256WithEcdsa`` is a DER-encoded ``Ecdsa-Sig-Value`` structure as defined in `RFC 3279, Section 2.2.3 <https://tools.ietf.org/html/rfc3279#section-2.2.3>`__.
 
 .. _SignatureHmacWithSha256:
 
@@ -249,7 +249,7 @@
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 ``SignatureHmacWithSha256`` defines a hash-based message authentication code (HMAC) that is calculated over the "signed portion" of an Interest or Data packet, using SHA-256 as the hash function, salted with a shared secret key.
-This signature algorithm is defined in `RFC 2104, Section 2 <http://tools.ietf.org/html/rfc2104#section-2>`__.
+This signature algorithm is defined in `RFC 2104, Section 2 <https://tools.ietf.org/html/rfc2104#section-2>`__.
 
 * The TLV-VALUE of ``SignatureType`` is 4
 * ``KeyLocator`` is required
@@ -270,7 +270,7 @@
 
 .. note::
 
-   As stated in `RFC 2104, Section 3 <http://tools.ietf.org/html/rfc2104#section-3>`__, shared keys shorter than the SHA-256 output byte length (32 bytes) are strongly discouraged.
+   As stated in `RFC 2104, Section 3 <https://tools.ietf.org/html/rfc2104#section-3>`__, shared keys shorter than the SHA-256 output byte length (32 bytes) are strongly discouraged.
 
 Provided that the signature verifies, this type of signature ensures the authenticity of the packet, namely, that it was signed by a party possessing the shared key, and that it was not altered in transit (integrity).
 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.
diff --git a/tlv.rst b/tlv.rst
index 4d83ffc..969eb41 100644
--- a/tlv.rst
+++ b/tlv.rst
@@ -9,7 +9,7 @@
 There is also no packet fragmentation support at network level.
 Whenever needed, NDN packets may be fragmented and reassembled hop-by-hop. [#f1]_
 
-.. [#f1] `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
+.. [#f1] `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <https://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
 
 Variable Size Encoding for type (T) and length (L)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~