[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!



On 05.03.2014 04:01, Didier 'OdyX' Raboud wrote:
Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit :
On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote:
> I have a rather silly question: would a mail (signed with this key)
> request to the DDs who already signed the initial key (and checked
> the identity) to sign the replacement key considered unreasonable ?
Considering that the initial keys are now considered weak, I expect
that it would be reasonable for people to not trust a key transition
statement where the only available trust anchor is the old weak key.

Well, the project currently considers these old keys to be trustworthy enough to let the people who control them to upload any packages on the
archive (modulo these keys are in the uploading keyring).

If we trust that the people behind the keys haven't changed, we should let them use easy ways to stronger keys. On the other hand, if we think
the keys have been compromised, then we should really drop the upload
rights!

Cheers,
OdyX

I would tend to side more with Odyx here in that the keys are still considered trustworthy enough to be in the keyring but we're encouraging moving to stronger keys and no longer accepting these keys to be included. The subject of compromise is a totally different situation than this and would obviously need to be handled differently as you should no longer trust the key entirely and should be removed.

I started the move to the high bit RSA key because of deciding to make the move to using the OpenPGP smartcard which only supported RSA and not DSA. This was not because I have any reason to believe my key was compromised or that I had lost the private key data. Given the lengths I go to verify identity, control of private key data and the email addresses listed in the UID of the key, I might consider an encrypted challenge requesting signing a new replacement key provided the assurance that the original key had not been compromised and the keys were cross-signed. Though it is something I would most likely take on a case by case basis.


Reply to: