From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Valid til days is required with OpenVPN-2.4.x
Date: Mon, 18 Jun 2018 14:09:10 +0100
Message-ID: <f529e572f8df77c2dad7000fb830529cb6b6bf42.camel@ipfire.org>
In-Reply-To: <67b0e1a1-b5ff-26d7-fb31-1e239bb2662d@rymes.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6322899047878795666=="
List-Id: <development.lists.ipfire.org>

--===============6322899047878795666==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

How relevant is this one here?

  https://bugzilla.ipfire.org/show_bug.cgi?id=3D10482

-Michael

On Mon, 2018-06-18 at 08:21 -0400, Tom Rymes wrote:
> Erik,
>=20
> Tossing this back on the list, I hope you don't mind.
>=20
> 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.
>=20
> In other words, my suggestion would be to use the longest lifetime=20
> consistent with best practices, like those that you include below.
>=20
> Tom
>=20
> 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 --> https://community.openvpn.net/op=
env
> > pn/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 IPFi=
re
> > 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:  Validity period =3D not greater than 6-12 monthsKey
> > length of 2048:  Validity period =3D not greater than 2 yearsKey length of
> > 4096:  Validity period =3D not greater than 16 years
> >=20
> > <-- is from https://cloudblogs.microsoft.com/enterprisemobility/2009/06/1=
2/r
> > ecommendations-for-pki-key-lengths-and-validity-periods-with-configuratio=
n-
> > manager/
> >=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.
> > >=20
> > > 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.
> > >=20
> > > https://bugzilla.ipfire.org/show_bug.cgi?id=3D11742
> > >=20
> > > My $0.02,
> > >=20
> > > Tom
> > >=20
> > > On Jun 18, 2018, at 3:56 AM, ummeegge <ummeegge(a)ipfire.org> wrote:
> > >=20
> > > > 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.
> > > >=20
> > > > Greetings,
> > > >=20
> > > > Erik
> > > >=20
> > > > Am Sonntag, den 17.06.2018, 19:14 +0100 schrieb Michael Tremer:
> > > > > Hello,
> > >=20
> > > can we also set a good default value for this?
> > >=20
> > >=20
> > > This can be a little bit confusing for new users and it would be good
> > >=20
> > > to have
> > >=20
> > > some guidance. It can be a separate patch.
> > >=20
> > >=20
> > > Best,
> > >=20
> > > -Michael
> > >=20
> > >=20
> > > On Fri, 2018-06-15 at 14:59 +0200, ummeegge wrote:
> > >=20
> > > >=20
> > > > Have seen it too late to announce it in the commit message but this
> > > > patch solves also Bug #11715
> > > >=20
> > > > Best,
> > > >=20
> > > > Erik
>=20
>=20

--===============6322899047878795666==--