Re: GNUPG HELP please
Great!! Signed and edit key ...Works like a charm. Thank you Daniel Kahn Gillmor d...@fifthhorseman.net 10/14/2009 4:40 PM Hi Connie-- I'm glad that was useful. On 10/14/2009 05:07 PM, CONNIE RODRIGUEZ wrote: I attempted key signing but was not successful. I received the following output: [la...@lsftest1/usr/local/bin # ./gpg --edit-key REWARD pub 1024D/C2126D6D created: 2009-02-23 expires: never usage: SC trust: unknown validity: unknown sub 2048g/4D5AFE2E created: 2009-02-23 expires: never usage: E [ unknown] (1). REWARD data interchange 2009 Command sign gpg: no default secret key: secret key not available Command Any help is appreciated! It sounds to me like you might be confusing validity with ownertrust. In my earlier note, i suggested that you *trust* the keyholder of some key that will certify the keys you are encrypting to. Instead, it looks to me like you've chosen to try to *sign* one of the keys you're encrypting to directly from the server. It helps me to separate out these concepts into two ideas: 0) who do you know (i.e. who can you identify)? 1) who do you trust to identify others? And since you're dealing with two different gpg installations (one on the server and one that you control elsewhere) you probably want to think about those from separate perspectives. I don't know what you're planning to do on your server, but i'll pretend for the moment that you're working with a web application which is expected to recieve information over the web, and then encrypt it to someone. I'll refer to that someone as the encryption target. from the webapp's view, how does it know it's encrypting info to the right person? let's say you're the administrator of such a system, and you want the webapp to believe you when you certify that a certain key belongs to a given person. Then you (as the admin) would have your own OpenPGP key, stored off of the server (probably on your own workstation someplace). Let's assume that key is key ID 0xDECAFBAD. You'd upload the public part of 0xDECAFBAD to the server, and import it into the webapp's keyring. After import *as the webapp user* you'd say i trust the sysadmin to identify encryption targets by doing: gpg --edit-key 0xDECAFBAD trust and then designate ultimate ownertrust. Then, you'd use your own key to certify the key belonging to the encryption target -- you'd sign the target's public key with your own key. Then you'd upload the target's public key (with your certification) to the server, and import it into the webapp's keyring. Does this make sense? The advantage of this arrangement is that now your webapp can be used to encrypt to a variety of people -- you'll just need to sign their keys, and they can be encryption targets as well. hope this helps, --dkg Please consider the environment before printing this e-mail. This e-mail, facsimile, or letter and any files or attachments transmitted with it contains information that is confidential and privileged. This information is intended only for the use of the individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient, any disclosure, copying, printing, or use of this information is strictly prohibited and possibly a violation of federal or state law and regulations. If you have received this information in error, please notify Children's Medical Center Dallas immediately at 214-456- or via e-mail at priv...@childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all applicable privileges related to this information. ___ 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
