Hi, > -----Original Message----- > From: Niklas Keller [mailto:m...@kelunik.com] > Sent: Monday, July 3, 2017 3:14 PM > To: Jakub Zelenka <bu...@php.net> > Cc: PHP Internals <internals@lists.php.net> > Subject: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > 2017-05-30 22:26 GMT+02:00 Jakub Zelenka <bu...@php.net>: > > > On Mon, May 29, 2017 at 9:16 PM, Niklas Keller <m...@kelunik.com> wrote: > > > >> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bu...@php.net>: > >> > >>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <m...@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 > > > > What's the way to proceed now? Time is running low for the PHP 7.2 feature > freeze. > I haven't followed the discussion back then, but just read through. The discussion seems unfinished yet, as far as I understood. The two approaches - the one going by security levels, and the other using strength bits as a argument. As for me, security levels were more future oriented and the original alike, while have to be emulated with older dependencies. On the other hand - giving the strength directly is a an explicit approach, even if it's completely different from the latest OpenSSL. It were good to hear from Jakub yet.
About how to proceed - I'd say the issue is clear and either way should be fixed. The RFC chooses the explicit strength approach. What I'm a bit concerned about is, that there's no implementation by this time, neither for 7.2 nor for lower. Given there are indeed just last moments before the feature freeze, for 7.2 it depends on RMs. In general, I'd prefer to see the discussion to come more or less to the conclusion about pro/contra of the concrete approach, especially from the POV different OpenSSL versions and future support. If a patch with an implementation could make it into 7.2, the backport for lower branches will have no choice regarding approach. But, without being able to look at th patch, it is hard to say, whether a backport is even doable. For example, how it often could be, an implementation of a new stream context option might require some additional struct member, etc. Alternatively, what could be done - bring the approach discussion and consequently the BC implementation in all of 7\.[012] while letting the restrictive part to target 7.3. Either way, please let's see the code. Regards Anatol
