Re: DNSSec mess with SHA1

I would like to add decision to not allow SHA1 signatures verification were done on openssl component in RHEL9. It was not proposed by bind maintainer and because the crypto library prevents that operation, there is a little bind package made by any vendor can do. Unless they want to support th

Re: DNSSec mess with SHA1

tion is Jan 1, 2017, SHA1 certs should not be created after Jan 1, 2016, because the expiration date of the certificate would be past the deprecation date. * See the Microsoft KB article for specifics on code signing certificates. * Microsoft is going to reevaluate their policy in July, 2015 * Mozilla has stated that they are in agreem

Re: DNSSec mess with SHA1

Hi Folks, Many thanks for you feedback and insights. I didn’t wanted to say that this is an ISC issue or something I expected someone to fix. I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-) Yes, it may be a distribution packing

Re: DNSSec mess with SHA1

They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews > On 16 Dec 2023, at 01:09, Scott Morizot wrote: > >  >> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: >> We do runtime detection at

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: > We do runtime detection at startup because it's configurable, build time > would not work properly. > Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime erro

Re: DNSSec mess with SHA1

On 15. 12. 23 14:28, Scott Morizot wrote: On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček > wrote: Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as inse

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček wrote: > Hello. > > It smells like a packaging issue to me. Stock BIND (not an obsolete Red > Hat-Frankenstein version) should detect this condition and threat > domains as insecure. > And I think that answers the one question I had. I was curious what

Re: DNSSec mess with SHA1

* See the Microsoft KB article for specifics on code signing certificates. * Microsoft is going to reevaluate their policy in July, 2015 * Mozilla has stated that they are in agreement with Microsoft and Google and that SHA1 certificates should not be issued after Jan 1, 2016 or tr

Re: DNSSec mess with SHA1

The question I have is why you're posting the issue to this list and what you expect the ISC to do? It could be submitted as a bug to the distribution you're using. Or if you want to change the way algorithms are treated, the dnsops list at the IETF would be an appropriate place to start. (There ha

Re: DNSSec mess with SHA1

Mozilla has stated that they are in agreement with Microsoft and Google and that SHA1 certificates should not be issued after Jan 1, 2016 or trusted after Jan 1, 2017. They will phase in varying degrees of messages moving forward. After Jan 1, 2017 Firefox will show SHA1 protected sites as untru

Re: DNSSec mess with SHA1

On 14. 12. 23 8:58, Wolfgang Riedel via bind-users wrote: Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others s

DNSSec mess with SHA1

Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others simply removed SHA1 from the code so if you're running