Re: [OpenPGP] Key Transition

Never mind, sorry for the noise.  Even though .gnupg was writable by  
me, pubring.gpg was not.


-Grant

On Oct 13, 2009, at 4:50 PM, Grant Ingersoll wrote:

> 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]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>