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

Re: Creating a larger release key?



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.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


------------------------------------------------------------------------------


_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel