gpg-key-transition post conversion

4 files changed, 242 insertions, 209 deletions

diff --git a/content/blog/gpg-transition.markdown b/content/blog/gpg-transition.markdown
deleted file mode 100644
index 9331122..0000000
--- a/content/blog/gpg-transition.markdown
+++ /dev/null
@@ -1,174 +0,0 @@
----
-title: "GPG Key Transition"
-description: ""
-tags:
-  - GPG
-  - GNUPG
-  - Smartcards
-  - yubikeys
-date: "2017-08-23"
-slug: "gpg-key-transition"
----
-
-Today I'm announcing my [GPG][6] transition from my old, and now
-expired, [GPG][6] key: [DAEE96513758BF6337F71E491066BA71A5F56C58][0]
-and [8FCAF4F0CBB0BB9C590C8ED11CFA8A9CD949D956][1] to a new master
-key [932F3E8E1C0F4A9895D7B8B8B0CAA28A02958308][2].  The old key will
-remain vaild for a little while longer, but I prefer all future
-correspondence to be addressed to my new key.
-
-This transition document is signed by both keys to validate the
-transition.
-
-If you have signed my old key, I would appreciate new signatures on my
-new key as well, provided that your signing policy permits that
-without re-authenticating me.
-
-## Key Verification ##
-
-Specifically, the old keys were:
-
-    pub   rsa4096 2014-06-12 [expired: 2017-06-27]
-    DAEE 9651 3758 BF63 37F7 1E49 1066 BA71 A5F5 6C58
-
-and,
-
-    pub   rsa4096 2015-01-30 [expires: 2018-01-30]
-    8FCA F4F0 CBB0 BB9C 590C 8ED1 1CFA 8A9C D949 D956
-
-The new key is:
-
-    pub   rsa4096 2017-06-27 [expires: 2022-06-26]
-    932F 3E8E 1C0F 4A98 95D7 B8B8 B0CA A28A 0295 8308
-
-To fetch my new key from a key server, use the following:
-
-    gpg --keyserver pool.sks-keyservers.net --recv-key 0xB0CAA28A02958308
-
-Or, if you prefer, you may also download the new key
-from [this blog][this]:
-
-    curl -fsL https://kennyballou.com/kballou.asc -O
-
-The new key can be verified with the old key:
-
-    gpg --check-sigs 0xB0CAA28A02958308
-
-If you do not have the old key, or would like to double check, the
-fingerprint can be verified against the one above:
-
-    gpg --fingerprint 0xB0CAA28A02958308
-
-If you have both keys, this document can be verified to be signed by
-both keys:
-
-    gpg --verify gpg-transition.markdown.asc
-
-If you are satisfied that you have the correct key and the UID's
-match, and if it's compatible with your key signing policy, I would
-greatly appreciate it if you would sign my key:
-
-    gpg --sign-key 0xB0CAA28A02958308
-
-Finally, if you could upload these signatures, I would appreciate it.
-You can either upload the signatures to a public key server directly:
-
-    gpg --keyserver pool.sks-keyservers.net \
-        --send-key 0xB0CAA28A02958308
-
-Or you can send me an email with the new signatures:
-
-    gpg --armor --export 0xB0CAA28A02958308
-
-## New GPG Setup ##
-
-The new key/transition is brought about by a number of months of
-thinking about the [GPG][6] and a set of small problems I've been facing
-with [GPG][6].  Mainly, sharing keys between the number of different
-computers I use through the day makes me sad and worrisome.
-Similarly, there isn't a good backup/recovery solution to the previous
-setup, something the transition aims to fix.  Finally, multiple keys
-per identity was more bothersome than I had originally anticipated.
-
-My knowledge of [GPG][6] was young and it was time to level up my
-knowledge.  To that end, I will, briefly, describe how my current
-setup works.
-
-### Key Generation and Storage ###
-
-This new setup follows the basic "master-key with sub-keys" approach.
-I have an encrypted USB drive (several, actually), that contains the
-master key and the sub keys.  The master key is used for signing and
-self-certification, but has no other purpose.  The sub keys are
-created for the other purposes, e.g., encryption, signing, and
-authentication.  I will not go over the specifics of generating the
-keys or creating this setup, there
-are [many][0] [guides][1] [already][2] for that purpose.
-
-To solve the multiple device problem, I purchased a [Yubikey Neo][3]
-to contain the sub keys.  I'm currently, as of this writing, only
-using the [smartcard][5] functionality of the Yubikey, thus, I cannot
-speak to its other uses.  However, something to note, the current
-Yubikey (series 4) cannot hold keys bigger than 3072 bits, thus, all
-of my sub keys are 2048 bits.  This turns out to be an acceptable
-trade off, as 2048 keys are really, really similar in strength to 4096
-keys.  I don't have enough cryptographic knowledge to sink into the
-Elliptic-Curve based key algorithms, but they seem to show great
-strengths against the larger RSA algorithm without as many weaknesses.
-
-### Multiple Identities ###
-
-[GPG][6] keys can have multiple UID's associated with them,
-eliminating the need for a mapping of keys to email addresses, (unless
-of course, a key not associated with your identity is desired).
-However, I took a bit of a pragmatic approach here: I did not want
-"work" keys tightly integrated with my own identity.  It will be
-likely I will still generate a separate key for work related
-activities.  This way, deleting passwords and other secrets is as
-simple as deleting the key, I do not actually have to worry about the
-possibility of still being able to decrypt the passwords and encrypted
-data.
-
-The one drawback to this approach of having a separate key pair for
-personal and work related activities is that it either necessitates
-_another_ [Yubikey][3], or I'm back to where I was with the previous
-setup and the multi-device headaches that are associated with it.
-However, I feel this is acceptable, because _usually_ I only have one
-"work" device, but multiple personal devices.
-
-### Backups ###
-
-I've created numerous copies of the encrypted USB drive, and they will
-be scattered to a number of locations, to make sure that I can still
-access at least _a_ copy of the keys, it might not be the most up to
-date key, but it will get me started in getting back online.
-
-Furthermore, because flash memory isn't perfect, I've also created a
-number of printouts using [paperkey][4] such that I can recover the
-key even if _all_ of the USB keys fail.
-
-### Future Work ###
-
-One aspect of the system I would like to improve at some point is that
-instead of creating exact duplicates of the flash drives or
-the [paperkey][4] printouts, I would like to be able to create \\(n\\)
-by \\(m\\) chunks of the key data.  That is, create a backup of
-\\(n\\) pieces that only require \\(m\\) copies to be recoverable.
-
-[this]: https://kennyballou.com/kballou.pub.asc
-
-[0]: https://www.chameth.com/2016/08/11/offline-gnupg-master-yubikey-subkeys/
-
-[1]: https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/
-
-[2]: https://gist.github.com/abeluck/3383449
-
-[3]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
-
-[4]: http://www.jabberwocky.com/software/paperkey/
-
-[5]: https://en.wikipedia.org/wiki/Smart_card
-
-[6]: https://gnupg.org/
-
-[7]: http://blogs.fsfe.org/drdanz/?p=782
diff --git a/content/blog/gpg-transition.markdown.asc b/content/blog/gpg-transition.markdown.asc
deleted file mode 100644
index 7e82967..0000000
--- a/content/blog/gpg-transition.markdown.asc
+++ /dev/null
@@ -1,35 +0,0 @@
------BEGIN PGP SIGNATURE-----
-
-iQIzBAABCAAdFiEEj8r08Muwu5xZDI7RHPqKnNlJ2VYFAlmdIzEACgkQHPqKnNlJ
-2VbU1g/+I4s/PfS3Z7KfHltMxQtIhFYHg1XD2/O9BQmnLqYCbdu799nmfem7fxfC
-scBrvWwCzMilQg3Os2CK8ZxOBAuPjWlJZw1p8do2gB7zZFQlN33v6wcCQPPS5Vwd
-ca72WiP+MH/QdmgzTvg7AgSuM8HrBzUzmz9Xo2ND0KgA9Cz3kgRaYC9XyVUD9SQ7
-+BwM3Jqm62HAyHNhB07zcsGbBH569Fa9gS2MG9e+upsEYXNOLQGPxyMruOznyYbA
-C0P7acAmcN8gL3UE98aDwdCtibDe8Mwk+68wZu+wHSIh20If+rQqSMOscERVdRez
-Txh68LeHbg+6D6Syl61qDd7whdf6A26Alr4339RTkFQoZkTdX+BhHalnaNYVKeVA
-/qTHJQ2NmBjwULMWxiBWxnaB4ZIw+Z8kNWFYZ33FHAXfvFp6uNigK4foP9M4IC1m
-5/rc+h14bj+WaIgF0QIyM5AQU2QrZ0GjfIXRPOeUTsRpG0i1Fr6xKbXdzsdv3Vtf
-1P0zAMXbisfNudZbcympLCWPpcDzy9cNDqB6XXKqvE48aUUce9BA5i3fTkdIMl8y
-pXFmOvT6ntGO5DTReO5m6/7T98qxEkUUbu8nD0qR5b8q7QC3TqcQ+WJhJH8evVZS
-xzpZivvq3bFZ2+7eZUNxTvLXfsf43iJCkcVe7RePIa5OI5h3MNSJAjMEAAEIAB0W
-IQTa7pZRN1i/Yzf3HkkQZrpxpfVsWAUCWZ0jMQAKCRAQZrpxpfVsWJbgD/9YtZr2
-OAzEzEGolLn4g4vJOpkSqry3oYVZArRvXJPxWqLHe3Nv0sxKYEnVFviESQlNTGH/
-puHWzHhyT07EItpCNRc9AdGrIRf3A0rEuGXOLOmpDM/rmmoCLGiO+GZpI8Qe76re
-p90smPHgcCk/XBA0upHW8EJI1yH2Q1X2bhc8xItOq2MrLWnbfsiFf3zc7qsJztL6
-YMdfm1EpJynBAjdMM+8gg73BSLYoZVU2GhrKOIMdWF5FOIzqf1WbCE3qnelCy0As
-/bL4jwDN9e1TnELVwvqCmeCVo2SzyFx+iu/R06QiF6eb1qX4j221Gp4FvPAf9x8f
-sscoeES9MnaN9R1J4tGbV+g/HKZbxsE9HFc2FIBy8OMawmXFYLZrA4ByxMFxS2NQ
-0XbRNeS90Ku7EMdGI+AV5cfrByvMknbzNF/p2Ep44y+yDWDikFaFtp0lZmG0GS2O
-hHUVUVNaazdALTZ8yAKuAtRtKtqAQgNBz2ODpe9BnN5j/VkJVJIao/8vq/epPyQQ
-2K+rpYBwqt8CSTMs7Fr9n38HRGmrY7lkYvcebNSxqxHTcERG0IRQLnJrVkoxGkZL
-eV0SwO9LOD0h4nUXGnyLWsfr6iYFfIqZ6ay7JrDj4NrFTwj/COGW4buZhpI6tcK4
-f6jIf811vbTVQFR/aJ/oP3Snvgk7ab/DyseLRokBMwQAAQgAHRYhBOHS4Af04GxI
-WZD+1v4UeXzm9h/yBQJZnSMxAAoJEP4UeXzm9h/yrVAH/AmXh0CQrW1trYqMv4FN
-p8qLFMV1YQytI874ix7xNHZC9gmjhzTzWgbk8f0mlvO0eWpPZyIoJuiDPPgYKwee
-FFeBBwLl+iilo3DJnnPEGyXgkR3EnvWKsQFPu2ncDrpz3hhegaHplJMNfYxLbftE
-xfycL0WYvUEgpsm/pINlAYUcjBsovOHkHj9GtA4iotFMNBNIkiIFqK4fUXpZ523f
-Y6YBzSTSv/8Y+F2JvNoJ+GWfSAOSmXu2NC4zYP40xPp1/uZOzAQgfYc9s9KPahWi
-tO22AxSGmDrcRAUhRH816XE7vbowuJvNaULRgDde6KK88JIJFztNCNjUwqQ2DD2m
-pMk=
-=mrZk
------END PGP SIGNATURE-----
diff --git a/posts/gpg-transition.org b/posts/gpg-transition.org
new file mode 100644
index 0000000..99f889d
--- /dev/null
+++ b/posts/gpg-transition.org
@@ -0,0 +1,207 @@
+#+TITLE: GPG Key Transition
+#+DESCRIPTION: Key transition statement and verification steps
+#+TAGS: GPG
+#+TAGS: GNUPG
+#+TAGS: Smartcards
+#+TAGS: Yubikeys
+#+DATE: 2017-08-23
+#+SLUG: gpg-key-transition
+#+LINK: gpg-transition-document https://kennyballou.com/blog/2017/08/gpg-key-transition/gpg-transition.org.asc
+#+LINK: gpg-public-key https://kennyballou.com/kballou.pub.asc
+#+LINK: chameth-offline-master-key-subkeys https://www.chameth.com/2016/08/11/offline-gnupg-master-yubikey-subkeys/
+#+LINK: void-kargig-new-key-with-subkeys https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/
+#+LINK: gist-338449 https://gist.github.com/abeluck/3383449
+#+LINK: yubico-neo https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
+#+LINK: paperkey http://www.jabberwocky.com/software/paperkey/
+#+LINK: wiki-smart-cards https://en.wikipedia.org/wiki/Smart_card
+#+LINK: gnupg https://gnupg.org/
+#+LINK: fsfe-drdanz-782 http://blogs.fsfe.org/drdanz/?p=782
+#+LINK: key-1066BA71A5F56C58 https://pgp.mit.edu/pks/lookup?op=get&search=0x1066BA71A5F56C58
+#+LINK: key-1CFA8A9CD949D956 https://pgp.mit.edu/pks/lookup?op=get&search=0x1CFA8A9CD949D956
+#+LINK: key-B0CAA28A02958308 https://pgp.mit.edu/pks/lookup?op=get&search=0xB0CAA28A02958308
+
+#+BEGIN_PREVIEW
+Today I'm announcing my [[gnupg][GPG]] transition from my old, and now expired,
+[[gnupg][GPG]] key:
+[[key-1066BA71A5F56C58][DAEE96513758BF6337F71E491066BA71A5F56C58]] and
+[[key-1CFA8A9CD949D956][8FCAF4F0CBB0BB9C590C8ED11CFA8A9CD949D956]] to a new master
+key [[key-B0CAA28A02958308][932F3E8E1C0F4A9895D7B8B8B0CAA28A02958308]].  The old
+key will remain vaild for a little while longer, but I prefer all future
+correspondence to be addressed to my new key.
+#+END_PREVIEW
+
+This transition document is signed by all three keys to validate the
+transition.
+
+If you have signed my old key, I would appreciate new signatures on my new key
+as well, provided that your signing policy permits that without
+re-authenticating me.
+
+** Key Verification
+   :PROPERTIES:
+   :CUSTOM_ID: key-verification
+   :END:
+
+Specifically, the old keys were:
+
+#+BEGIN_EXAMPLE
+    pub   rsa4096 2014-06-12 [expired: 2017-06-27]
+    DAEE 9651 3758 BF63 37F7 1E49 1066 BA71 A5F5 6C58
+#+END_EXAMPLE
+
+and,
+
+#+BEGIN_EXAMPLE
+    pub   rsa4096 2015-01-30 [expires: 2018-01-30]
+    8FCA F4F0 CBB0 BB9C 590C 8ED1 1CFA 8A9C D949 D956
+#+END_EXAMPLE
+
+The new key is:
+
+#+BEGIN_EXAMPLE
+    pub   rsa4096 2017-06-27 [expires: 2022-06-26]
+    932F 3E8E 1C0F 4A98 95D7 B8B8 B0CA A28A 0295 8308
+#+END_EXAMPLE
+
+To fetch my new key from a key server, use the following:
+
+#+BEGIN_EXAMPLE
+    gpg --keyserver pool.sks-keyservers.net --recv-key 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+Or, if you prefer, you may also download the new key from
+[[gpg-public-key][this blog]]:
+
+#+BEGIN_EXAMPLE
+    curl -fsL https://kennyballou.com/kballou.asc -O
+#+END_EXAMPLE
+
+The new key can be verified with the old key:
+
+#+BEGIN_EXAMPLE
+    gpg --check-sigs 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+If you do not have the old key, or would like to double check, the fingerprint
+can be verified against the one above:
+
+#+BEGIN_EXAMPLE
+    gpg --fingerprint 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+If you have all of the keys, [[gpg-transition-document][this document]] can be
+verified to be signed by all keys:
+
+#+BEGIN_EXAMPLE
+    gpg --verify gpg-transition.org.asc
+#+END_EXAMPLE
+
+If you are satisfied that you have the correct key and the UID's match, and if
+it's compatible with your key signing policy, I would greatly appreciate it if
+you would sign my key:
+
+#+BEGIN_EXAMPLE
+    gpg --sign-key 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+Finally, if you could upload these signatures, I would appreciate it.  You can
+either upload the signatures to a public key server directly:
+
+#+BEGIN_EXAMPLE
+    gpg --keyserver pool.sks-keyservers.net \
+        --send-key 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+Or you can send me an email with the new signatures:
+
+#+BEGIN_EXAMPLE
+    gpg --armor --export 0xB0CAA28A02958308
+#+END_EXAMPLE
+
+** New GPG Setup
+   :PROPERTIES:
+   :CUSTOM_ID: new-gpg-setup
+   :END:
+
+The new key/transition is brought about by a number of months of thinking about
+[[gnupg][GPG]] and a set of small problems I've been facing with
+[[gnupg][GPG]].  Mainly, sharing keys between the number of different computers
+I use through the day makes me sad and worrisome.  Similarly, there isn't a
+good backup/recovery solution to the previous setup, something the transition
+aims to fix.  Finally, multiple keys per identity was more bothersome than I
+had originally anticipated.
+
+My knowledge of [[gnupg][GPG]] was young and it was time to level up my
+knowledge.  To that end, I will, briefly, describe how my current setup works.
+
+*** Key Generation and Storage
+    :PROPERTIES:
+    :CUSTOM_ID: key-generation-and-storage
+    :END:
+
+This new setup follows the basic "master-key with sub-keys" approach.  I have
+an encrypted USB drive (several, actually), that contains the master key and
+the sub keys.  The master key is used for signing and self-certification, but
+has no other purpose.  The sub keys are created for the other purposes, e.g.,
+encryption, signing, and authentication.  I will not go over the specifics of
+generating the keys or creating this setup, there are
+[[chameth-offline-master-key-subkeys][many]]
+[[void-kargig-new-key-with-subkeys][guides]] [[gist-338449][already]] for that
+purpose.
+
+To solve the multiple device problem, I purchased a [[yubico-neo][Yubikey Neo]]
+to contain the sub keys.  I'm currently, as of this writing, only using the
+[[wiki-smart-cards][smartcard]] functionality of the Yubikey, thus, I cannot
+speak to its other uses.  However, something to note, the current Yubikey
+(series 4) cannot hold keys bigger than 3072 bits, thus, all of my sub keys are
+2048 bits.  This turns out to be an acceptable trade off, as 2048 keys are
+really, really similar in strength to 4096 keys.  I don't have enough
+cryptographic knowledge to sink into the Elliptic-Curve based key algorithms,
+but they seem to show great strengths against the larger RSA algorithm without
+as many weaknesses.
+
+*** Multiple Identities
+    :PROPERTIES:
+    :CUSTOM_ID: multiple-identities
+    :END:
+
+[[gnupg][GPG]] keys can have multiple UID's associated with them, eliminating
+the need for a mapping of keys to email addresses, (unless of course, a key not
+associated with your identity is desired).  However, I took a bit of a
+pragmatic approach here: I did not want "work" keys tightly integrated with my
+own identity.  It will be likely I will still generate a separate key for work
+related activities.  This way, deleting passwords and other secrets is as
+simple as deleting the key, I do not actually have to worry about the
+possibility of still being able to decrypt the passwords and encrypted data.
+
+The one drawback to this approach of having a separate key pair for personal
+and work related activities is that it either necessitates /another/
+[[yubico-neo][Yubikey]], or I'm back to where I was with the previous setup and
+the multi-device headaches that are associated with it.  However, I feel this
+is acceptable, because /usually/ I only have one "work" device, but multiple
+personal devices.
+
+*** Backups
+    :PROPERTIES:
+    :CUSTOM_ID: backups
+    :END:
+
+I've created numerous copies of the encrypted USB drive, and they will be
+scattered to a number of locations, to make sure that I can still access at
+least /a/ copy of the keys, it might not be the most up to date key, but it
+will get me started in getting back online.
+
+Furthermore, because flash memory isn't perfect, I've also created a number of
+printouts using [[paperkey][paperkey]] such that I can recover the key even if
+/all/ of the USB keys fail.
+
+*** Future Work
+    :PROPERTIES:
+    :CUSTOM_ID: future-work
+    :END:
+
+One aspect of the system I would like to improve at some point is that instead
+of creating exact duplicates of the flash drives or the [[paperkey][paperkey]]
+printouts, I would like to be able to create \(n\) by \(m\) chunks of the key
+data.  That is, create a backup of \(n\) pieces that only require \(m\) copies
+to be recoverable.
diff --git a/static/blog/2017/08/gpg-key-transition/gpg-transition.org.asc b/static/blog/2017/08/gpg-key-transition/gpg-transition.org.asc
new file mode 100644
index 0000000..9fa217c
--- /dev/null
+++ b/static/blog/2017/08/gpg-key-transition/gpg-transition.org.asc
@@ -0,0 +1,35 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEE2u6WUTdYv2M39x5JEGa6caX1bFgFAlqNvxAACgkQEGa6caX1
+bFjndQ/+Lu6CiTpbFQfa0YsB7d3uBjRfj5tGpDIb99aqoyFTqtjROzrX0sCNJ69r
+ai86mFXsdg7pNweF7ca2UMwUzxHgOhZkEiY65YyRUi9KIoTEx7TlRZiiSP7XpI9z
+GpBn4M8CvZuJW55zSMYEiEEvTJm4AcPRgOPzRJJcyauD/uzZw9tmTwi25SPYDBrv
+Kf9qpC8DGDM3kQRIabfxWdblMngDc3SuqkH2+Ll4/gtUyU6D+D10FRmbQYNnOvJQ
+UaF5ZCvlkWhwhj+N6cjWrWEa02uFS2muiwLGZXyOKIQio3xpiucgdTif14jSR/eS
+2tNm+tO0W5YSqfu4N0y4vprAi7C0yZimJHUJqqBDdmrouJMXJOZfuPZF97gRZVqK
+SsRBWx3noBqTitxKqzJFJeFy00ug4po1jsg5fZG/RFi6yyj9maRxXMasX1iX/R3x
+nbZTNdEU9unb4Z70Fd0dAUElpHFNYG1ge6ZdZrms8JETXBe+QoS4egwAq5A2E3yc
+IamMpqby/JLauT01c+b70HpkSDVygQQezRUhleyPDANKK/2EJInQcO3jB1DEWwmr
+bQLpMyYuB/Xx+N9Li9QUnZB09J9gXR3tq2PyoXOUjNxSHGfjTImgMy5p+RklyfXQ
+0W8N5hmbQMWFn4PJvMBsS/DNuoUYaqEDJsrxeMRAciOySmQB2FWJAjMEAAEIAB0W
+IQSPyvTwy7C7nFkMjtEc+oqc2UnZVgUCWo2/EAAKCRAc+oqc2UnZVsDMEACgOrJY
+4Hc1TXbuD+L8zlPVdjiaO0NlqgkDcF8Xhx/h377Q370dk7HPtW2X+AtktqaRnp4a
+yvOfKDfUFKRRMMt1ztpZoqpQGzbI+zSKx2V6r4SIk8/shqiekdaiDpBmGBUqEIy+
+fSMlsJ/lXoGnRLA2FxRpghUMpyuoldIo8l7IaXqy8hQr7R/DxDBds0Qn6DgEQaBU
+/Y1buO43/SWgHVFlF1HJl2ZKxaoDKMlf1HxbchP0Fs/gB42XuPjD8Cq7jJiei9SO
+Mu5l0pw5eiTFOU7fIELOLoyhkqxYdd5BKzcaVmwhOnSUtxEwNXyjDHIbqYO7vSSM
+yzWUCLw84cyo9wBy80bvHSD46cTCqeB00tA9TF3cnUEDzV+tm310loYLgEVN/0Qf
+NRdC2Pctj/0/h3oDNoPvXEZP9nBYlhaNh9qddoIM17wWoCPsVjDEWqzk7E+dYlG4
+ccqmXHCN2x7c/R2P8ZkkeV3CfyGnvGJQTYbUDLJfOS4EmoaxD90TRxpPQkUwiltE
+gK1WGa7rp2UzpWPv+U8fQxO50NgaAn7/PXgpPdC3s6t9YR1M7bl0ZE2TFPTmE33V
++eYTJS37qvuJXhWxCgdvH96IA5VEi6up9RgnyZQg7bj3mHyj5Zw4JtgdWvFx8L04
+hASDN7AXyM5hf9gX3n9S0/9+ChBqZUXxn21s84kBMwQAAQgAHRYhBOHS4Af04GxI
+WZD+1v4UeXzm9h/yBQJajb8QAAoJEP4UeXzm9h/ydYkH/3RCjzabw+9R2vZsaQgn
+xCqEHJUI62koP7vvbsLE6VLci910lI+4BNi+sOvtc/kGZhYqZi5LTJpdA/JEonMG
+bHSvmLSg6mjsCRdM7c2qzHNDM3c2hm+3dnFWVAt5csM050IbR7dmvXR5FEWc9U+V
+HfN1G93646VvxIzXAATnz9xx5W7bmwVLzA8ZpQeivIRL+Kp4xjcp/KZrdKuIHCAY
+wmW3CPGr93xZqYQ3jCW6KujkaH4J5D48p91WB0x9582U+8dj7BSbtAGmJN/tGWFl
+5WJ4VklukA8JSLac0WeDBmj8aISeXQvM1eOtzdacxIeJfxVS/3Q7rW0Pyfb+j1KW
+dTw=
+=2zvC
+-----END PGP SIGNATURE-----