From a5d46a4e38985be540b9127ddcd3d8e21bbecb9a Mon Sep 17 00:00:00 2001 From: Kali Kaneko Date: Mon, 8 Jun 2015 16:46:11 -0400 Subject: Imported Upstream version 2.0.2 --- .../Complete-Guide-to-Publishing-OpenPGP-in-DNS.md | 832 ---- docs/DETAILS | 1225 ----- docs/NOTES-isec-audit.org | 21 - docs/NOTES-python-gnupg-3.1-audit.html | 946 ---- docs/NOTES-python-gnupg-3.1-audit.org | 232 - docs/NOTES-python-gnupg-development.org | 59 - docs/NOTES-python-openpgp-implementations.txt | 31 - docs/OpenPGP-keys-in-DNS.md | 133 - docs/_build/doctrees/environment.pickle | Bin 1439404 -> 0 bytes docs/_build/doctrees/gnupg.doctree | Bin 582816 -> 0 bytes docs/_build/doctrees/index.doctree | Bin 11034 -> 0 bytes docs/_build/html/.buildinfo | 4 - docs/_build/html/_modules/gnupg.html | 148 - docs/_build/html/_modules/gnupg/_meta.html | 981 ---- docs/_build/html/_modules/gnupg/_parsers.html | 1486 ------ docs/_build/html/_modules/gnupg/_util.html | 718 --- docs/_build/html/_modules/index.html | 104 - docs/_build/html/_sources/gnupg.txt | 131 - docs/_build/html/_sources/index.txt | 44 - docs/_build/html/_static/DETAILS.html | 2677 ----------- docs/_build/html/_static/agogo.css | 337 -- docs/_build/html/_static/ajax-loader.gif | Bin 673 -> 0 bytes docs/_build/html/_static/basic.css | 537 --- docs/_build/html/_static/bgfooter.png | Bin 434 -> 0 bytes docs/_build/html/_static/bgtop.png | Bin 430 -> 0 bytes docs/_build/html/_static/comment-bright.png | Bin 3500 -> 0 bytes docs/_build/html/_static/comment-close.png | Bin 3578 -> 0 bytes docs/_build/html/_static/comment.png | Bin 3445 -> 0 bytes docs/_build/html/_static/doctools.js | 238 - docs/_build/html/_static/down-pressed.png | Bin 368 -> 0 bytes docs/_build/html/_static/down.png | Bin 363 -> 0 bytes docs/_build/html/_static/file.png | Bin 392 -> 0 bytes docs/_build/html/_static/jquery.js | 2 - docs/_build/html/_static/minus.png | Bin 199 -> 0 bytes docs/_build/html/_static/pgp-subkeys.html | 236 - docs/_build/html/_static/plus.png | Bin 199 -> 0 bytes docs/_build/html/_static/pygments.css | 69 - docs/_build/html/_static/searchtools.js | 622 --- docs/_build/html/_static/underscore.js | 31 - docs/_build/html/_static/up-pressed.png | Bin 372 -> 0 bytes docs/_build/html/_static/up.png | Bin 363 -> 0 bytes docs/_build/html/_static/websupport.js | 808 ---- docs/_build/html/genindex.html | 932 ---- docs/_build/html/gnupg.html | 2721 ----------- docs/_build/html/index.html | 147 - docs/_build/html/objects.inv | Bin 1574 -> 0 bytes docs/_build/html/py-modindex.html | 135 - docs/_build/html/search.html | 129 - docs/_build/html/searchindex.js | 1 - docs/_build/python-gnupg-docs.zip | Bin 189773 -> 0 bytes docs/_static/DETAILS.html | 2677 ----------- docs/_static/agogo.css | 337 -- docs/_static/pgp-subkeys.html | 236 - docs/_static/pygments.css | 69 - docs/change-license-emails.txt | 272 -- docs/change-license-emails.txt~ | 437 -- docs/gpg-migrate.txt | 208 - docs/pip-install.log | 5008 -------------------- docs/smartcard-idea.txt | 10 - docs/the-internals-of-a-gpgpgp-key | 631 --- docs/to-monkeysphere-list | 34 - docs/upstream-python-gnupg-POC-exploit.py | 120 - 62 files changed, 26756 deletions(-) delete mode 100644 docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md delete mode 100644 docs/DETAILS delete mode 100644 docs/NOTES-isec-audit.org delete mode 100644 docs/NOTES-python-gnupg-3.1-audit.html delete mode 100644 docs/NOTES-python-gnupg-3.1-audit.org delete mode 100644 docs/NOTES-python-gnupg-development.org delete mode 100644 docs/NOTES-python-openpgp-implementations.txt delete mode 100644 docs/OpenPGP-keys-in-DNS.md delete mode 100644 docs/_build/doctrees/environment.pickle delete mode 100644 docs/_build/doctrees/gnupg.doctree delete mode 100644 docs/_build/doctrees/index.doctree delete mode 100644 docs/_build/html/.buildinfo delete mode 100644 docs/_build/html/_modules/gnupg.html delete mode 100644 docs/_build/html/_modules/gnupg/_meta.html delete mode 100644 docs/_build/html/_modules/gnupg/_parsers.html delete mode 100644 docs/_build/html/_modules/gnupg/_util.html delete mode 100644 docs/_build/html/_modules/index.html delete mode 100644 docs/_build/html/_sources/gnupg.txt delete mode 100644 docs/_build/html/_sources/index.txt delete mode 100644 docs/_build/html/_static/DETAILS.html delete mode 100644 docs/_build/html/_static/agogo.css delete mode 100644 docs/_build/html/_static/ajax-loader.gif delete mode 100644 docs/_build/html/_static/basic.css delete mode 100644 docs/_build/html/_static/bgfooter.png delete mode 100644 docs/_build/html/_static/bgtop.png delete mode 100644 docs/_build/html/_static/comment-bright.png delete mode 100644 docs/_build/html/_static/comment-close.png delete mode 100644 docs/_build/html/_static/comment.png delete mode 100644 docs/_build/html/_static/doctools.js delete mode 100644 docs/_build/html/_static/down-pressed.png delete mode 100644 docs/_build/html/_static/down.png delete mode 100644 docs/_build/html/_static/file.png delete mode 100644 docs/_build/html/_static/jquery.js delete mode 100644 docs/_build/html/_static/minus.png delete mode 100644 docs/_build/html/_static/pgp-subkeys.html delete mode 100644 docs/_build/html/_static/plus.png delete mode 100644 docs/_build/html/_static/pygments.css delete mode 100644 docs/_build/html/_static/searchtools.js delete mode 100644 docs/_build/html/_static/underscore.js delete mode 100644 docs/_build/html/_static/up-pressed.png delete mode 100644 docs/_build/html/_static/up.png delete mode 100644 docs/_build/html/_static/websupport.js delete mode 100644 docs/_build/html/genindex.html delete mode 100644 docs/_build/html/gnupg.html delete mode 100644 docs/_build/html/index.html delete mode 100644 docs/_build/html/objects.inv delete mode 100644 docs/_build/html/py-modindex.html delete mode 100644 docs/_build/html/search.html delete mode 100644 docs/_build/html/searchindex.js delete mode 100644 docs/_build/python-gnupg-docs.zip delete mode 100644 docs/_static/DETAILS.html delete mode 100644 docs/_static/agogo.css delete mode 100644 docs/_static/pgp-subkeys.html delete mode 100644 docs/_static/pygments.css delete mode 100644 docs/change-license-emails.txt delete mode 100644 docs/change-license-emails.txt~ delete mode 100644 docs/gpg-migrate.txt delete mode 100644 docs/pip-install.log delete mode 100644 docs/smartcard-idea.txt delete mode 100644 docs/the-internals-of-a-gpgpgp-key delete mode 100644 docs/to-monkeysphere-list delete mode 100644 docs/upstream-python-gnupg-POC-exploit.py (limited to 'docs') diff --git a/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md b/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md deleted file mode 100644 index 5112c97..0000000 --- a/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md +++ /dev/null @@ -1,832 +0,0 @@ - - -# The complete guide to publishing PGP keys in DNS - -## Introduction - -Publishing PGP keys is a pain. There are many disjoint keyservers, three or -four _networks_ of which, which do (or don't) share information with each -other. Some are corporate, some are private. And it's a crapshoot as to -whose key is going to be on which, or worse, which will have the latest copy -of a person's key. - -For a long time, GPG has had a way to publish keys in DNS, but it hasn't been -well documented. This document hopes to change that. - -After reading this, you should: - -* Know the three ways to publish a key - -* Have at least a couple tools to do so - -* Have learned a bit more about DNS - -The target audience for this guide is a technical one. It's expected you -understand what DNS is, and what an RFC and a resource record is. - -There are three ways to publish a PGP key in DNS. Most modern versions of GPG -can retrieve from all three, although it's not enabled by default. There are -no compile-time options you need to enable it, and it's simple to turn on. Of -the three key-publishing methods, there are two that you probably shouldn't -use at the same time, and there are advantages and disadvantages to each, -which I hope to outline below, both in general and for each method. - -### Advantages to DNS publishing of your keys - -* It's universal. Your DNS is your own, and you don't have to worry about - which network of vastly-disconnectedkeyservers is caching your key. - -* Using DNS does not stop you from publishing via other means. - -* If you run an organization, you can easily publish all your employee-keys - via this method, and in the same step,define a signing-policy, such that a - person need only assign trust to your organization's "keysigning key" (or - theCEO's key, or the CTO's), without the trouble of running a keyserver. - -* DNSSEC can be (somewhat) used as an additional trust-path vector. More on - this in the notes at the bottom. - -* You do not have to be searching DNS for keys in order to publish. On the - same note, you do not have to be publishing in this manner to search - forothers there. - -### Disadvantages to DNS publishing - -* If you don't control your own DNS (or have a good relationship with your DNS - admin), this isn't going to beas easy or even possible. Ideally, you want - to be running BIND. - -* With two of the three methods listed here, you're going to need to be able - to put a CERT record into your DNS. Mostweb-enabled DNS tools probably will - not give you this ability. The third uses TXT records, which SPF has caused - to befairly universal in web-interfaces. However, it's also the least - standards-defined of the three. - -* Using at least some of these methods, it's not always a "set it and forget - it" procedure. You may need toperiodically re-export your key and - re-publish it, especially if you gain new signatures. - -* Using some of these methods, you're going to be putting some pretty large, - pretty unwiedly lines in your DNS zones. Not everyone will easily be able - to retrieve them, but again, you can still publish other ways. - -* Using some of these methods, DNS is just a means to an end: you still need - to publish your key elsewhere, like a webpage,and the DNS records just point - at it. - -* Initial verifications of most of these seem to imply that only DSA keys are - supported, although I welcome feedback. Itseems the community is trying to - get RSA keys to make a comeback. They're the only type supported by the - gpg2.0 card, andthey are the default keytype. There was a while where they - weren't, though. Since writing this document, I've discoveredthat "new" RSA - keys work, but ancient RSA keys with no subkeys tend to misbehave. - -### Turning on key-fetching via DNS - -Inside your GPG "options" file, find the "auto-key-locate" line, and add -"cert" and/or "pka" to the options. - - auto-key-locate cert pka (as well as other methods, like keyserver URLs) - - -Don't be surprised if a lot of people don't use this method. - -Note that you can also turn on two options during signature verification. -They are specified in a "verify-options" clause in your config file, or on the -command line, and they are (right from the GPG manpage): - - pka-lookups - - Enable PKA lookups to verify sender addresses. Note that - PKA is based on DNS, and so enabling this option may dis- - close information on when and what signatures are veri- - fied or to whom data is encrypted. This is similar to the - "web bug" described for the auto-key-retrieve feature. - -And: - - pka-trust-increase - - Raise the trust in a signature to full if the signature - passes PKA validation. This option is only meaningful if - pka-lookups is set. - - -You can also use the same options on the command line (as you'll see in this -document). - -## Types of PGP Key Records - -### DNS PKA Records - -Relevant RFCs: None that I can find. - -Other Docs: The GPG source and mailing lists. - -#### Advantages - -* It's a TXT record. Easy to put in a zonefile with most management software. -* No special tools required to generate, just three simple pieces of data. -* Since it uses a special subzone, you can manage the _pka namespace in a - separate zonefile. -* GPG has an option, when verifying a signature, to look up these records - (--verify-options pka-lookups), so it's doubly useful, both from a - distribution and a verification point. - -#### Disadvantages - -* As with IPGP certs, you're at the mercy of the URL. This doesn't put your - key in DNS, just the location of it, and the fingerprint. Some clients may - not be able to support https or http 1.1. -* Not RFC standard. - -#### Howto - -1. Figure out which key you want to export: - - %gpg --list-keys danm@prime.gushi.org - Warning: using insecure memory! - pub 1024D/624BB249 2000-10-02 <-- I'm going to use this one. - uid Daniel P. Mahoney <danm@prime.gushi.org> - uid Daniel Mahoney (Secondary Email) <gushi@gushi.org> - sub 2048g/DE20C529 2000-10-02 - pub 1024R/309C17C5 1997-05-08 - uid Daniel P. Mahoney <danm@prime.gushi.org> - -2. Export the key to a file (I use keyid.pub.asc, but it can be anything) - - %gpg --export --armor 624BB249 > 624BB249.pub.asc - Warning: using insecure memory! - % - -3. Get the fingerprint for your key: - - %gpg --list-keys --fingerprint 624BB249 - gpg: WARNING: using insecure memory! - gpg: please see http://www.gnupg.org/faq.html for more information - pub 1024D/624BB249 2000-10-02 - Key fingerprint = C206 3054 5492 95F3 3490 37FF FBBE 5A30 624B B249 <-- That bit is your fingerprint. - uid Daniel P. Mahoney <danm@prime.gushi.org> - uid Daniel Mahoney (Secondary Email) <gushi@gushi.org> - sub 2048g/DE20C529 2000-10-02 - -4. Copy the file somewhere, like your webspace. It need not live on the same - server. It needs to be accessable by the url you create in the next step. - - %cp 624BB249.pub.asc public_html/danm.pubkey.txt - -5. Make up your text record. The format is: - - danm._pka.prime.gushi.org. TXT "v=pka1;fpr=C2063054549295F3349037FFFBBE5A30624BB249;uri=http://prime.gushi.org/danm.pubkey.txt" - - -We'll take this in several parts. The record label is simply the email -address with "._pka." replacing the "@". danm@prime.gushi.org becomes -danm._pka.prime.gushi.org. Don't forget the trailing dot, if you're using the -fully qualified name. I recommend sticking with fully-qualified, for -simplicity. - -The body of the record is also simple. The v portion is just a version. -There's only one version as far as I can tell, 'pka1'. The fpr is the -fingerprint, with all whitespace stripped, and in uppercase. The uri is the -location a key can be retrieved from. All the "names" are lowercase, -separated by semicolons. - -6. Publish the above record in your DNS. Bump your serial number and reload - your nameserver. If you're using DNSSEC, re-sign your zone. - -#### Testing - -Most of the tests we're going to do for these are essentially the same -activity. See if our DNS server is handing out an answer, and then see if GPG -can retrieve it. - -1. A simple dig: - - %dig +short danm._pka.prime.gushi.org. TXT - "v=pka1\;fpr=C2063054549295F3349037FFFBBE5A30624BB249\;uri=http://prime.gushi.org/danm.pubkey.txt" - -(The backslashes before the semicolons are normal). Other than that, it seems -to make sense and match what I put in.) - -2. Test it with GPG. Rather than messing around with, and adding-from and - deleting from live keyrings, you can do: - - %echo "foo" | gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-key-locate pka -r you@you.com - - -(where you@you.com is the address of your primary key.) The /tmp/gpg-$$ -creates a random file named after your PID. What you should see, and what I -see, is something like this: - - gpg: WARNING: using insecure memory! - gpg: please see http://www.gnupg.org/faq.html for more information - gpg: keyring `/tmp/gpg-39996' created - gpg: requesting key 624BB249 from http server prime.gushi.org - gpg: key 624BB249: public key "Daniel P. Mahoney <danm@prime.gushi.org>" imported - gpg: public key of ultimately trusted key CF45887D not found - gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model - gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u - gpg: Total number processed: 1 - gpg: imported: 1 - gpg: automatically retrieved `danm@prime.gushi.org' via PKA - gpg: DE20C529: There is no assurance this key belongs to the named user - pub 2048g/DE20C529 2000-10-02 Daniel P. Mahoney <danm@prime.gushi.org> - Primary key fingerprint: C206 3054 5492 95F3 3490 37FF FBBE 5A30 624B B249 - Subkey fingerprint: CE40 B786 81E2 5CB9 F7D3 1318 9488 EB58 DE20 C529 - It is NOT certain that the key belongs to the person named - in the user ID. If you *really* know what you are doing, - you may answer the next question with yes. - Use this key anyway? (y/N) y - -----BEGIN PGP MESSAGE----- - Version: GnuPG v1.4.10 (FreeBSD) - hQIOA5SI61jeIMUpEAf/UotgWP8VQC9VTY36HaZeXO1CTFk90x0qlPrAhJk9YaoA - 2eHNKZSoHKqaLjzTbaWnWHnNZu0IllIS+qrAwNeIAhswfzDoc8Q9+/4sGSR3LmxA - 8SEwrJIvLmGVbqJEtnH8TTHIEao/lpL/d+ul4nLfbXRn0NW+MsaCAi8UsjbLlJeV - n4p0GQlpDoZCE55DTwMzfWMT84YVwuXTesuN+i7sSyJn2hT1rXuK1BCVcsgTcKdy - QhIo3EfKBlfFp74yiU7QCmlAujD6U6a93mmxezPIHVx/WGXgPExVRGgEzfT/tUcI - IQ2xMDUv4BF05hgm04GPGCbBY431j4UkdWWI6bvMLwgA2i01NmflH/6Z8+ss6J1M - e3RWnR7TPl5lDkXFBtLGAzO+HrsC5A32SbkTw+WsljCQLifJ2EalfoJ1QGY4Sp3v - H2YunwZLVPTc+D2JnrXfqNmi5zYZio8by3c8L0CgWdMwZ7PPxZpTOLN77/MIjBkJ - EBb8Z6SZCgzTIhN5z56ZgWFvmSKf1vKkeUcrgxMs+DnA+XqBMJ9w520JwoTLjJza - syrlYVhd+ktY21DYB9OJ5MZx2HMAtkUDRAzW1zoLcehk1kdZNzhpjU5hqSjT8/GN - trKFeqkmKemrq2GvMNyJyrEOB8e7KgbmXa95YKH0Wh2D4SWpXukegyCspmY4tDE+ - uckaFSao+48g8D6vs1irGSxBRjyhD/jPDblrgpo= - =NbgW - -----END PGP MESSAGE----- - -The "insecure memory" warning is a silly warning that the only way to turn off is to run GPG setuid root. -You can see in the output that the key comes from PKA. - -The "it is NOT certain" warning has nothing to do with the fact that it came -from DNS. You will get that warning every time you use that key (or any gpg -key) until you have edited it and assigned ownertrust to it, or until the key -is signed with a trusted signature, either from your personal web of trust, or -from a signing service like the pgp.com directory. - -3. Ask other people to run it for you and send you the resulting blob. You should be able to decrypt it with your private key. - -### PGP CERT Records - -Also known as: The "big" CERT record. - -Relevant RFCs: [RFC 2538](http://www.faqs.org/rfcs/rfc2538.html), -[RFC 4398](http://www.faqs.org/rfcs/rfc4398.html), specifically sections 2.1 -and 3.3 - -#### Advantages - -* DNS is all you need. You don't have to host the key elsewhere. As a DNS - nerd, this strikes me as very cool. - -* Suprisingly easy to verify with dig, if you have a base64 converter handy - (openssl includes one) - -#### Disadvantages - -* These records can get big. Really big. Especially if you have photo-ids on your keys. You can play with export-options to shrink it somewhat. Big dns packets may require EDNS, or dns-over-tcp, which not everyone supports, but support is becoming more widespread as a result of DNSSEC awareness. - -* Requires the make-dns-cert tool, which isn't built by default. - -* Requires you to have some control over your actual zonefile. Most control panels won't cut it. - -* Make-dns-cert currently generates a very ugly record for this. - - #### How to - -1. As before, the first step is to figure out which key we want. - - %gpg --list-keys danm@prime.gushi.org - Warning: using insecure memory! - pub 1024D/624BB249 2000-10-02 <-- I'm going to use this one. - uid Daniel P. Mahoney <danm@prime.gushi.org> - uid Daniel Mahoney (Secondary Email) <gushi@gushi.org> - sub 2048g/DE20C529 2000-10-02 - pub 1024R/309C17C5 1997-05-08 - uid Daniel P. Mahoney <danm@prime.gushi.org> - -2. We export the key, but this time, it needs to be binary. - - %gpg --export 624BB249 > 624BB249.pub.bin - Warning: using insecure memory! - -3. We run make-dns-cert on it. make-dns-cert comes with no manual or docs, - but running with -h gives you all the clue you need. - - make-dns-cert - -f fingerprint - -u URL - -k key file - -n DNS name - -So then, - - make-dns-cert -n danm.prime.gushi.org. -k 624BB249.pub.bin - 
`%make-dns-cert -n danm.prime.gushi.org. -k 624BB249.pub.bin
-         danm.prime.gushi.org.   TYPE37  \# 1298 0003 0000 00 9901A20439D8DAF1110400F770EC6AA006076334BEC6DB6FBB237DC194BC0AB8
-         302C8953F04C28FC2085235D4F10EFA027234FBD63D142CCADD5213AD2B79A22C89ED9B4138370D8220D0F987F993A5364A4A7AC3D42F3765C384
-         71DDD0FF3372E4AE6F7BEE1E18EF464A0BEB5BBE860A08238891455EBE7CB53D567E981F78ADBD263206B0493ADCB74DD00A0FF0E9A1CD245415E
-         CEF59435162AFCE4CDD14BC70400EA38FF501256E773DEA299404854D99F4EDB2757AA911A9C77C68AB8D6622E517A556C43D21F0523C568F016C
-         D0DB89EF435F0D53B4E07434213F899E6578955DC2C147931E7B6901C9FD8A02705417D69A879B3CC196D2AC2EAEF311192EE89ABAF5A60942167
-         B4625735FCBDFB5DE0E3AC1236A53FA4D7CDD7D75F5DE85AF50400867D9546B28B79AF10541053CF4AB06A6171BFD21458BFD12AF1AE2B2401CAD
-         8851661F8AF6602F80EDAC99C79616BE1F910F4156242003779C68D7A079A8B18F89DD293E1B247E7420471300A4A0730AA61DE281CCC211FC405
-         A0A8A79877999FF9042AD892AB927DA371E8883BBB370AB7A97841408C3486BB18598CF2559BB42844616E69656C20502E204D61686F6E6579203
-         C64616E6D407072696D652E67757368692E6F72673E884E04101102000E050239D8DAF1040B030102021901000A0910FBBE5A30624BB249FA2E00
-         9B057503ED498695AE5ED73CA1B98EBAEE13F717E500A0921E0D92724459100266FEBBC29E911C8B0F530BB43244616E69656C204D61686F6E657
-         920285365636F6E6461727920456D61696C29203C67757368694067757368692E6F72673E8860041311020020050245D49FD7021B23060B090807
-         030204150208030416020301021E01021780000A0910FBBE5A30624BB249158400A082C8AF43DA8B85F740D6B1A6E9FF0B4490520B8C00A08F77D
-         21FBF86C842963E8090DC0646D1DD7F95C9B9020D0439D8DAF4100800F64257B7087F081772A2BAD6A942F305E8F95311394FB6F16EB94B3820DA
-         01A756A314E98F4055F3D007C6CB43A994ADF74C648649F80C83BD65E917D4A1D350F8F5595FDC76524F3D3D8DDBCE99E1579259CDFDB8AE744FC
-         5FC76BC83C5473061CE7CC966FF15F9BBFD915EC701AAD35B9E8DA0A5723AD41AF0BF4600582BE5F488FD584E49DBCD20B49DE49107366B336C38
-         0D451D0F7C88B31C7C5B2D8EF6F3C923C043F0A55B188D8EBB558CB85D38D334FD7C175743A31D186CDE33212CB52AFF3CE1B1294018118D7C84A
-         70A72D686C40319C807297ACA950CD9969FABD00A509B0246D3083D66A45D419F9C7CBD894B221926BAABA25EC355E9320B3B00020207FF5E1A3C
-         C5DA00E1E94EC8EF6C7FE9B49D944C71D8BBC817DD8E64A7344B9E48392E0B833B3B1DB7E6D5A38BE2826DEF0060F78C6417871EAF1CFBCBC47D2
-         7E93718D975E0A3A36D868C021D6B771740CE2918307D69D614BBF0632DC31932EA31397A7F3B04618C9A76C2F38265C7037E303EDD8AEF03D069
-         208E3FE9C4EA77D83E6311ED36C013D58C54E914B263A459E22D463A0288510C4752B99C163EEA0A55686979691AB0D9F9AA0C06C834446D7A723
-         EC534D819301382621ACF8930C74E9FD28C8797718AEC2C30CF601E24194B799234104A3D6239657B1D4AD545BDAA637F61541435CB51B4D138FB
-         F55E1A9FD2EED860E4459D6795B6FCCA23155A8846041811020006050239D8DAF4000A0910FBBE5A30624BB249415A009E37BCFDC64E76CBF6A86
-         82B85EA161BD1DFB793DF00A0C471BC7B9723535CD855D8FF1EB93F01E251B698
-         %
-                                                                                                                                                              
-The program prints that all on **one line**.
-
-Immediately, we notice a few things.
-
-*   The record type isn't "CERT", it's "TYPE37".  This confused me for a while until I discovered    [RFC3597](http://www.faqs.org/rfcs/rfc3597.html) Basically, it's a way that a DNS server can handle a resource    record it doesn't know about, by giving it some special fields like the "#", as well as a length (which is the 1298 you    see there).
-
-*   The rest of the record is on one line.  I wrapped it for the purposes of brevity.  If I were using this in a zonefile,    I would need to be careful that I wrapped it on a byte-boundary (every two characters is a byte).  If I miss the    boundary, named will refuse to load it, dnssec-signzone won't touch it, etc.
-
-4.  So the thing is ugly and you don't want to touch it.  The easiest way to work with it is to drop all that into a file:
-
-        %make-dns-cert -n danm.prime.gushi.org. -k 624BB249.pub.bin > 624BB249.big.cert
-
-
-5.  And then either read it into your editor, or tack it on like this:
-
-        %cat 624BB249.big.cert >> your.zonefile
-
-Be sure to make a backup first.  Either way, you never have to copy/paste the raw hex and worry about newlines being    inserted where you don't want them.
-
-6.  Before you reload your zone, you might want to use named-checkzone on it first:
-
-        prime# named-checkzone gushi.org gushi.org.hosts
-        zone gushi.org/IN: loaded serial 2009102909
-        OK
-        prime#
-
-7.  Voice of experience: You may want to dial the TTL (which controls how long servers will cache your data) way down on the    record above.  It's not hard, just put a number before the TYPE37, with a space, i.e:
-
-         danm.prime.gushi.org. 30 TYPE37
-
-This way if it all goes terribly wrong, or you need to make changes, it won't be cached for very long.
-
-8.  If it looks okay, bump your serial number and reload.
-
-#### Testing
-
-1.  As above, you can dig, but you won't be able to easily read the results:
-
-         prime# dig +short danm.prime.gushi.org CERT
-         ;; Truncated, retrying in TCP mode.
-
-
-PGP 0 0 
-mQGiBDnY2vERBAD3cOxqoAYHYzS+xttvuyN9wZS8CrgwLIlT8Ewo/CCF
-I11PEO+gJyNPvWPRQsyt1SE60reaIsie2bQTg3DYIg0PmH+ZOlNkpKes
-PULzdlw4Rx3dD/M3Lkrm977h4Y70ZKC+tbvoYKCCOIkUVevny1PVZ+mB
-94rb0mMgawSTrct03QCg/w6aHNJFQV7O9ZQ1Fir85M3RS8cEAOo4/1AS
-Vudz3qKZQEhU2Z9O2ydXqpEanHfGirjWYi5RelVsQ9IfBSPFaPAWzQ24
-nvQ18NU7TgdDQhP4meZXiVXcLBR5Mee2kByf2KAnBUF9aah5s8wZbSrC
-6u8xEZLuiauvWmCUIWe0Ylc1/L37XeDjrBI2pT+k183X119d6Fr1BACG
-fZVGsot5rxBUEFPPSrBqYXG/0hRYv9Eq8a4rJAHK2IUWYfivZgL4DtrJ
-nHlha+H5EPQVYkIAN3nGjXoHmosY+J3Sk+GyR+dCBHEwCkoHMKph3igc
-zCEfxAWgqKeYd5mf+QQq2JKrkn2jceiIO7s3CrepeEFAjDSGuxhZjPJV
-m7QoRGFuaWVsIFAuIE1haG9uZXkgPGRhbm1AcHJpbWUuZ3VzaGkub3Jn
-PohOBBARAgAOBQI52NrxBAsDAQICGQEACgkQ+75aMGJLskn6LgCbBXUD
-7UmGla5e1zyhuY667hP3F+UAoJIeDZJyRFkQAmb+u8KekRyLD1MLtDJE
-YW5pZWwgTWFob25leSAoU2Vjb25kYXJ5IEVtYWlsKSA8Z3VzaGlAZ3Vz
-aGkub3JnPohgBBMRAgAgBQJF1J/XAhsjBgsJCAcDAgQVAggDBBYCAwEC
-HgECF4AACgkQ+75aMGJLskkVhACggsivQ9qLhfdA1rGm6f8LRJBSC4wA
-oI930h+/hshClj6AkNwGRtHdf5XJuQINBDnY2vQQCAD2Qle3CH8IF3Ki
-utapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSG
-SfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPF
-RzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvN
-ILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjT
-NP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM
-2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/9e
-GjzF2gDh6U7I72x/6bSdlExx2LvIF92OZKc0S55IOS4Lgzs7Hbfm1aOL
-4oJt7wBg94xkF4cerxz7y8R9J+k3GNl14KOjbYaMAh1rdxdAzikYMH1p
-1hS78GMtwxky6jE5en87BGGMmnbC84JlxwN+MD7diu8D0Gkgjj/pxOp3
-2D5jEe02wBPVjFTpFLJjpFniLUY6AohRDEdSuZwWPuoKVWhpeWkasNn5
-qgwGyDREbXpyPsU02BkwE4JiGs+JMMdOn9KMh5dxiuwsMM9gHiQZS3mS
-NBBKPWI5ZXsdStVFvapjf2FUFDXLUbTROPv1Xhqf0u7YYORFnWeVtvzK
-IxVaiEYEGBECAAYFAjnY2vQACgkQ+75aMGJLsklBWgCeN7z9xk52y/ao
-aCuF6hYb0d+3k98AoMRxvHuXI1Nc2FXY/x65PwHiUbaY
-
-
-It's still ugly, but it's not AS ugly because it's base64, which includes
-spaces, at least, and is easier to search for a pattern.  Base64 can also be
-easily wrapped on any boundary, which is nice.
-
-You can run your existing exported key through a base64 converter, like the
-one built into the openssl binary, if you want to compare:
-
-     %cat 624BB249.pub.bin | openssl enc -base64
-     mQGiBDnY2vERBAD3cOxqoAYHYzS+xttvuyN9wZS8CrgwLIlT8Ewo/CCFI11PEO+g
-     JyNPvWPRQsyt1SE60reaIsie2bQTg3DYIg0PmH+ZOlNkpKesPULzdlw4Rx3dD/M3
-     Lkrm977h4Y70ZKC+tbvoYKCCOIkUVevny1PVZ+mB94rb0mMgawSTrct03QCg/w6a
-     (...etc...)
-     OPv1Xhqf0u7YYORFnWeVtvzKIxVaiEYEGBECAAYFAjnY2vQACgkQ+75aMGJLsklB
-     WgCeN7z9xk52y/aoaCuF6hYb0d+3k98AoMRxvHuXI1Nc2FXY/x65PwHiUbaY
-
-
-Now, while you could compare things byte-by-byte here, what I've done as a
-"casual check" is just pick random strings in the text and see if they match
-up.  For example, you can see that "reaIsie2" is present in both.  They both
-start with and end with similar strings on every line.  The real test, of
-course, is to see if GPG recognizes it as a valid key.
-
-By the way, since I use DNSSEC, dnssec-signzone rewrites this record into the
-proper "presentation format" for me, which is base64.  If you want a similar
-function, you can use named-compilezone to get some of the same effects, or
-you can use the shell script I provide later in this document, with which you
-don't even need make-dns-cert.
-
-2.  Testing with gpg
-
-As above, the command to test this is remarkably simple:
-
-     %rm /tmp/gpg-*
-     %echo "foo" | gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-key-locate cert -r danm@prime.gushi.org
-     gpg: keyring `/tmp/gpg-39996' created
-     gpg: key 624BB249: public key "Daniel P. Mahoney <danm@prime.gushi.org>" imported
-     gpg: Total number processed: 1
-     gpg:               imported: 1
-     gpg: automatically retrieved `danm@prime.gushi.org' via DNS CERT
-     gpg: DE20C529: There is no assurance this key belongs to the named user
-     pub  2048g/DE20C529 2000-10-02 Daniel P. Mahoney <danm@prime.gushi.org>
-     Primary key fingerprint: C206 3054 5492 95F3 3490  37FF FBBE 5A30 624B B249
-     Subkey fingerprint: CE40 B786 81E2 5CB9 F7D3  1318 9488 EB58 DE20 C529
-     It is NOT certain that the key belongs to the person named
-     in the user ID.  If you *really* know what you are doing,
-     you may answer the next question with yes.
-     Use this key anyway? (y/N) y
-     -----BEGIN PGP MESSAGE-----
-     Version: GnuPG v1.4.10 (FreeBSD)
-     hQIOA5SI61jeIMUpEAf/Sx7MKWm+e9EpUTSrDaBp4nJfDcBeqbYJulPRbDZz7eVW
-     2+ol6sG0jWjuirbG1YppZccEr9mgqaQujdSXb/bleD8POS0TEWuf3aPswFQvHf90
-     NLEzHt6BnfLoeobXXxyCflNaGX8zW+XgJtwZqAc2+jietuz8MOUhrf5m17CsW/wZ
-     IuEqwaek+K1irJp+w3rhaE08Jzb/S4CCifeW9J3mK57chQoPOu7Nz3rY666YKp/3
-     9T9StOgmFiNpvtFPNy4N7hHMHvbQwRsKlnkl+a7n0Aq2+OF4d1+/k2EE4uSGgcz0
-     oHvee8DnuOx3P92mO4Jz5/0O0lwBD7I51iOjzUurTAgAiIM5sHV8/QFCVzH9Ule+
-     gd8Wo5momcphkU/AXpce5Xgi/Vm4oGQ0x0queii8afUrzkpeN5SuwgQfAdOPiXW5
-     2bo527jBllxOxjeBasfky82XheTnLzbAQNvQNTEM9zE7zCl1LQJUZEJ1hVzcOevI
-     s+cm/AaGII9VkrAtSt3aLSRZuRJHFmhGvYd2Hz5WzcV1YFjXXP1eLwfetDBlaeB9
-     /K5v4hZBkIZPbHX0DcLVrP96mCIT4wCBYSJw+I6n0E6Fz3IfybQG2HMfqWp966/c
-     00ijx/aRDh42Dr/fTropuzzFzQr7weYDa1JnN3Zoftv6Zb/n+NcrmMiDCH8jJV6E
-     uMkaeeB5Mv7ssDQ9kPhO989CHFcznrE1lgOxjX8=
-     =NTLY
-     -----END PGP MESSAGE-----
-                                                                                                                                                              
-Okay, as above, try to decrypt that with your private key.
-
-### IPGP CERT Records
-
-Also known as: The "little" or "short" CERT record. (These terms are purely my
-own).
-
-Relevant RFCs: [RFC 2538](http://www.faqs.org/rfcs/rfc2538.html),
-[RFC 4398](http://www.faqs.org/rfcs/rfc4398.html), specifically sections 2.1
-and 3.3
-
-IPGP certs are interesting.  It's basically the same pieces of infomation that
-are in the PKA record, as above, except that it's supported by an RFC.
-Despite the RFC compliance, I am not sure if any non-gpg client knows to look
-for them.  However, because it's a DNS cert, make-dns-cert encodes the
-information in binary, and your DNS server will see it in base64.  So
-verifying it visually is harder than verifying either of the above.
-
-#### Advantages
-
-*   Small, easy-to-transmit records.
-*   Can use the same uri as the PKA record.
-
-#### Disadvantages
-
-* Relies on the URI scheme.  I haven't yet been able to get a definitive list
-  of what uri schemes are supported, although I've seen http and finger.  I've
-  also seen reports that unless gpg is compiled against curl, http 1.1 is not
-  supported (what this actually means is that any host that supports SSL will
-  probably work, because of some of the nuances of SSL).
-* With PGP certs and IPGP certs, GPG will only parse the first key it gets, so
-  if you publish both, and one doesn't work, there's no failover.  I've argued
-  that this should be fixed.
-* Requires make-dns-cert, which is not built in GPG by default.  (But see "A
-  Better Way" below)
-* Requires publication in your main DNS zone.
-* Despite being RFC compliant, GPG has additional trust vectors for PKA but
-  not this, despite the fact that they share basically the same information.
-* Harder to verify with dig.
-
-#### Howto
-
-1. Note that some of these steps are redundant.  If you're already doing a PKA
-   key, skip to step 5.
-
-2. Dig:
-
-         %gpg --list-keys danm@prime.gushi.org
-         Warning: using insecure memory!
-         pub   1024D/624BB249 2000-10-02  <-- I'm going to use this one.
-         uid                  Daniel P. Mahoney <danm@prime.gushi.org>
-         uid                  Daniel Mahoney (Secondary Email) <gushi@gushi.org>
-         sub   2048g/DE20C529 2000-10-02
-         pub   1024R/309C17C5 1997-05-08
-         uid                  Daniel P. Mahoney <danm@prime.gushi.org>
-
-3. Export the key to a file (I use keyid.pub.asc, but it can be anything)
-
-         %gpg --export --armor 624BB249 > 624BB249.pub.asc
-         Warning: using insecure memory!
-         %
-
-4. Get the fingerprint for your key:
-
-         %gpg --list-keys --fingerprint 624BB249
-         gpg: WARNING: using insecure memory!
-         gpg: please see http://www.gnupg.org/faq.html for more information
-         pub   1024D/624BB249 2000-10-02
-         Key fingerprint = C206 3054 5492 95F3 3490  37FF FBBE 5A30 624B B249 <-- That bit is your fingerprint.
-         uid                  Daniel P. Mahoney <danm@prime.gushi.org>
-         uid                  Daniel Mahoney (Secondary Email) <gushi@gushi.org>
-         sub   2048g/DE20C529 2000-10-02
-
-5. As above, run make-dns-cert.  This time we use the -n, -f, and -u options:
-
-         %make-dns-cert -n danm.prime.gushi.org. -f C2063054549295F3349037FFFBBE5A30624BB249 -u http://prime.gushi.org/danm.pubkey.txt
-         danm.prime.gushi.org.   TYPE37  \# 64 0006 0000 00 14 C2063054549295F3349037FFFBBE5A30624BB249    687474703A2F2F7072696D652E67757368692E6F72672F64616E6D2E7075626B65792E747874
-         %
-
-
-6. Put the above in DNS.  All on one line.  Optionally add a TTL.
-
-7. IMPORTANT: make sure you don't have any other CERT records with the same
-   label (i.e. a "big" cert, as above).  While it won't break things, you have
-   no control over which (of multiple) people will get.
-
-8. Reload your zone, and test.  Testing will probably look VERY MUCH like the
-   above, but here are the steps anyway:
-
-#### Testing
-
-1.  Dig:
-
-         %dig +short danm.prime.gushi.org CERT
-         6 0 0 FMIGMFRUkpXzNJA3//u+WjBiS7JJaHR0cDovL3ByaW1lLmd1c2hpLm9y Zy9kYW5tLnB1YmtleS50eHQ=
-
-Sadly, I haven't come across an easy way to decipher it yet, but there's
-always gpg.
-
-2.  GPG:
-
-Since we're fetching the same kind of record, the command is exactly the same
-as before:
-
-     %echo "foo" | gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-key-locate cert -r  danm@prime.gushi.org
-     gpg: WARNING: using insecure memory!
-     gpg: please see http://www.gnupg.org/faq.html for more information
-     gpg: keyring `/tmp/gpg-39996' created
-     gpg: requesting key 624BB249 from http server prime.gushi.org
-     gpg: key 624BB249: public key "Daniel P. Mahoney <danm@prime.gushi.org>" imported
-     gpg: public key of ultimately trusted key CF45887D not found
-     gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
-     gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
-     gpg: Total number processed: 1
-     gpg:               imported: 1
-     gpg: automatically retrieved `danm@prime.gushi.org' via DNS CERT
-     gpg: DE20C529: There is no assurance this key belongs to the named user
-     pub  2048g/DE20C529 2000-10-02 Daniel P. Mahoney <danm@prime.gushi.org>
-     Primary key fingerprint: C206 3054 5492 95F3 3490  37FF FBBE 5A30 624B B249
-     Subkey fingerprint: CE40 B786 81E2 5CB9 F7D3  1318 9488 EB58 DE20 C529
-     It is NOT certain that the key belongs to the person named
-     in the user ID.  If you *really* know what you are doing,
-     you may answer the next question with yes.
-     Use this key anyway? (y/N) y
-     -----BEGIN PGP MESSAGE-----
-     Version: GnuPG v1.4.10 (FreeBSD)
-     hQIOA5SI61jeIMUpEAgApZurJi3hZmDaUFjB2j93eX/lTl96xq6T//sz6nT6jcTx
-     IPnq1RN8IrIQPjDBByHdqOZBT5hhblr9xi7NKIIv3W4q4L0z0fJx7NERPZNvn/H0
-     DkTwfDgAvCRxcKjenpLSwKZFwLjyfS7wjlDr3HFX7Tila0hbzplHslvgTE0QMcd7
-     7oNmEyOL3z+yZr/afQGp2wpzDv4YB9zOiNHcHcenqX0yrtiqKozZ9VAldi53rb/q
-     f38lwInbveyAcEQkE2iFwhRsbMR4VLcsBoxY6D9brsBprt23ey8Rnv+bQ9IAR0VN
-     /WYzU4zUUqb8HmpNFXQLEgH8A2BENw+bxkVYHjSfWQf/cBSGAzfBQQVJ7qp4tN0Z
-     FRVe51dokbU4NM9tGBdCzFHWARVkQX/Ulekd4F3sxBR/sum1UOT2xl2THVBz7/Pq
-     UCrTRPA0uH4dIbL5JpfGZhqsJ079+wmUWUtJIiO2wXi7ePEA/DrBC6p7jlmjyYN/
-     AeSKcPoTeLX+zryV5bECx4RO6S56EEcy0Ns0pASGMsgUnKL6Adrv3Y6ea3ZAOQMn
-     H9Uo28BKTKNUvUaBpN8cV8jIbKYPPW9i04kvEQRqs5rdamERCY1vVTqYTrcLsNqz
-     fF3KopX+V82X1oE2QuGdFfd8mK57ZXJL3VRUrfohQjhfYNKzougiP46rQQv79MYT
-     j8kazWyJUuufm6NVco1/35Zdp1UhHu8qTgXxrjo=
-     =zY9G
-     -----END PGP MESSAGE-----
-     %
-
-Strangely, the output doesn't say what PKA does (a PKA retrieval has a line
-about fetching via HTTP), however, by checking my webserver logs, I can see it
-retrieved it from there:
-
-     %tail -200 /usr/local/apache/logs/prime.gushi.org.log | grep pubkey | tail -1
-     prime.gushi.org 72.9.101.130 - - [28/Oct/2009:23:50:43 -0400] "GET /danm.pubkey.txt HTTP/1.1" 200 4337 "-" "-"
-     %
-
-As usual, test decryption, etc.  You're done.
-
-## Further Steps
-
-* Figure out which of these are useful to you, and use them.* When someone
-  asks for your public key, tell them to run the above command instead of
-  mailing them your key or sending them a keyserver URL.
-
-* Consider using the pka-related verify-options.
-
-* Look into embracing DNSSEC.  With a signed root, there's a good trust-path
-  vector here.  Who knows, maybe some day GPG will be dnssec-aware so it will
-  give more credit to a secure DNS transaction.  Without a signed root, there
-  are still ways to have those who care about security use it, through
-  services such as [ISC's DLV registry](http://dlv.isc.org).
-
-* On DNSSEC: At present, GPG cannot see the difference between an insecure
-  response (one from an unsigned zone) and a correctly validated one from a
-  signed zone.  (In a signed zone, an unsigned or malformed will simply get a
-  SERVFAIL dns response).  Look into sponsoring development of GPG to make it
-  as an application more aware of this.
-
-## A better way to generate records
-
-In reading over a lot of these commands, I've come across a few problems with
-the tools involved.  They either require you to assemble large records by
-hand, or manipulate huge files.
-
-DNS has also come a long way since these tools were written, and RFCs have
-solidified that have determined the "presentation format" (i.e. the "master
-file format") of what CERT records should look like.
-
-On top of everything, the make-dns-cert tool is not built by default, and is
-not present in most binary distributions (RPM's, deb packages, FreeBSD's
-ports).
-
-Thus, I took it upon myself to rewrite make-dns-cert as a shell script.
-
-### Advantages
-
-* Extracts your key for you (takes a keyid as the argument).
-* Formats all three record types for you, you can pipe it right into your zone
-  file.
-* Takes email address as an argument, generates record label.
-* No compiling needed.
-* Should work with most systems.  Requires openssl and sed, a few other
-  standard utilities.
-* Generates base64-ified CERT records, split into easy, manageable pieces.
-* Generates DNS-friendly comments, so repeating tasks are easy to reference.
-* (Eventually) available as a tarball, or as a paste-and-go script.
-* Arguments are in logical DNS record order `emailaddress keyid [url]`.
-* Will generate an IPGP CERT record without a URI (this is legal per RFC4398).
-
-You can see sample output
-[here](http://www.gushi.org/make-dns-cert/sample-output.txt), and you can view
-the script itself
-[here](http://www.gushi.org/make-dns-cert/make-dns-cert.sh.txt).  Depending on
-your MIME settings, you can probably get a download link if you go
-[here](http://www.gushi.org/make-dns-cert/make-dns-cert.sh).  If you see the
-script rather than getting a download prompt, you can just save-as.
-
-README, Changelog, TODO coming soon.
-
-## Other notes
-
-I'm not 100 percent sure (mainly because I haven't tried), but with IPGP cert,
-and PKA, I believe I could in theory point at a keyserver directly, for
-example, specify a uri of
-[http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB0307039309C17C5](http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB0307039309C17C5).
-I'm a bit dubious about the question marks and equals-signs, or if I might
-have to uri-encode things.  It's something to be tried.
-
-I'm trying to convince the GPG people that this would be much better adopted
-if the make-dns-cert tool was built/included by default, or if its function
-were included in gpg rather than a third-party tool.  This is analagous as to
-how dnssec-keygen is used to generate SSHFP DNS records.
-
-It doesn't do any actual cryptography, just some binary conversion, so in
-theory it could be rewritten in pure-perl, so there's nothing to compile.
-
-I've made the argument to the GPG developers that if multiple CERT records are
-available, all should be tried if one fails.  So far, if multiple exist, only
-the first received is parsed, and of course, DNS round-robins the answers by
-default.
-
-It took me quite a lot of trial and error to realize that there's a difference
-between "modern" RSA keys, like this:
-
-    %gpg --list-keys --fingerprint gushi@prime.gushi.org
-    pub   2048R/CF45887D 2009-10-29
-    Key fingerprint = FCB0 485E 050D DDFA 83C6  76E3 E722 3C05 CF45 887D
-    uid                  Gushi Test <gushi@prime.gushi.org>
-    sub   2048R/C9761244 2009-10-29
-
-and ancient RSA keys like this pgp2.6.2 monster:
-
-    %gpg --list-keys --fingerprint danm@prime.gushi.org
-    pub   1024R/309C17C5 1997-05-08
-    Key fingerprint = 04 4B 1A 2E C4 62 95 73  73 A4 EA D0 08 A4 45 76
-    uid                  Daniel P. Mahoney <danm@prime.gushi.org>
-
-Note the lack of a subkey there.  Note the weird fingerprint.  I have not been
-able to get this key to properly export with gpg.  If someone knows the Deep
-Magic, let me know.
-
-## References
-
-### Blog posts and list threads
-
-While researching this I came across little more than a few blog posts, and a
-few short discussions on the gpg-devel mailing list.
-
-* [A blog entry](http://www.df7cb.de/blog/2007/openpgp-dns.html) that seems to
-  have things mostly right.
-
-* [GPG Mailing List Discussion](http://lists.gnupg.org/pipermail/gnupg-users/2006-April/028314.html)
-  which seems to date towhen these features were first added.
-
-* [My own thread](http://www.mail-archive.com/gnupg-users@gnupg.org/msg12336.html)
-  on the gnupg-users mailing list that led upto this doc.
-
-* [A slideshow of a talk given on PKA](ftp://ftp.g10code.com/people/werner/talks/pka-intro.ps.gz)
-  (really the only doc I couldfind with regard to PKA).  Note that this is a
-  postscript doc, for reasons I cannot fathom.
-
-### RFCs
-
-* [RFC 3597](http://www.faqs.org/rfcs/rfc3597.html) defines the odd format of
-  the records that make-dns-cert generates, if itconfuses you.
-
-* [RFC 2538](http://www.faqs.org/rfcs/rfc2538.html), which was superseded by
-  [RFC4398](http://www.faqs.org/rfcs/rfc4398.html), defines the format for a
-  CERT record.
-
-## Todo
-
-* At least one GPG enthusiast has suggested to me that any tools I write to
-  handle keys should simply be able to insert themusing nsupdate.  I don't
-  disagree, but there's a complicated metric there as some of these require
-  manipulation of a site'smain zone, or at the very least, many subzones.  In
-  doing this I'd also like to find out a bit about how to do nsupdate
-  withsig(0) and KEY records, which with the right policies would mean I could
-  do this without touching named.conf.  That may be the subject of a whole
-  other howto.
-
-* (Done) I need to get the shell script cleaned up a bit more, and generate
-  proper docs, and start tracking it with version control.
-
-* I should probably get the gumption up to formally license all this stuff.
-  For right now, I declare it under the
-  [ISCLicense](http://en.wikipedia.org/wiki/ISC_license).
-
-* I'd like to track down the full list of supported URI types for PKA/IPGP
-  CERT records.  There doesn't seem to be a defined standard for it.
-
-## Epilogue
-
-### About the author
-
-Dan Mahoney is a Systems Admin in the Bay Area, California.  In his spare time
-he enjoys thinking for those brief fleeting moments what he would do if he had
-more free time.  Keyid 624BB249, or email address danm@prime.gushi.org.
-
-### About this Document
-
-This document was written in [gnu nano](http://nano-editor.org), and HTML was
-generated using [Markdown](http://daringfireball.net/projects/markdown).
-
-Markdown rocks.
-
-Originally published on my livejournal at
-[http://gushi.livejournal.com/524199.html](http://gushi.livejournal.com/524199.html),
-its main home is at
-[http://www.gushi.org/make-dns-cert/HOWTO.html](http://www.gushi.org/make-dns-cert/HOWTO.html),
-which is where later versions will be published.
-
-Free to use, comments to the above email address are welcome.
diff --git a/docs/DETAILS b/docs/DETAILS
deleted file mode 100644
index d5c5cea..0000000
--- a/docs/DETAILS
+++ /dev/null
@@ -1,1225 +0,0 @@
-# doc/DETAILS                                                -*- org -*-
-#+TITLE: GnuPG Details
-# Globally disable superscripts and subscripts:
-#+OPTIONS: ^:{}
-#
-
-# Note: This file uses org-mode; it should be easy to read as plain
-# text but be aware of some markup peculiarities: Verbatim code is
-# enclosed in #+begin-example, #+end-example blocks or marked by a
-# colon as the first non-white-space character, words bracketed with
-# equal signs indicate a monospace font, and the usual /italics/,
-# *bold*, and _underline_ conventions are recognized.
-
-This is the DETAILS file for GnuPG which specifies some internals and
-parts of the external API for GPG and GPGSM.
-
-* Format of the colon listings
-  The format is a based on colon separated record, each recods starts
-  with a tag string and extends to the end of the line.  Here is an
-  example:
-#+begin_example
-$ gpg --with-colons --list-keys \
-      --with-fingerprint --with-fingerprint wk@gnupg.org
-pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
-fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
-uid:f::::::::Werner Koch :
-uid:f::::::::Werner Koch :
-sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
-fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
-sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
-fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:
-#+end_example
-
-The double =--with-fingerprint= prints the fingerprint for the subkeys
-too.  Old versions of gpg used a lighly different format and required
-the use of the option =--fixed-list-mode= to conform to format
-described here.
-
-** Description of the fields
-*** Field 1 - Type of record
-
-    - pub :: Public key
-    - crt :: X.509 certificate
-    - crs :: X.509 certificate and private key available
-    - sub :: Subkey (secondary key)
-    - sec :: Secret key
-    - ssb :: Secret subkey (secondary key)
-    - uid :: User id (only field 10 is used).
-    - uat :: User attribute (same as user id except for field 10).
-    - sig :: Signature
-    - rev :: Revocation signature
-    - fpr :: Fingerprint (fingerprint is in field 10)
-    - pkd :: Public key data [*]
-    - grp :: Keygrip
-    - rvk :: Revocation key
-    - tru :: Trust database information [*]
-    - spk :: Signature subpacket [*]
-    - cfg :: Configuration data [*]
-
-    Records marked with an asterisk are described at [[*Special%20field%20formats][*Special fields]].
-
-*** Field 2 - Validity
-
-    This is a letter describing the computed validity of a key.
-    Currently this is a single letter, but be prepared that additional
-    information may follow in some future versions. Note that GnuPG <
-    2.1 does not set this field for secret key listings.
-
-    - o :: Unknown (this key is new to the system)
-    - i :: The key is invalid (e.g. due to a missing self-signature)
-    - d :: The key has been disabled
-	   (deprecated - use the 'D' in field 12 instead)
-    - r :: The key has been revoked
-    - e :: The key has expired
-    - - :: Unknown validity (i.e. no value assigned)
-    - q :: Undefined validity.  '-' and 'q' may safely be treated as
-           the same value for most purposes
-    - n :: The key is not valid
-    - m :: The key is marginal valid.
-    - f :: The key is fully valid
-    - u :: The key is ultimately valid.  This often means that the
-           secret key is available, but any key may be marked as
-           ultimately valid.
-    - w :: The key has a well known private part.
-    - s :: The key has special validity.  This means that it might be
-           self-signed and expected to be used in the STEED sytem.
-
-    If the validity information is given for a UID or UAT record, it
-    describes the validity calculated based on this user ID.  If given
-    for a key record it describes the validity taken from the best
-    rated user ID.
-
-    For X.509 certificates a 'u' is used for a trusted root
-    certificate (i.e. for the trust anchor) and an 'f' for all other
-    valid certificates.
-
-*** Field 3 - Key length
-
-    The length of key in bits.
-
-*** Field 4 - Public key algorithm
-
-    The values here are those from the OpenPGP specs or if they are
-    greather than 255 the algorithm ids as used by Libgcrypt.
-
-*** Field 5 - KeyID
-
-    This is the 64 bit keyid as specified by OpenPGP and the last 64
-    bit of the SHA-1 fingerprint of an X.509 certifciate.
-
-*** Field 6 - Creation date
-
-    The creation date of the key is given in UTC.  For UID and UAT
-    records, this is used for the self-signature date.  Note that the
-    date is usally printed in seconds since epoch, however, we are
-    migrating to an ISO 8601 format (e.g. "19660205T091500").  This is
-    currently only relevant for X.509.  A simple way to detect the new
-    format is to scan for the 'T'.  Note that old versions of gpg
-    without using the =--fixed-list-mode= option used a "yyyy-mm-tt"
-    format.
-
-*** Field 7 - Expiration date
-
-    Key or UID/UAT expiration date or empty if it does not expire.
-
-*** Field 8 - Certificate S/N, UID hash, trust signature info
-
-    Used for serial number in crt records.  For UID and UAT records,
-    this is a hash of the user ID contents used to represent that
-    exact user ID.  For trust signatures, this is the trust depth
-    seperated by the trust value by a space.
-
-*** Field 9 -  Ownertrust
-
-    This is only used on primary keys.  This is a single letter, but
-    be prepared that additional information may follow in future
-    versions.  For trust signatures with a regular expression, this is
-    the regular expression value, quoted as in field 10.
-
-*** Field 10 - User-ID
-    The value is quoted like a C string to avoid control characters
-    (the colon is quoted =\x3a=).  For a "pub" record this field is
-    not used on --fixed-list-mode.  A UAT record puts the attribute
-    subpacket count here, a space, and then the total attribute
-    subpacket size.  In gpgsm the issuer name comes here.  A FPR
-    record stores the fingerprint here.  The fingerprint of a
-    revocation key is stored here.
-*** Field 11 - Signature class
-
-    Signature class as per RFC-4880.  This is a 2 digit hexnumber
-    followed by either the letter 'x' for an exportable signature or
-    the letter 'l' for a local-only signature.  The class byte of an
-    revocation key is also given here, 'x' and 'l' is used the same
-    way.  This field if not used for X.509.
-
-*** Field 12 - Key capabilities
-
-    The defined capabilities are:
-
-    - e :: Encrypt
-    - s :: Sign
-    - c :: Certify
-    - a :: Authentication
-    - ? :: Unknown capability
-
-    A key may have any combination of them in any order.  In addition
-    to these letters, the primary key has uppercase versions of the
-    letters to denote the _usable_ capabilities of the entire key, and
-    a potential letter 'D' to indicate a disabled key.
-
-*** Field 13 - Issuer certificate fingerprint or other info
-
-    Used in FPR records for S/MIME keys to store the fingerprint of
-    the issuer certificate.  This is useful to build the certificate
-    path based on certificates stored in the local key database it is
-    only filled if the issuer certificate is available. The root has
-    been reached if this is the same string as the fingerprint. The
-    advantage of using this value is that it is guaranteed to have
-    been been build by the same lookup algorithm as gpgsm uses.
-
-    For "uid" records this field lists the preferences in the same way
-    gpg's --edit-key menu does.
-
-    For "sig" records, this is the fingerprint of the key that issued
-    the signature.  Note that this is only filled in if the signature
-    verified correctly.  Note also that for various technical reasons,
-    this fingerprint is only available if --no-sig-cache is used.
-
-*** Field 14 - Flag field
-
-    Flag field used in the --edit menu output
-
-*** Field 15 - S/N of a token
-
-    Used in sec/sbb to print the serial number of a token (internal
-    protect mode 1002) or a '#' if that key is a simple stub (internal
-    protect mode 1001)
-
-*** Field 16 - Hash algorithm
-
-    For sig records, this is the used hash algorithm.  For example:
-    2 = SHA-1, 8 = SHA-256.
-
-** Special fields
-
-*** PKD - Public key data
-
-    If field 1 has the tag "pkd", a listing looks like this:
-#+begin_example
-pkd:0:1024:B665B1435F4C2 .... FF26ABB:
-    !  !   !-- the value
-    !  !------ for information number of bits in the value
-    !--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
-#+end_example
-
-*** TRU - Trust database information
-    Example for a "tru" trust base record:
-#+begin_example
-    tru:o:0:1166697654:1:3:1:5
-#+end_example
-
-    - Field 2 :: Reason for staleness of trust.  If this field is
-                 empty, then the trustdb is not stale.  This field may
-                 have multiple flags in it:
-
-                 - o :: Trustdb is old
-                 - t :: Trustdb was built with a different trust model
-                        than the one we are using now.
-
-    - Field 3 :: Trust model
-
-                 - 0 :: Classic trust model, as used in PGP 2.x.
-                 - 1 :: PGP trust model, as used in PGP 6 and later.
-                        This is the same as the classic trust model,
-                        except for the addition of trust signatures.
-
-                 GnuPG before version 1.4 used the classic trust model
-                 by default. GnuPG 1.4 and later uses the PGP trust
-                 model by default.
-
-    - Field 4 :: Date trustdb was created in seconds since Epoch.
-    - Field 5 :: Date trustdb will expire in seconds since Epoch.
-    - Field 6 :: Number of marginally trusted users to introduce a new
-                 key signer (gpg's option --marginals-needed).
-    - Field 7 :: Number of completely trusted users to introduce a new
-                 key signer.  (gpg's option --completes-needed)
-
-    - Field 8 :: Maximum depth of a certification chain. (gpg's option
-                 --max-cert-depth)
-
-*** SPK - Signature subpacket records
-
-    - Field 2 :: Subpacket number as per RFC-4880 and later.
-    - Field 3 :: Flags in hex.  Currently the only two bits assigned
-                 are 1, to indicate that the subpacket came from the
-                 hashed part of the signature, and 2, to indicate the
-                 subpacket was marked critical.
-    - Field 4 :: Length of the subpacket.  Note that this is the
-                 length of the subpacket, and not the length of field
-                 5 below.  Due to the need for %-encoding, the length
-                 of field 5 may be up to 3x this value.
-    - Field 5 :: The subpacket data.  Printable ASCII is shown as
-                 ASCII, but other values are rendered as %XX where XX
-                 is the hex value for the byte.
-
-*** CFG - Configuration data
-
-    --list-config outputs information about the GnuPG configuration
-    for the benefit of frontends or other programs that call GnuPG.
-    There are several list-config items, all colon delimited like the
-    rest of the --with-colons output.  The first field is always "cfg"
-    to indicate configuration information.  The second field is one of
-    (with examples):
-
-    - version :: The third field contains the version of GnuPG.
-
-                 : cfg:version:1.3.5
-
-    - pubkey :: The third field contains the public key algorithms
-                this version of GnuPG supports, separated by
-                semicolons.  The algorithm numbers are as specified in
-                RFC-4880.  Note that in contrast to the --status-fd
-                interface these are _not_ the Libgcrypt identifiers.
-
-                 : cfg:pubkey:1;2;3;16;17
-
-    - cipher :: The third field contains the symmetric ciphers this
-                version of GnuPG supports, separated by semicolons.
-                The cipher numbers are as specified in RFC-4880.
-
-                 : cfg:cipher:2;3;4;7;8;9;10
-
-    - digest :: The third field contains the digest (hash) algorithms
-                this version of GnuPG supports, separated by
-                semicolons.  The digest numbers are as specified in
-                RFC-4880.
-
-                 : cfg:digest:1;2;3;8;9;10
-
-    - compress :: The third field contains the compression algorithms
-                  this version of GnuPG supports, separated by
-                  semicolons.  The algorithm numbers are as specified
-                  in RFC-4880.
-
-                 : cfg:compress:0;1;2;3
-
-    - group :: The third field contains the name of the group, and the
-               fourth field contains the values that the group expands
-               to, separated by semicolons.
-
-               For example, a group of:
-                 : group mynames = paige 0x12345678 joe patti
-               would result in:
-                 : cfg:group:mynames:patti;joe;0x12345678;paige
-
-
-* Format of the --status-fd output
-
-  Every line is prefixed with "[GNUPG:] ", followed by a keyword with
-  the type of the status line and some arguments depending on the type
-  (maybe none); an application should always be prepared to see more
-  arguments in future versions.
-
-** General status codes
-*** NEWSIG
-    May be issued right before a signature verification starts.  This
-    is useful to define a context for parsing ERROR status messages.
-    No arguments are currently defined.
-
-*** GOODSIG    
-    The signature with the keyid is good.  For each signature only one
-    of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or
-    ERRSIG will be emitted.  In the past they were used as a marker
-    for a new signature; new code should use the NEWSIG status
-    instead.  The username is the primary one encoded in UTF-8 and %XX
-    escaped. The fingerprint may be used instead of the long keyid if
-    it is available.  This is the case with CMS and might eventually
-    also be available for OpenPGP.
-
-*** EXPSIG    
-    The signature with the keyid is good, but the signature is
-    expired. The username is the primary one encoded in UTF-8 and %XX
-    escaped. The fingerprint may be used instead of the long keyid if
-    it is available.  This is the case with CMS and might eventually
-    also be available for OpenPGP.
-
-*** EXPKEYSIG   
-    The signature with the keyid is good, but the signature was made
-    by an expired key. The username is the primary one encoded in
-    UTF-8 and %XX escaped.  The fingerprint may be used instead of the
-    long keyid if it is available.  This is the case with CMS and
-    might eventually also be available for OpenPGP.
-
-*** REVKEYSIG    
-    The signature with the keyid is good, but the signature was made
-    by a revoked key. The username is the primary one encoded in UTF-8
-    and %XX escaped. The fingerprint may be used instead of the long
-    keyid if it is available.  This is the case with CMS and might
-    eventually also beƱ available for OpenPGP.
-
-*** BADSIG    
-    The signature with the keyid has not been verified okay.  The
-    username is the primary one encoded in UTF-8 and %XX escaped. The
-    fingerprint may be used instead of the long keyid if it is
-    available.  This is the case with CMS and might eventually also be
-    available for OpenPGP.
-
-*** ERRSIG