Re: A lot of questions about CERT, PKA and make-dns-cert
On Wed, 21 Oct 2009, David Shaw wrote: On Oct 20, 2009, at 10:55 PM, Dan Mahoney, System Admin wrote: On Thu, 15 Oct 2009, David Shaw wrote: On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote: I'm running: echo foo | gpg -v -v --auto-key-locate cert --recipient gu...@gushi.org --encrypt -a And get gpg: error retrieving `gu...@gushi.org' via DNS CERT: No fingerprint I exported my key with: gpg --export --export-options minimal file; and make-dns-cert -n gushi.gushi.org -f file It works fine for me. What version of GPG are you using? I tried this again, after I nuked the fingerprint cert record. Oddly, running on gpg2 on an older debian system, I get: # echo foo | gpg2 -v -v --auto-key-locate cert --encrypt -r gu...@gushi.org gpg: no keyserver known (use option --keyserver) gpg: error retrieving `gu...@gushi.org' via DNS CERT: General error gpg: gu...@gushi.org: skipped: General error gpg: [stdin]: encryption failed: General error That first line specifically makes me scratch my head a bit. You didn't give an actual version number (run gpg2 --version), so I can only make an educated guess, but I do think I see your problem. You don't have one key in your CERT - you have two (309C17C5 and 624BB249) combined into one DNS record. That doesn't work - it's a one-name-one-key mapping. We should give a better error message in this case. Can you try again with a single key in your CERT? Alternately, if you want both of your keys, you could use 2 different CERT records for the gushi.gushi.org. name, each with one of your keys (rather than 1 CERT record with a payload containing two keys). Note that this will usually result in round-robining for those people who don't have your key, which may or may not be what you want. For the benefit of people who may search this later, what's the best set of args to extract the key with? Neither export-clean nor export-minimal seems to be what I want. In effect what I want is only the most recent signature from each other key, so some hybrid of export-clean and export-minimal? At least using gpg 2.0.13, and a single key in the CERT, this works properly for me. I can't speak for an earlier version. All of that said, I think it's worth pointing out that IPGP (the fingerprint+URL variation of CERT) is far more useful that PGP (the full key). Not all systems are going to be able to pass a 1718-byte DNS message, as yours is. As DNSSEC becomes more widely adopted, as EDNS0 and TCPDNS become more the norm, this is less of an issue. IPGP is also little more than a standards-based version of HKP, which I'm also publishing. If I've uncommented the line in options.skel (present in some distros, not others), the order will be: #auto-key-locate cert pka ldap hkp://subkeys.pgp.net (one of my other pet peeves is that gpg hangs up on unknown options, instead of falling to the next, so if I haven't compiled with LDAP support that whole line will break things. Is this worth filing a bug?) Anyway, if we assume most people just say yeah sounds good and uncomment the option, pka is a chance to get info out if CERT fails. Why would I duplicate the same info? If I've published an IPGP cert, and it fails to validate, the same info in PKA won't fare any better. Since there's no way to reliably publish both forms of CERT and have the client able to request one or the other (or parse all records until we find one that works, instead of the first it gets), the PGP variant actually gets the key out there in a case where the URL is unretrievable (for example, behind a firewall where outbound finger is blocked, or in a case where we're compiled without curl support, but hitting a host that requires HTTP 1.1). Put another way, with PGP, all the info you need is in the DNS packets. With IPGP, you have another step to chase down. Only parsing one CERT response also prevents one from putting in multiple keys with the same key retrievable via multiple URIs, i.e. one finger, one http, etc. (On a related note, I can't specify multiple keyservers to search on the command line or in my config file, which is also annoying, is this worth filing a bug?). Is the way a CERT record is parsed (i.e. only parsing the first one) goverened by an RFC? Or considering the likely little use this is getting, do you feel it's too late in the game to change the way multiple records would be handled? This is also why I asked for a list of what uri formats are supported, and it would help me to know which of those are retrievable by default with no external libs. Given an HTTPS-capable webserver where I also control vhost order, if I only have one URI-format to publish, what's my best chance to have this support the most clients? Hell, can one put an hkp:// uri in that URL field? I suspect strongly that this feature doesn't get the most broad platform testing. Let me know if you'd like to help. Please do! More
Re: A lot of questions about CERT, PKA and make-dns-cert
On Wed, 21 Oct 2009, David Shaw wrote: You didn't give an actual version number (run gpg2 --version), so I can only make an educated guess, but I do think I see your problem. You don't have one key in your CERT - you have two (309C17C5 and 624BB249) combined into one DNS record. That doesn't work - it's a one-name-one-key mapping. We should give a better error message in this case. Aah, yes, there we go. Now it seems to work on all my systems. For some reason I assumed --export would just pick one key to match on, just as --delete-keys does. Note there's still a secondary key, hence my confusion. So far, the commands for a PGP CERT are: gpg --list-keys gu...@gushi.org (read, get key id) gpg2 --export --export-options export-clean keyid.pub.bin -or- gpg2 --export --export-options export-minimal keyid.pub.bin make-dns-cert -k keyid.pub.bin -n gushi.gushi.org. keyid.dnscert The commands for an IPGP cert are: gpg --list-keys y...@you.com Choose your keyid from the above. gpg2 --export --armor keyid keyid.pub.asc copy the ascii file somewhere where it's url accessable. Manually copy/paste your fingerprint into the next command: make-dns-cert -n gushi.gushi.org. -u url format (which?) -f fingerprint keyid.dnscert Then, publish one (and only one) CERT record in dns per-label. In my case this also means signing the zone and all that. Finally, for an _PKA record, it involves manually: u...@domain.com becomes user._pka.domain.com. Get your keyid as above. 1) Export to a uri as for IPGP cert, above (presumably, it can be the same uri). Strip your fingerprint like so: 2) gpg --fingerprint keyid | grep Key fingerprint | cut -d = -f 2 | sed 's/ *//g' The format of the text record is simple: you._pka.domain.com. IN TXT v=pka1;fpr=[#1];uri=[#2] Where the values are substituted from the steps above. Publish this in DNS. Test using: dig you._pka.domain.com TXT, see if you get a result. Test with a GPG client that doesn't otherwise have the key: echo foo | gpg --auto-key-locate pka --armor --encrypt -r y...@domain.com and see if you get an output. So here's the laundry list: 0) Do the above look mostly-right? 1) What are the best options for exporting certs for a CERT record? For a uri-styled record? (i.e. which signatures do you want to include?) 2) Do either the pka or the IPGP standards require the key to be in binary/ascii format? 3) What's the sanctioned list of uri formats? Where is it defined for CERT? For PKA? 4) As I'm not a c-coder, how difficult would it be to have the make-dns-cert output in base64 instead of binary? 5) How solid is the output of --fingerprint? Is it likely to change between versions, or are the grep and sed listed likely to work most places? 6) How difficult would it be to get the cert-export functions right into gpg? 7) How difficult would it be to get make-dns-cert built-by-default? 8) (asked previously) Is it worth filing a bug on not being able to specify multiple keyservers for auto-key-locate? 9) (also previously) Is it worth filing a bug to not have auto-key-locate vomit on unsupported methods? With the answers to the above, I'll write up a nice howto doc including the prereqs for all the above, the DNS requirements, and the like. -Dan -- It's three o'clock in the morning. It's too late for 'oops'. After Locate Updates, don't even go there. -Paul Baecker January 3, 2k Indeed, sometime after 3AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A lot of questions about CERT, PKA and make-dns-cert
On Thu, 15 Oct 2009, David Shaw wrote: On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote: I'm running: echo foo | gpg -v -v --auto-key-locate cert --recipient gu...@gushi.org --encrypt -a And get gpg: error retrieving `gu...@gushi.org' via DNS CERT: No fingerprint I exported my key with: gpg --export --export-options minimal file; and make-dns-cert -n gushi.gushi.org -f file It works fine for me. What version of GPG are you using? I tried this again, after I nuked the fingerprint cert record. Oddly, running on gpg2 on an older debian system, I get: # echo foo | gpg2 -v -v --auto-key-locate cert --encrypt -r gu...@gushi.org gpg: no keyserver known (use option --keyserver) gpg: error retrieving `gu...@gushi.org' via DNS CERT: General error gpg: gu...@gushi.org: skipped: General error gpg: [stdin]: encryption failed: General error That first line specifically makes me scratch my head a bit. (The gpg manpage also appears to be a bit corrupted on this system). On my bsd system, I get what you see at http://www.gushi.org/gpg.txt. It retrieves the key, but complains of no fingerprint, however it actually DOES import the key, so it works a second time. If you require a shell to play with this, let me know and I'll provide one. With the demise of thawte's free cert offering, I'd really like to do what I can to increase awareness of this stuff. On my ubuntu desktop, it works fine. I suspect strongly that this feature doesn't get the most broad platform testing. Let me know if you'd like to help. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A lot of questions about CERT, PKA and make-dns-cert
On Oct 20, 2009, at 10:55 PM, Dan Mahoney, System Admin wrote: On Thu, 15 Oct 2009, David Shaw wrote: On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote: I'm running: echo foo | gpg -v -v --auto-key-locate cert --recipient gu...@gushi.org --encrypt -a And get gpg: error retrieving `gu...@gushi.org' via DNS CERT: No fingerprint I exported my key with: gpg --export --export-options minimal file; and make-dns-cert -n gushi.gushi.org -f file It works fine for me. What version of GPG are you using? I tried this again, after I nuked the fingerprint cert record. Oddly, running on gpg2 on an older debian system, I get: # echo foo | gpg2 -v -v --auto-key-locate cert --encrypt -r gu...@gushi.org gpg: no keyserver known (use option --keyserver) gpg: error retrieving `gu...@gushi.org' via DNS CERT: General error gpg: gu...@gushi.org: skipped: General error gpg: [stdin]: encryption failed: General error That first line specifically makes me scratch my head a bit. You didn't give an actual version number (run gpg2 --version), so I can only make an educated guess, but I do think I see your problem. You don't have one key in your CERT - you have two (309C17C5 and 624BB249) combined into one DNS record. That doesn't work - it's a one-name-one-key mapping. We should give a better error message in this case. Can you try again with a single key in your CERT? Alternately, if you want both of your keys, you could use 2 different CERT records for the gushi.gushi.org. name, each with one of your keys (rather than 1 CERT record with a payload containing two keys). Note that this will usually result in round-robining for those people who don't have your key, which may or may not be what you want. At least using gpg 2.0.13, and a single key in the CERT, this works properly for me. I can't speak for an earlier version. All of that said, I think it's worth pointing out that IPGP (the fingerprint+URL variation of CERT) is far more useful that PGP (the full key). Not all systems are going to be able to pass a 1718-byte DNS message, as yours is. I suspect strongly that this feature doesn't get the most broad platform testing. Let me know if you'd like to help. Please do! More testing is always welcome. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A lot of questions about CERT, PKA and make-dns-cert
On Fri, 16 Oct 2009 05:27, ds...@jabberwocky.com said: Even if the documentation was better (and I agree, it is poorly documented), I don't think CERT or PKA would be a very widely used FWIW: At least for PKA that is my fault. I once wrote a paper for it in German and presented it at the GUUG house conference. Unfortunately I had no time to pursue the PKA idea further or to translate the paper. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
A lot of questions about CERT, PKA and make-dns-cert
All, I'm in the process of writing a blog entry about the PKA and CERT methods. A couple people have written them a long time ago, and I'd like to bring some of the info up to date. (If this is better asked on gnupg-dev, let me know). For starters: 1) Currently the only tool that can generate a CERT record, make-dns-cert, is not built or packaged by default under any os I've found (I've tried FreeBSD and ubuntu). It has no documentation, no examples, and only a terse 4-line usage summary. I've also seen a few bugs reported with it, that I don't know if they're fixed, such as not handling whitespace in the key fingerprint properly. 2) I realize this is a fringe feature, but other than a few scattered blog posts that reference each other, some of which are written by gnupg developers, info on these methods is HARD TO FIND. There's nothing in the docs/faq about this, at all. I think adoption would be much more widespread if this were a faq-able item. It's mentioned once in the manpage, once in the default gnupg.conf, and that's really it. If you document it, people will use it (and with thawte dropping personal freemail certs lately, this is something you want). 3) As far as I know, PKA isn't standardized in any RFC. Has this been changed? I saw mention of applying to IANA for its own typecode. Is there a list somewhere of what uri types are supported? I saw talk of it not supporting http 1.1, but that may be fixed with curl. Of the two methods, I tend to actually prefer PKA because it lets me delegate _pka.example.com to its own sub-zone, whereas CERT records must be inserted into the main zone. 4) Try though I might, I can't seem to get my full-key in CERT format to recognize. I am not sure if this is because my key is complicated (i.e. it has subkeys), because the cert is not under my primary uid, or because I just plain exported it wrong. I'm running: echo foo | gpg -v -v --auto-key-locate cert --recipient gu...@gushi.org --encrypt -a And get gpg: error retrieving `gu...@gushi.org' via DNS CERT: No fingerprint I exported my key with: gpg --export --export-options minimal file; and make-dns-cert -n gushi.gushi.org -f file It's still live if anyone wants to try. 5) Finally, the quality of records being generated, while consistent with rfc3597, leaves them as a real bear to manage, and import. If you're going to export them in hex, could we please also get whitespace so we can get this into an editor easily? Ideally, the things would just be base64 encoded, in accordance with rfc4398. Most versions of bind9 understand the CERT record, with base64 representation, and numeric typecodes. bind9.6 understands the PGP type value mnemonic but not IPGP. BIND 9.7 understands IPGP. What would be really, really cool, is step by step instructions for exporting, or hell, let gpg generate these records, the way ssh-keygen generates SSHFP records. Those are my thoughts. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A lot of questions about CERT, PKA and make-dns-cert
On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote: 1) Currently the only tool that can generate a CERT record, make-dns- cert, is not built or packaged by default under any os I've found (I've tried FreeBSD and ubuntu). It has no documentation, no examples, and only a terse 4-line usage summary. I've also seen a few bugs reported with it, that I don't know if they're fixed, such as not handling whitespace in the key fingerprint properly. The whitespace issue was handled back in 2006 (one day after the program was added to GnuPG, as it happens). Possibly you saw an email from someone who was tracking the code repository in between releases. There is no version of GnuPG that was ever released with the bug. 2) I realize this is a fringe feature, but other than a few scattered blog posts that reference each other, some of which are written by gnupg developers, info on these methods is HARD TO FIND. There's nothing in the docs/faq about this, at all. I think adoption would be much more widespread if this were a faq-able item. It's mentioned once in the manpage, once in the default gnupg.conf, and that's really it. If you document it, people will use it (and with thawte dropping personal freemail certs lately, this is something you want). Even if the documentation was better (and I agree, it is poorly documented), I don't think CERT or PKA would be a very widely used feature. The reality is that the majority of users do not have the kind of access to DNS that CERT requires. PKA is a bit better in this regard as it uses TXT records, which can at least be used by people who have some web-based DNS configuration for their domain. I don't know of many of those configuration tools that do CERT at all (we're talking text-files-and-bind usually for CERT). Whether TXT or CERT, though, it's a fairly high barrier for many users. I do encourage you to document it better, and I'm willing to help explain wherever necessary, or make code changes if there is something that could be done better. 3) As far as I know, PKA isn't standardized in any RFC. Has this been changed? I saw mention of applying to IANA for its own typecode. Is there a list somewhere of what uri types are supported? I saw talk of it not supporting http 1.1, but that may be fixed with curl. If you build GnuPG with curl (which is the default, assuming you have curl), then you have HTTP 1.1 support. That said, is there a particular HTTP 1.1 feature that you need here? After the PKA parsing happens, GPG is just doing a regular HTTP GET. 4) Try though I might, I can't seem to get my full-key in CERT format to recognize. I am not sure if this is because my key is complicated (i.e. it has subkeys), because the cert is not under my primary uid, or because I just plain exported it wrong. I'm running: echo foo | gpg -v -v --auto-key-locate cert --recipient gu...@gushi.org --encrypt -a And get gpg: error retrieving `gu...@gushi.org' via DNS CERT: No fingerprint I exported my key with: gpg --export --export-options minimal file; and make-dns-cert -n gushi.gushi.org -f file It works fine for me. What version of GPG are you using? Incidentally, you have two different CERT records for gushi.gushi.org at the same time. You have both a fingerprint-style answer and a full- key answer. This is not a major problem (GPG won't care - it'll just take the first one that parses), but if your nameserver does some sort of round-robining, it can be confusing as to which record is the one that gets used. 5) Finally, the quality of records being generated, while consistent with rfc3597, leaves them as a real bear to manage, and import. If you're going to export them in hex, could we please also get whitespace so we can get this into an editor easily? Ideally, the things would just be base64 encoded, in accordance with rfc4398. Most versions of bind9 understand the CERT record, with base64 representation, and numeric typecodes. bind9.6 understands the PGP type value mnemonic but not IPGP. BIND 9.7 understands IPGP. When I wrote the code, precious few nameservers understood any of this (and none understood IPGP at all - that patch only went into BIND a few months ago). That's why the record is TYPE37 and not CERT. It's ugly, but it was the least common denominator. It has been a few years since then. Possibly it's time to upgrade. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A lot of questions about CERT, PKA and make-dns-cert
On Thu, 15 Oct 2009, David Shaw wrote: David, For starters let me thank you on both the fullness and the expedience of your answer. Far too many open source projects just go crickets when I send out a laundry list, and I need to recognize your time. Let me also apologize in advance for my wordiness. We have quite a bit of ground to cover. On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote: 1) Currently the only tool that can generate a CERT record, make-dns-cert, is not built or packaged by default under any os I've found (I've tried FreeBSD and ubuntu). It has no documentation, no examples, and only a terse 4-line usage summary. I've also seen a few bugs reported with it, that I don't know if they're fixed, such as not handling whitespace in the key fingerprint properly. I was referencing this thread: http://lists.gnupg.org/pipermail/gnupg-users/2006-April/028314.html If that's no longer the case, then no worry. I suppose if doc were more abundant I wouldn't have had to pore over old mailing list entries looking for examples :) The few examples I've seen online as to how to use this have the FP whitespace-stripped, so I assumed it was done so deliberately to work around that, and I did the same. Whether TXT or CERT, though, it's a fairly high barrier for many users. True, and sadly, applying for a separate typecode would be an additional barrier to entry there. (SPF made TXT what it is today!) Is there a formal spec document? The most I could find was a PDF slideshow. I do encourage you to document it better, and I'm willing to help explain wherever necessary, or make code changes if there is something that could be done better. Docs, I'm totally on. I'm trying as much as I can to link to the standards docs as well, which is why I was asking for a supported-uri-format doc. Ideally there should be something in the gpg faq, something in the manpage, and at least a small README in tools that covers all the things in there (maybe we can talk about what the rest of those do as well). If you really feel up to making code changes: gpg --export --format cert-PGP d...@prime.gushi.org gpg --export --format cert-IPGP gu...@gushi.org [--url=http://foo] gpg --export --format pka f...@bar.com --url=http://foo Some variation on the above would all be wonderful, but I don't think I'm likely to get that wish granted. One of the tutorials I saw made reference of using pgp-clean -- what is the gnupg equivalent of this? If you build GnuPG with curl (which is the default, assuming you have curl), then you have HTTP 1.1 support. That said, is there a particular HTTP 1.1 feature that you need here? After the PKA parsing happens, GPG is just doing a regular HTTP GET. No, I'm just looking for a full list of what you can put in the uri= portion of a _pka record. I never found it enumerated. Is https supported? If so, does the system do cert validation? I've seen finger and http, but wouldn't know where in the code to try to read to figure out the full list. I also didn't find a clear listing of what format the key should be in, although the finger hinted at the usual armored format. From a code end, I'd like to know for sure if either/both work. 4) Try though I might, I can't seem to get my full-key in CERT format to recognize. It works fine for me. What version of GPG are you using? gpg (GnuPG) 2.0.12 libgcrypt 1.4.4 When you say it works for you, do you mean you're able to parse my key, or that you've been able to publish and retrieve your own CERT-PGP record? If I nuke things down to my single cert-ipgp record, could you try again? Incidentally, you have two different CERT records for gushi.gushi.org at the same time. You have both a fingerprint-style answer and a full-key answer. This is not a major problem (GPG won't care - it'll just take the first one that parses), but if your nameserver does some sort of round-robining, it can be confusing as to which record is the one that gets used. I did that because it complained about having no fingerprint, so I thought for a moment it needed both kinds, one with the key, and a separate one with the FP. Most versions of bind9 understand the CERT record, with base64 representation, and numeric typecodes. bind9.6 understands the PGP type value mnemonic but not IPGP. BIND 9.7 understands IPGP. The cert is a single, long, unbroken hex string. BIND will understand it if you chuck it into an include file or paste it in with a non-wrapping editor. But it's fragile and unwieldly. If you feel like carefully counting characters, you can wrap it, as long as you hit a hex boundary. Adding a few spaces and parens would make it just work if wrapped. And the presentation format should be base64, not binary (dnssec-signzone will convert both _pka and CERT records to this format anyway). When I wrote the code, precious few nameservers understood any of this (and
