Hi, > -----Original Message----- > From: Anatol Belski [mailto:weltl...@outlook.de] > Sent: Thursday, July 6, 2017 4:52 PM > To: Niklas Keller <m...@kelunik.com> > Cc: Sara Golemon <poll...@php.net>; Jakub Zelenka <bu...@php.net>; PHP > Internals <internals@lists.php.net> > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Morning, guys, > > > -----Original Message----- > > From: Niklas Keller [mailto:m...@kelunik.com] > > Sent: Wednesday, July 5, 2017 4:39 PM > > To: Anatol Belski <weltl...@outlook.de> > > Cc: Sara Golemon <poll...@php.net>; Jakub Zelenka <bu...@php.net>; PHP > > Internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > Ok, so you strive to create a completely new RFC with a solution > > based on today's situation. I think you still don't see my point. Say > > there's insecure_allow_sha1_signature, which is a stream context. Then > > > > > > - in 7.0 and 7.1 > > - if absent, insecure_allow_sha1_signature = true > > - if present, the given value taken > > - impact for 7.2 migration - if explicit > > insecure_allow_sha1_signature = false is in the code, no impact > > - in 7.2 > > - if absent, insecure_allow_sha1_signature = false > > - if present, depending on the decision either the exact value is > > taken or ignored > > - future impact - none, the option can be even silently removed > > - in 7.3 > > - removed and disabled completely > > > > No see same if insecure_allow_sha1_signature is an INI > > > > - in 7.0 and 7.1 > > - if not set, insecure_allow_sha1_signature = On > > - if set, the given value is taken > > - impact for 7.2 migration - depending on decision, either it's > > deprecated warning or disabled by default > > - in 7.2 > > - if not set, insecure_allow_sha1_signature = Off > > - if set, the given value is taken, warning is issued > > - in 7.3 > > - removed and disabled completely > > > > Both options do same, but in different manner. Both have advantages > > and downsides, but one option only is both necessary and sufficient to > > achieve the goal. > > > > > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, > > dunno whether that'll be the case. I'd prefer that. > > > Nome, that's not mine, it's was your intention as I've remembered, might be > wrong. Anyway, what I wanted is only to show the redundancy having multiple > ways to do same. > > Anyway, now that Jakub also responded with an approach as well, maybe it's > time to get an RFC get the thing done? It could have the two suggestions > brought till now as an "exclusive or" choice and the disablement plan. The one > that won would be followed up. An implementation were great to have before. > > Both suggestions, either the separate context options for md5 and sha1, or > security levels, do same job and only differ in the way it's done. The > downside of > security levels is, that fe the suggested security level 2 will disable both, > while > user might want to disable only sha1, that's where the separate options win on > flexibility. Whereby having a higher security level should automatically > ensure a > certain weak functionality is disabled at once, which has some use as well. > IMO, > the INI option is a no go - the argument that user can get everything done at > once breaks encapsulation, as not every stream in the app might require it. > > The plan about the default disablement by version brought by Jakub sounds > plausible, as for me. IMHO the complete disablement should not be a part of > this > RFC. > > I would suggest, it's time to get on RFC and bust this issue. It would be > great, if > all the interested parties could cooperate on this. > Any news on the topic?
Regards Anatol
