Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.173 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CANUQDChVGuF1rrG3+AVTT+pp0nEmDw7MXyGGX7nVbQ42Kpgytw@mail.gmail.com>
References: <CANUQDCiUYNwH_tkZyS_cbWVa1X=4CAA3_14VD+fYjAXk-JU=1g@mail.gmail.com>
 <CANUQDChzB7EYyx8QOPgDC2TPR7n-h-dK43tHDfTZ=ocHPLHSOQ@mail.gmail.com>
 <CAEKnhAH8eGzcUsWODc75_L1kq4OtF2bvR7qJkijWWSVoY7c_mQ@mail.gmail.com> <CANUQDChVGuF1rrG3+AVTT+pp0nEmDw7MXyGGX7nVbQ42Kpgytw@mail.gmail.com>
Date: Tue, 30 May 2017 21:26:27 +0100
Message-ID: <CAEKnhAH78Uey_Tp43UY+AVaADi-ckvtBW9EqsuKTj8iDfK+AGQ@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11489d184bfc150550c39e5e"
Subject: Re: [RFC] Distrust SHA-1 Certificates
From: bukka@php.net (Jakub Zelenka)

--001a11489d184bfc150550c39e5e
Content-Type: text/plain; charset="UTF-8"

On Mon, May 29, 2017 at 9:16 PM, Niklas Keller <me@kelunik.com> wrote:

> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:
>
>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:
>>
>>> Morning Internals,
>>>
>>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>>
>>>
>> Wouldn't be better use security levels instead as it is in OpenSSL? Of
>> course I mean just for sig level to not re-implement everything. Basically
>> having sig_level or something like that...
>>
>
> As we can't use the OpenSSL implementation directly, I don't see any
> reason to use arbitrary integers there which you have to look up again.
> Maybe we should fine a totally different way.
>
>
Well we are going to implement security levels at some point  anyway as it
is the primary way how to control security strength in OpenSSL 1.1+ so
people will need to look it up anyway. It is also much easier to use than
directly setting security bits IMHO. It might also allow us to simplify
implementation in the future (for example if it gets separated to its own
verify param in the future, we could use that). Also we will be able to
just completely skip that if the main security level is already on that
level or higher (it would be already covered by that).

Please mind that this is an openssl extension so we should prefer the API
offered by the library and not trying to invent our own solutions.

Cheers

Jakub

--001a11489d184bfc150550c39e5e--