Hi David, On Tue, Dec 29, 2015 at 12:33 PM, David G <lsmb...@sbts.com.au> wrote:
> 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 > > Ok. Given Jame's response on the topic, let's go with these steps and decide on a key of size 4096 bits in size. There's one thing I'd like to ask though: why remove the sig of the old key, even after we completely deprecate it? If we do that, people can't establish the upgrade path even a day after the deprecation, right? Can't we just leave it? Should we revoke the key after it has been deprecated? I think so, right? > > - > - > - 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 > listLedger-smb-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ledger-smb-devel mailing list > Ledger-smb-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > > -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
_______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel