• Key expiry

    From Paul Hayton@3:770/100 to All on Thu Oct 26 22:08:17 2017
    How long do you suggest a key should be valid for?

    I'm not certain, I'd set an expiry on one I created with an open end value in 2016 to 2018 y/day but now I'm wondering if that's a wise move or not?

    I say that as my limited understanding of keys so far is that they gain
    greater trust when signed by others but if I expire a key after only less
    than 12 months to go then surely I have to start all over again with getting the new on signed etc. so in my mind it's a disincentive to expire it?

    Thoughts welcome.

    Paul

    --- Mystic BBS v1.12 A36 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Thu Oct 26 11:55:31 2017
    Hi Paul,

    On 2017-10-26 22:08:17, you wrote to All:

    How long do you suggest a key should be valid for?

    That depends, on your use case. ;)

    I make mine valid forever. In hindsight that might not have been a good idea. I
    have some keys from the early 90's that I don't remember the passwords of, that
    just take up space on the keyservers, but I can't do anything with.

    I'm not certain, I'd set an expiry on one I created with an open end
    value in 2016 to 2018 y/day but now I'm wondering if that's a wise
    move or not?

    It seems a rather short period.

    I say that as my limited understanding of keys so far is that they
    gain greater trust when signed by others but if I expire a key after
    only less than 12 months to go then surely I have to start all over
    again with getting the new on signed etc. so in my mind it's a disincentive to expire it?

    If you sign your new key with the old one, there is a web of thrust that goes back to the signers of the old key. But I don't know how that works with expired keys. There is probably less thrust when there are expired keys involved.

    Thoughts welcome.

    Whatever period you choose, at least generate revokation certificates and keep them in a save place, so if you loose the passwords of your key you can still revoke them...

    And I just read that you can always extend the expiration date on an already expired key, and send that out to the key servers. So there is no reason to not
    use an expiration date on keys. I think I'm gona set mine to 5 years...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Thu Oct 26 13:14:53 2017
    Hi Paul,

    On 2017-10-26 11:55:31, I wrote to you:

    And I just read that you can always extend the expiration date on an already expired key, and send that out to the key servers. So there
    is no reason to not use an expiration date on keys. I think I'm gona
    set mine to 5 years...

    This explains it very well:


    Use an expiration date less than two years.

    People think that they don't want their keys to expire, but you actually do. Why? Because you can always extend your expiration date, even after it has expired! This "expiration" is actually more of a safety valve or "dead-man switch" that will automatically trigger at some point. If you have access to the secret key material, you can untrigger it. The point is to setup something to disable your key in case you lose access to it (and have no revocation certificate).

    Setting an expiration date means that you will need to extend that expiration date sometime in the future. That is a small task that you will need to remember to do (see next item about setting a reminder).

    You may think that is annoying and you don't want to deal with it, but it is actually good to be doing this on a regular basis so you keep your OpenPGP skills fresh. It indicates to users that the key is still active, and that the keyholder is using it, and gives you an opportunity to review the current state
    of your tools, and best practices. Also, many people will not sign a key that has no expiration date!

    Source: https://preview.tinyurl.com/y77auelm


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Hayton@3:770/100 to Wilfred van Velzen on Fri Oct 27 12:57:46 2017
    On 10/26/17, Wilfred van Velzen pondered and said...

    This explains it very well:

    It does, thanks :)

    I think I will set mine 3 years in to the future and then extend thereafter
    as needed.

    I also need to consider if this current key is technically strong enough now or if I should shutter it and create a new one using a stronger process and
    set that one to expire 3 years from now?

    --- Mystic BBS v1.12 A36 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Wilfred van Velzen on Fri Oct 27 13:00:54 2017
    On 10/26/17, Wilfred van Velzen pondered and said...

    idea. I have some keys from the early 90's that I don't remember the passwords of, that just take up space on the keyservers, but I can't do anything with.

    Same here :)

    It seems a rather short period.

    Agreed... 3 years (see my other reply) may be better

    If you sign your new key with the old one, there is a web of thrust that goes back to the signers of the old key. But I don't know how that works with expired keys. There is probably less thrust when there are expired keys involved.

    Had not considered that, an expired key to my mind is just that so I can't
    see why anyone would want to include it in a future key?

    Whatever period you choose, at least generate revokation certificates
    and keep them in a save place, so if you loose the passwords of your key you can still revoke them...

    I need to learn how to do this and am not sure how to as yet, I'm using a windows tool paired with the gnupgp ... hmmm

    And I just read that you can always extend the expiration date on an already expired key, and send that out to the key servers. So there is
    no reason to not use an expiration date on keys. I think I'm gona set
    mine to 5 years...

    Fair enough :)

    --- Mystic BBS v1.12 A36 (Windows/32)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Fri Oct 27 11:55:33 2017
    Hi Paul,

    On 2017-10-27 12:57:46, you wrote to me:

    This explains it very well:

    It does, thanks :)

    I think I will set mine 3 years in to the future and then extend
    thereafter
    as needed.

    Seems like good practice...

    I also need to consider if this current key is technically strong
    enough now or if I should shutter it and create a new one using a
    stronger process and set that one to expire 3 years from now?

    That's what I'm doing. I set my 1024bit DSA from 1998 to expire in 2 years, and
    intend to use my newly created 4096bit (the maximum) RSA key from now on.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Fri Oct 27 12:01:21 2017
    Hi Paul,

    On 2017-10-27 13:00:54, you wrote to me:

    It seems a rather short period.

    Agreed... 3 years (see my other reply) may be better

    They advise 2 years, so your first instinct wasn't so bad. ;)

    Whatever period you choose, at least generate revokation certificates
    and keep them in a save place, so if you loose the passwords of your
    key you can still revoke them...

    I need to learn how to do this and am not sure how to as yet, I'm using a windows tool paired with the gnupgp ... hmmm

    On the command line it's easy 'gpg --gen-revoke [key number]' and follow the instructions.

    Your windows tool should have a menu option for it, if you right click on your key, I suppose?


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)