Help me to import my secret key please

[Charly Avital]

Daniel Kahn Gillmor wrote the following on 5/9/10 9:33 AM:
> On 05/09/2010 04:40 AM, Charly Avital wrote:
>> Yes, you can gnerate a new key pair with the same user ID email, the key
>> server will accept it. Do not forget to generate a revocation
>> certificate and to store in a safe place.
> 
> Yup, Charly is correct about this.  You can actually have as many keys
> as you like with the same UID in the public keyservers.
> 
>> You might want to indicate in
>> the comment of the new key that the previous key (key ID) is not usable,
>> if you plan to upload the new public key to a key server
> 
> I'm not sure exactly what Charly means here,

I mean what I have seen done by many users who couldn't revoke their key
(either because they had lost the secret key, or had forgotten the
passphrase). It is not my invention :-)

KeyA is compromised, or lost, and cannot be revoked.

The new key, KeyB *might* include in its comments something like:
KeyA unusable


> but i strongly recommend
> you do *not* put this kind of remark in the comment section of the User
> ID for your new key (between the name and the e-mail).  A better
> approach is to make a key transition document that describes the
> situation, sign it with the new key, and post it publicly.  For example:
> 
>   http://fifthhorseman.net/key-transition-2007-06-15.txt

Great text, and great approach. One has to hope that people will
actually read it. I mean, it's a long text. But definitely a good
approach, much more orthodox than the comment approach, which, I repeat,
I have seen often used. But "often" is not a sufficient criteria for "good".

> 
> (if you still had access to your old key, you could have signed the
> transition statement with it too)
> 
> So why do i think you shouldn't put it in the comment section of your
> new User ID?  Your User ID is the linkage between your key and your
> real-world identity.  When you ask people to "sign your key", you are
> asking them to certify (a) that this key belongs to you, and (b) that
> they believe this User ID does really belong to you too.  If your User
> ID contains a string that does not really relate to you,

The string would relate to the user, it's all a matter of choosing the
right wording (very short).

> you're asking
> people to certify something unusual and potentially meaningless.

Not unusual (but again I say, usual is not a proof of goodness). Not
potentially meaningless, because the meaning is clear: *that* key is not
usable.

> 
> Also, consider the situation 5 years from now -- hopefully you'll still
> be able to use the key you made today.  Do you really want a remark
> about this legacy key to follow you for 5 years?

I wouldn't mind.
> 
> Lastly, since you can't revoke the old key outright, you might consider
> contacting everyone who has already certified it and asking them to
> revoke their signatures on the key.

This is a good approach, although it might "taint" the key. Users
wouldn't know why signers have revoked their signature, unless they care
to read the transition document.

> You can point them to your
> published key transition document as a start, but you'll probably want
> to also contact them offline -- this is also a good opportunity for you
> to ask them to certify your new key.

They would certify your new key only if they abide by the rules. I
wouldn't sign a key because of a key transition document. I would have
to contact directly, and better, personally, the owner of the "old" key,
of the transition document, and of the new key.

> That way, in the future, there
> will be no valid certifications on your old key, and which key people
> should choose for you should become clearer.
> 
> Regards,
> 
> 	--dkg
> 

To sum it up (as far as I am concerned, and to avoid further bandwidth
usage). I am OK with whatever approach or method that would make it
clear that the "old" key is not to be used any more.

Take care,
Charly