From: Tom Rymes <trymes@rymes.com>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Valid til days is required with OpenVPN-2.4.x
Date: Mon, 18 Jun 2018 08:21:27 -0400 [thread overview]
Message-ID: <67b0e1a1-b5ff-26d7-fb31-1e239bb2662d@rymes.com> (raw)
In-Reply-To: <1529323219.5499.21.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
Erik,
Tossing this back on the list, I hope you don't mind.
My apologies, I was unclear. What I mean is that the user will *want* a
longer lifetime, even though the longest *possible* lifetime will be too
long for security reasons.
In other words, my suggestion would be to use the longest lifetime
consistent with best practices, like those that you include below.
Tom
On 06/18/2018 8:00 AM, ummeegge wrote:
> Hi Tom,
> in my opinion this is the wrong suggestion since we circumvent in fact
> the new security feature from OpenSSL. The longest lifetime would be
> then '999998' days which is adequate to ~2740 years whereby we and our
> systems possibly wont go through :D .
>
> Additionally OpenVPNs hardening wiki --> https://community.openvpn.net/openvpn/wiki/Hardening#X.509keysize
> points a so called "future system near term use" (data are from Enisa) out
> whereby 3072 bit RSA key lenghts and more are recommended to stay safe in
> Enisa definitions for at least 10 years (research was from 2013) but IPFire uses
> currently 2048 bit RSA for the host certificate.
>
> May not representative but Microsoft said in 2009 something like this:
>
> Key length of 1024: Validity period = not greater than 6-12 monthsKey length of 2048: Validity period = not greater than 2 yearsKey length of 4096: Validity period = not greater than 16 years
>
> <-- is from https://cloudblogs.microsoft.com/enterprisemobility/2009/06/12/recommendations-for-pki-key-lengths-and-validity-periods-with-configuration-manager/
>
> May there are more actual papers for that...
>
>
> Best,
>
> Erik
>
>
> Am Montag, den 18.06.2018, 06:27 -0400 schrieb Tom Rymes:
>> I’d suggest that most users likely want the longest lifetime for
>> their certs that they can get, so as to avoid the need to frequently
>> replace expired certificates.
>>
>> This is especially true because there is no way to recreate certs in
>> the WUI when they expire, so you have to delete the entry and
>> recreate it when that happens.
>>
>> https://bugzilla.ipfire.org/show_bug.cgi?id=11742
>>
>> My $0.02,
>>
>> Tom
>>
>> On Jun 18, 2018, at 3:56 AM, ummeegge <ummeegge(a)ipfire.org> wrote:
>>
>>> Hi Michael,
>>> yes but the needs in there can differs a lot so the question arises
>>> what is a good default ?
>>> Another idea might be to add another (or a range of possible days)
>>> text
>>> for that field ?
>>> May the error message if an entry triggers one can also be
>>> extended.
>>>
>>> Greetings,
>>>
>>> Erik
>>>
>>> Am Sonntag, den 17.06.2018, 19:14 +0100 schrieb Michael Tremer:
>>>> Hello,
>>>
>>
>> can we also set a good default value for this?
>>
>>
>> This can be a little bit confusing for new users and it would be good
>>
>> to have
>>
>> some guidance. It can be a separate patch.
>>
>>
>> Best,
>>
>> -Michael
>>
>>
>> On Fri, 2018-06-15 at 14:59 +0200, ummeegge wrote:
>>
>>>
>>
>>> Have seen it too late to announce it in the commit message but this
>>
>>> patch solves also Bug #11715
>>
>>>
>>
>>> Best,
>>
>>>
>>
>>> Erik
next parent reply other threads:[~2018-06-18 12:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1529323219.5499.21.camel@ipfire.org>
2018-06-18 12:21 ` Tom Rymes [this message]
2018-06-18 13:09 ` Michael Tremer
2018-06-18 13:51 ` Michael Tremer
2018-06-18 14:05 ` ummeegge
2018-06-18 14:08 ` Michael Tremer
2018-06-18 14:10 ` ummeegge
2018-06-15 6:35 Erik Kapfer
2018-06-15 12:59 ` ummeegge
2018-06-17 18:14 ` Michael Tremer
2018-06-18 7:56 ` ummeegge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67b0e1a1-b5ff-26d7-fb31-1e239bb2662d@rymes.com \
--to=trymes@rymes.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox