my gpg key does not conform to rfc4880?
I was told by a developer of a piece of software that my key does not conform to rfc4800. He said: According to http://tools.ietf.org/html/rfc4880#section-5.2.2 signatures of version 3 don't have subpackets, which are only available in version 4. Looks like your key from 1998 is not compliant to RFC4880. Do I have any recourse other than to generate a new key? Cheers, b. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: my gpg key does not conform to rfc4880?
On 10/10/2013 01:45 PM, Brian J. Murrell wrote: > I was told by a developer of a piece of software that my key does not > conform to rfc4800. He said: > > According to http://tools.ietf.org/html/rfc4880#section-5.2.2 > signatures of version 3 don't have subpackets, which are only > available in version 4. > > Looks like your key from 1998 is not compliant to RFC4880. > > Do I have any recourse other than to generate a new key? your key 0x9771109462F2B970 appears to be an OpenPGPv4 key, not an OpenPGPv3 key, so i'm not sure what the person you were talking to was talking about. that said, 0x9771109462F2B970 claims to have been generated on 1998-02-16, and is a 1024-bit DSA key. This is a weak key by today's standards, and the fact that it has been in use for over 15 years makes me think that you should probably generate a new primary key anyway. You don't have to revoke your old key immediately, of course, but you probably want to move to something stronger sooner rather than later. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: my gpg key does not conform to rfc4880?
On Oct 10, 2013, at 1:45 PM, "Brian J. Murrell" wrote: > I was told by a developer of a piece of software that my key does not > conform to rfc4800. He said: > > According to http://tools.ietf.org/html/rfc4880#section-5.2.2 > signatures of version 3 don't have subpackets, which are only > available in version 4. > > Looks like your key from 1998 is not compliant to RFC4880. > > Do I have any recourse other than to generate a new key? Probably, but without seeing the key it is hard to be completely sure. Most likely, you could just strip the poison signature from your key and keep using it. If it's a self-signature, you'll have to make another one. If it's a signature from someone else, you can either disregard it, or ask them to re-sign your key. Can you say what the software that rejected your key is? If you think about it, rejecting a key because of a bad signature could lead to an denial of service attack - just upload a signature that is noncompliant enough to cause the key to be rejected, but compliant enough to make it onto a keyserver. Is your key with the bad signature on a keyserver? David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: my gpg key does not conform to rfc4880?
On 13-10-10 02:02 PM, Daniel Kahn Gillmor wrote: > > your key 0x9771109462F2B970 appears to be an OpenPGPv4 key, not an > OpenPGPv3 key, so i'm not sure what the person you were talking to was > talking about. Ahh. Interesting. I will point that out to him. > that said, 0x9771109462F2B970 claims to have been generated on > 1998-02-16, and is a 1024-bit DSA key. This is a weak key by today's > standards, and the fact that it has been in use for over 15 years makes > me think that you should probably generate a new primary key anyway. Yeah. I have considered both of those things also. I guess the only thing that was holding me back was that the existing key has an investment in signatures on it though. What I am unclear about is how the authenticity and trustibility of my new key will be regarded in relation to the existing key with all of the signatures on it. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: my gpg key does not conform to rfc4880?
On 10/10/2013 03:12 PM, Brian J. Murrell wrote: > Yeah. I have considered both of those things also. I guess the only > thing that was holding me back was that the existing key has an > investment in signatures on it though. What I am unclear about is how > the authenticity and trustibility of my new key will be regarded in > relation to the existing key with all of the signatures on it. none of the above concerns should keep you from creating a new, stronger key and starting to gather certifications on it. You can still keep your old key for places where more certifications matter, and start using your new key in places where stronger keys matter. Do this until you feel comfortable that your new key has gathered enough certifications to be useful in both places, at which point you can revoke your old key. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
First steps with GPG, am I off to a good start?
Hello all, I'd like to get started using GPG on a regular basis, e.g. to sign my EMail messages and exchange encrypted messages with a few people. So, I just generated my first keys in this manner: 1. Booted to a secure system. 2. invoked GPG using the following command: gpg --expert --gen-key 3. Generated an RSA key with signing and certification capabilities and 2048 bits in length. 4. Edited the key using gpg --edit-key in order to add all required UIDs. 5. Invoked addkey to generate a 2048 bit RSA sub key, with encryption and signing capabilities. 6. Exported all secret and public keys to a secure medium, also exported the secret sub keys. 7. Rebooted to my production system, imported the public keys and the secret subkeys. The listing now looks as follows. For public keys: MacBook-Pro:~ robin$ gpg --list-keys DC329876 pub 2048R/DC329876 2013-10-10 uid Robin Kipp uid Robin Kipp uid Robin Kipp sub 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] For secret keys: MacBook-Pro:~ robin$ gpg --list-secret-keys DC329876 sec# 2048R/DC329876 2013-10-10 uid Robin Kipp uid Robin Kipp uid Robin Kipp ssb 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] I'm signing this message using this subkey - and since this may not be widely available on keyservers just yet, the public key is at the end of this message. Could someone on this list perhaps be so kind and see if I've made any mistakes? I set the subkey to expire in a month just incase something went wrong with it, as I'd like to get it right before starting to effectively use it… Many thanks for any help! Robin -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org mQENBFJXKMwBCAC8DIDNqCRRdF9EqNJk5612/wsoUCTjC3D6Ipt1lDnR4NrI2VYm JjhnxBhmnsKP2M7Sco0zXycaygaNAEA+GBdAR1s1XxD85GRjTWToMf4DsVfuZPUM Kk20MqG2TOq9aSqEsoljCuu0M+pcPjALeCztf7GuC8fEbXKUAtQ3m01achYc22q0 IFkahEk/EPjvOPujO/T/+jqpt7OWyBtYPKkfnGsWqfUkWE0fEJl1xj28JyrT7ajU QSYVbVyJFTxTNMiD6gQwt0LVcibCFoYDil8BQEwrZX8I3r1azJoI2cRV33AmFaf+ Kc3fbMX45pA+wIUTOgtQqz01wjuLBYkRKwxVABEBAAG0IlJvYmluIEtpcHAgPG1s aXN0c0Byb2Jpbi1raXBwLm5ldD6JATcEEwEKACEFAlJXKwwCGwMFCwkIBwMFFQoJ CAsFFgIDAQACHgECF4AACgkQIlgbptwymHaJXQf9FpB3hB+frM7e2qP5rAR7ZJn3 Y0FSRslYXc+c0MirYK+K3NI6Anj8byT2G6C6OiKPE13glePGQEgNRg8v7X+k/ggD LaiQqYmfcAgIGuSIDBB+ZwmZVvErubDWtCzAEdzSIaS3VV+cT8gg+JTBJ6q/aZV7 bKPSRDyFlsmgUst55F1Amm1uoXlbdb3o8JXVZR4tYM4XDh0HcBwDeDIduN0NoSw+ JGYIX1CgIie5T418uUMVqB8sOvGDl8QeqSsOwpxTTCSCj667QqFjTaPdk4ZNAsZ1 8C4zgtBgw89fgMKImx8wez7vnV/VB+gv7P/YgAhMY2e8OF1ELyYnzo3xHATqAbQh Um9iaW4gS2lwcCA8cm9iaW5Acm9iaW4ta2lwcC5uZXQ+iQE6BBMBCgAkAhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheABQJSVyshAhkBAAoJECJYG6bcMph2vCUH/1H4 SeiF/OkOyJxQW5o1fBmzUfjVwptIitNWbjzhKQw+2QPlLRfiO6rqMW0U/loEM4O0 d1uxCmhguvusKGA3O/mAAZTicnnWcqzlkNNcvoycNavSAI8aaqGPjHPyzDuzYqJD /UREwRvknH5JWlyb1LaZvT3ynKDxgY+wkQHAQLLEHmhFyPk80egSjFMdI8WTmCVl +X3nPimME5UDcPO2M1YJ0pwHuMO/lC6vIJXCBPH9ljwIRWZ6fT7L4g5HEzN8yJ0h RbWrdSuPmgStiFT5wSts5K/BLHBGsPYqL1/0kiJNO+bz32Ob0dfIYDMXoiPAyYJ9 85K+ozRGkYQa/AJr/0GJATcEEwEKACEFAlJXKMwCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4AACgkQIlgbptwymHaFgQf+Jb7PfrZvt4glWNxUKh1+lkdXMLas9gl8 4Nsyc9s/biqqfD6iOSVpi4jQZJ93uhuBW8yKxOCcrI26jzVssSZHiP+8ZO7eDWx7 G5GbKal41FkE70AnP2lzCyovxeV/ozSnpHaopiQF6HRSvpikvKE8M6xeEN+9UgNv PfePYpO+lUdr7Rps5CNSEgtXgTX3IWt8QOJ7Q1jAbzaUNyz/kB9PuD31d4MLr0IV 8kMCvJ0c/qoF6DCatliEh0RLvWxig+ycScB0G0MOzgALpHHwzdBJnKYbR5PHWJnu KCCOwhsUTagNj+vIcVK8jbY6kyYa6tozvxzHUHpQPOzlgz86O/WkqbQfUm9iaW4g S2lwcCA8cm9iaW5AZGVic3BhY2Uub3JnPokBNwQTAQoAIQUCUlcp8gIbAwULCQgH AwUVCgkICwUWAgMBAAIeAQIXgAAKCRAiWBum3DKYdnCxB/9SH9YLIQAg6gBWgLCB kEocbCoY+62w89PHQksjUMGi3sICweZhth8HLHDTXhTnGLAE5d4dWZzQ7l5zSOI6 Fqu/ATCrKVOol5S27V0N2KGaeaY6TY2cSVq3RFVDwXVQxJgAfIY4+Pc6lYLk2trB 86xXuprZ2opRCRkHXX0Wxxu/bpM3cquNxkGs1XcT6ipKoGMB3NxXjj1xYR7qLW/+ wquFVA+bdAjvRSdeJT9UwuF9XQgv+dK1CN4OFgj3Cc8eOzOy/e74X7x6w4ygBCJW uC5LVqPC9/F/Vi3ktXmfXauoQ2NbSCFyJBd561odOe88d97Hpqu/aNMo+wE63Kpg UAoDuQENBFJXKY8BCADdCRlCh2Gc3ULtspU+fd/i9G0Dzv8J26cSqshD74RVqVtS IQCQ6D79rUe6/Tdy3BYVXGsxmWYkBlnyocoITgPiz8j8LrsCLZq+kVZ1qCFonWv7 nErMnVDfdyfJAZ99bG9D1lhCVj1J7Q0wGgN8Af2Xv5W/ZRerW7p8VuLf64SR1bdE sUASz0FyLwfa6GTlvjRIjZxOSpxfjduo9BewVL+tAKMjQjLVPeccqNf5piB8i4yw PklnXnNrbRL5m4Sk+nBTIK1+Sb4/RR7AQPLzahV2ePZ+41hrsUmZFtxtSHgSUX0+ QxdNW10TPF+D4yInB2gOytaFszSvyNd385+VgJA7ABEBAAGJAkQEGAEKAA8FAlJX KY8CGw4FCQAnjQABKQkQIlgbptwymHbAXSAEGQEKAAYFAlJXKY8ACgkQ9IrvKXff /wiqwwf+Omp3pRzeunMxJ3SqE3LZcAIaBncFp1UYIGvjdXKgPp6taMj54X7PcU6j 84iyTvYDC1pZaB+WQoxx+0uWfUJwXgs62aufu5pWowEPvpxXcbZN1TMo6SNcfPVq wScXwTyzimkX/I7EnmhmzihXl8Em+9fDoF0VNMmoXdXoEDSLaLhNR3ALBtmyEg9E 4WDitqbYha9L1JKv/hqYubyicWIPaZITF6LdIpKTIQhZn8vVc3xHDHPw9Ss9a+Rn UQlYOxQhfHOo8jzKQOxJKgRoTiWsi/PSbC3umrmKtamhK1rmuc6jtkY48QoDfviC IVwmO4XyVsJrmWBrYAFdcNJktTcK7Y1+B/95nNOrFhYe67JWnmMLqzLJq9e/G0bs lSBpr9iSGpNGr+NqdMcviHgN/DaqoJ7aLfqIp2z3QH/LLC8wDAmfKLPBJFNQdiwO B2oWTFE0lmBqMGx5N8wdg4BmSscomWfSDFE0WxSK4p8dVP9AIIUYUQ
Re: First steps with GPG, am I off to a good start?
On 10/10/2013 7:25 PM, Robin Kipp wrote: > 2. invoked GPG using the following command: > gpg --expert --gen-key Leave off the 'expert' flag and just use the defaults. Seriously, the defaults are reasonable and don't need tweaking. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: First steps with GPG, am I off to a good start?
Am Fr 11.10.2013, 01:25:50 schrieb Robin Kipp: > Invoked addkey to generate a 2048 bit RSA sub key, with > encryption and signing capabilities. It seems to me that the more accepted recommendation here is to have separate subkeys for signing and encryption. > 6. Exported all secret and public keys > to a secure medium, also exported the secret sub keys. 7. Rebooted to my > production system, imported the public keys and the secret subkeys. > For public keys: > MacBook-Pro:~ robin$ gpg --list-keys DC329876 > pub 2048R/DC329876 2013-10-10 > uid Robin Kipp > uid Robin Kipp > uid Robin Kipp > sub 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] I know of no good reason for creating a mainkey without expiration date. Furthermore it would be nice to have a UID without email address but with a comment which explains the security of the key. Something like "Robin Kipp (normal security level subkeys with offline mainkey)" This should be explained in more detail in a key policy which you should make publicly available and put its URL into the self signatures (see --set-policy- url) for the UIDs (and maybe even the subkeys). You should also set your preferred key server in the selfsigs (--default-keyserver-url). > since this may not be widely available on keyservers just yet > Could someone on this list perhaps be so kind and see if I've > made any mistakes? One may call that the best sequence of steps but one... ;-) Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: First steps with GPG, am I off to a good start?
On 10/10/2013 09:32 PM, Hauke Laging wrote: > Am Fr 11.10.2013, 01:25:50 schrieb Robin Kipp: > >> Invoked addkey to generate a 2048 bit RSA sub key, with >> encryption and signing capabilities. > > It seems to me that the more accepted recommendation here is to have separate > subkeys for signing and encryption. This is absolutely correct. You should not be re-using the same RSA key for two different usages if at all possible. See, for example https://www.schneier.com/paper-chosen-protocol.html You can fix this by simply revoking this subkey and adding two new subkeys, one for encryption and one for signing. GnuPG will automatically select the right one to use for whichever purpose. > I know of no good reason for creating a mainkey without expiration date. I also agree with this. An expiration date of 3 years is reasonable. If you're using the key actively and you do not believe it has been compromised two years later, it should not be much extra work to extend your expiration date for another two years. The expiration date on your primary key gives you a failsafe endpoint in the event that you lose all copies of your secret key material and your revocation certificate. (you do have a revocation certificate generated and stored someplace safe, right? i didn't notice that in your list of steps) You can resolve the lack of expiry on your primary key just by setting an expiration date directly with: gpg --edit-key 0x22581BA6DC329876 expire You can make your revocation certification with: gpg --gen-revoke 0x22581BA6DC329876 store it in a safe place! > Furthermore it would be nice to have a UID without email address but with a > comment which explains the security of the key. Something like > >"Robin Kipp (normal security level subkeys with offline mainkey)" > > This should be explained in more detail in a key policy which you should make > publicly available and put its URL into the self signatures (see --set-policy- > url) for the UIDs (and maybe even the subkeys). You should also set your > preferred key server in the selfsigs (--default-keyserver-url). I disagree with these last recommendations from hauke. Take that as you will. I don't think such policy information in the User ID is particularly useful to other people (i'd be interested to hear of a situation where that communication actually changes peoples actions and where it can only be made through the User ID as opposed to, say, on a web page, a blog post, in-person communication during keysigning, etc), and adding comments like this to the User ID makes it more difficult for others to decide whether to certify your key (since they may not be able to verify the claim you're asking them to assert). Implementing and abiding by nuanced policy documents that you set forward in your policy-url also doesn't seem worth the labor, complexity and maintenance involved, since the advantages it provides (either for yourself or for others) are not clear. Questions to ask yourself: Have you ever checked someone else's policy URLs? what would you do differently if you could check them? have you ever audited the claims of someone's policy URL in any way? Lastly, do you even have a preferred keyserver? if not, setting --default-keyserver-url doesn't make any sense in the first place, and you should just use the global pool. Even if you do have a preferred keyserver, including such a keyserver URL in your self-sig is in some senses equivalent to a "web bug": you're asking the user of the key to make a call to your preferred server when they access your key. People who do not want to have their activity tracked will probably set no-honor-keyserver-url in their ~/.gnupg/gpg.conf, and will expect to get updates from arbitrary members of the public keyserver network, or from their own preferred private, non-logging or otherwise privacy-preserving server that is peered to the public keyserver network. i hope this analysis is helpful, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: First steps with GPG, am I off to a good start?
On 10/10/2013 11:25 PM, Daniel Kahn Gillmor wrote: > > (a lot of stuff snipped) > ... Or, you know, you could just stick with the defaults. :) IMO, new users should be encouraged to use the defaults. This gets them using GnuPG and developing their skills with it. If, once they develop their skills, they decide that their needs are not well-met by the defaults they can always create a new certificate that's fine-tuned how they like. GnuPG already has a learning curve like the Matterhorn. Let's give some thought to that before we start advising new users to tweak every knob and dial on GnuPG's controls. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
standardized security levels
Hello, a few mails ago dkg asked what the use of key policy documents was. That is obviously limited for several reasons. But the conclusion cannot be that we do completely without anything like that. It must be that we solve the problem in a reasonable way. If we don't then we seriously limit the quantity and quality of crypto usage. I have been considering this a problem for years and yesterday I finally made my first step in solving it: http://www.crypto-fuer-alle.de/wishlist/securitylevel/ The text is in German, though. But have some fun with the Google translator if you like... :-) http://translate.google.com/translate?sl=de&tl=en&js=n&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.crypto-fuer-alle.de%2Fwishlist%2Fsecuritylevel%2F&act=url The idea is to reduce the complex multi-dimensional security of a system to a limited number (about 10) of typical and useful cases. This should allow people who do not consider IT as one of their hobbies to much better assess the situation of their IT and their data. My OpenPGP specific aim is that such a standardized list would be implemented in OpenPGP applications, probably as a signature notation. The typical user would have several keys (for the same address) at different security levels. Thus the sender could select the security need of the data to be sent and the system could automatically select the most suitable key (or fail if none such is available). This may sound like making IT even more complex but I am convinced that the opposite it true. Achieving the same situation is much more difficult today. In fact these considerations are simply ignored by most people today. And then they are surprised that their money is stolen via online banking... Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
