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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/b5138e433b5218bb143b9cfa191db...@undergrid.net
