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

Reply via email to