From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes 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 Message-ID: <67b0e1a1-b5ff-26d7-fb31-1e239bb2662d@rymes.com> In-Reply-To: <1529323219.5499.21.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8690871271904656074==" List-Id: --===============8690871271904656074== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=20 longer lifetime, even though the longest *possible* lifetime will be too=20 long for security reasons. In other words, my suggestion would be to use the longest lifetime=20 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 . >=20 > Additionally OpenVPNs hardening wiki=C2=A0--> 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. >=20 > May not representative but Microsoft said in 2009 something like this: >=20 > Key length of 1024:=C2=A0=C2=A0Validity period =3D not greater than 6-12 mo= nthsKey length of 2048:=C2=A0=C2=A0Validity period =3D not greater than 2 yea= rsKey length of 4096:=C2=A0=C2=A0Validity period =3D not greater than 16 years >=20 > <-- is from https://cloudblogs.microsoft.com/enterprisemobility/2009/06/12/= recommendations-for-pki-key-lengths-and-validity-periods-with-configuration-m= anager/ >=20 > May there are more actual papers for that... >=20 >=20 > Best, >=20 > Erik >=20 >=20 > Am Montag, den 18.06.2018, 06:27 -0400 schrieb Tom Rymes: >> I=E2=80=99d 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=3D11742 >> >> My $0.02, >> >> Tom >> >> On Jun 18, 2018, at 3:56 AM, ummeegge 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 --===============8690871271904656074==--