Re: [OpenPGP] Key Transition
Grant Ingersoll <[email protected]>
| Newsgroups | gmane.comp.apache.community |
|---|---|
| Message-ID | <[email protected]> |
I'm trying to follow the instructions at: http://www.apache.org/dev/openpgp.html#generate-key
And am getting [1] below. I think I have a public keyring (I've
signed releases in the past so I thought it should just work). I'm
using GPG 2.0.12 on OS X (10.6). I have a .gnupg directory and it
contains a bunch of stuff, but I admit I've always just followed the
instructions on this stuff and not understood the why behind it.
[1]
>gpg2 --gen-key
gpg (GnuPG/MacGPG2) 2.0.12; Copyright (C) 2009 Free Software
Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
...
gpg: no writable public keyring found: Unknown system error
Key generation failed: Unknown system error
---end [1] --
Any help would be appreciated.
Thanks,
Grant
On Aug 19, 2009, at 6:07 AM, Robert Burrell Donkin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> i plan to prepare a set of instructions for those who have a small key
> and who want to transition to a longer one. most of this should be
> uncontroversial.
>
> there is one area that i think needs some more consideration. i don't
> think that there is a great rush to implement this so - unless anyone
> jumps in with something i've missed - i'll get on with the rest whilst
> this is discussed.
>
> a transition statement is a notice informing the world that the old
> key
> is being replaced by a new one. it is signed by both the new key and
> the
> old. for an example, see
> http://www.jroller.com/robertburrelldonkin/entry/openpgp_transition_statement
> .
>
> providing that the old key has not been compromised, a transition
> statement allows those who trust the old key - and that it hasn't been
> compromised - to resign the new key.
>
> for apache, the risk with recommending this mechanism is that it's
> less
> secure than signing after a F2F meeting - if a key is compromised then
> transition statements could be published and keys signed in error.
> however, without using transition statements, there is a risk that an
> advance in cryptography will conclusively break SHA-1 or DSA before
> the
> new apache WOT is viable.
>
> if we decide to recommend transition statements then i recommend
> asking
> committers to broadcast transition statements using a independent
> trusted communication channel which can be monitored by committers.
> this
> should provide more security than each person using an ad hoc
> solution.
>
> for example, asking for statements to be committed to subversion would
> mean that an attacker would have to comprise a users subversion
> credentials as well as their private key. if that change were posted
> to
> a public mailing list to which that user were subscribed then they
> would
> be informed that their key had been comprised and could take
> appropriate
> action.
>
> opinions?
>
> - - robert
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQIcBAEBCgAGBQJKi87nAAoJEHl6NpRAqILLjqwQALzaot3LVWJwbCzxb2G9ZHbe
> +1luE6cQ4BH8aEz/S8oZDYq0iekvmJESEYzylalis4H4NEMfoIvTKS5Wdthgwspj
> IKxn6zjAgcj25+WFq+0sd8TK5BGoAYR9HOLkQsUEOFp3w693gbm3lE9XbRkFRMc5
> c/T9n4hVnPXGEih5fzaeHhOxGDcnuRGu4ZSs+GfW/F6hncqhTdqKw8kXTWeQ9es/
> 8xNcIkxULUIOHOgjVgEyQBHCX7zDsW7p3kBysHuYNV3BIKEwSOO660LmEUmnOLYR
> PYqFMEMmpEL8BJYZvtz1b9CG/ROtBWmy7GsjiXAvClWvZw93w5O+/qwFZ6LYQgO2
> IRd+T+RknJzr7KdPE/vzrlCpAITNd5SU4ROpUT9hSj2cig7sZWwaPlC+W4fr+1eA
> fk+PKPANEyBP2SnnNzmm9gOUCLahigHZVNR+8TBJVImAptQqvfpchrcwq+ov55vQ
> AL/msg81DxZaj/TR3tjydy1xu61t2coJ1OAN/yn/UyeFxzyujHxdiHtudaCaAXeP
> 7tfCvEvHa9q4DotvfT5aS6+hVQTUy2Hxd9iOHFwim6ewE2DVsvryeYI3PP60g/Vj
> XLoE6vpkJn3TgObQrhnGzF9vKLRBptYFy0HK8BacOaVdP8oQGeX2/02AGJ7mEwTi
> 7WpvJnmgD1ILnQt6ZrJx
> =BVjD
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]