Hi Erik,
I think we do need to upgrade our key, yes it could be a nuisance to
some, but most people will hardly notice.
To smooth the process I would suggest
- modify the existing key to have an expiry in the not to
distant future, perhaps 6 to 12 months.
- create a new key of 4096 bits or more
- Sign the new key with the old one (this can be undone once the
old key expires)
- *DO NOT* sign the old key with the new, that doesn't really
add to it's security but may create the illusion of that it
does.
- While the old key is still valid, sign any new releases with
BOTH keys.
- Once the old key expires,
- retain a copy (signed with the new key) of the public key
for historical use on old release
- Remove the (old key) signing of the new key
- Stop using the old key to sign anything
There may be some more things to add but I can't come up with
them right now.
On 29/12/15 17:14, Erik Huelsmann
wrote:
Hi,
The project has been using one and the same key to
sign releases for a looooong time. The key has a length of
1024 bits, a length now assumed to be susceptible to attacks.
Should we create a new key? What size? What process
should we use for the replacement? There must be other orgs
that had this same problem that we can learn from?
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
|