diff options
Diffstat (limited to 'docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md')
| -rw-r--r-- | docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md | 832 |
1 files changed, 832 insertions, 0 deletions
diff --git a/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md b/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md new file mode 100644 index 0000000..5112c97 --- /dev/null +++ b/docs/Complete-Guide-to-Publishing-OpenPGP-in-DNS.md @@ -0,0 +1,832 @@ +<!-- + +Livejournal Introduction: + +I recently wrestled with something, learned quite a lot, and came up with a document that I'm really rather proud of, that +shares knowledge that's not all out there in one place anywhere else. Along the way I've written some software that I'm +releasing, that makes all of what I've learned a lot easier, and may help make the world a little more secure. I'd like to +share it here. + +This is going to be a technical post. For that I apologize. The target of this post is anyone who has a GPG key that they'd +like to expand to a greater audience, and who controls DNS for any of the email domains they publish. Anyone that I host DNS +or mail for is also welcome to do this, if you use PGP, as part of the goal of writing this is to encourage adoption and use +of these methods + +<lj-cut text="This will be long and technical"> +--> + +# 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 + <pre>`%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. |