Greetings. I posted the -01 about ten days ago, and have not heard anything
since then. The chairs indicated that they wanted this fast-tracked, so I'll
nudge here for more input, either on the WG mailing list on in the repo
(https://github.com/paulehoffman/draft-hoffman-dnssec). If nothing big
> On Apr 25, 2022, at 8:56 AM, Hugo Salgado wrote:
>
> Thank you very much Duane for the changes. For my part, the paragraph
> on the requirements on data in zones and registries seems perfect.
>
> I also find the new way of mentioning glues for in-domain/sibling
> domain name servers clearer.
Thank you very much Duane for the changes. For my part, the paragraph
on the requirements on data in zones and registries seems perfect.
I also find the new way of mentioning glues for in-domain/sibling
domain name servers clearer. However I see that the change was made
only in chapters 2 and 3, b
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Apr 25, 2022, at 15:32, Bill Woodcock wrote:
>
>
>
>> On Apr 25, 2022, at 1:31 PM, Havard Eidnes wrote:
>>
> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
> I think the only good way would be starting considering shorter keys as
> insecure in FIPS mode.
>>>
>>> Agreed.
> On Apr 25, 2022, at 1:31 PM, Havard Eidnes wrote:
>
>>> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
>>> I think the only good way would be starting considering shorter keys as
>>> insecure in FIPS mode.
>>
>> Agreed. We've been using 2408-bit ZSKs for more than ten years now. It's
>> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
>> I think the only good way would be starting considering shorter keys as
>> insecure in FIPS mode.
>
> Agreed. We've been using 2408-bit ZSKs for more than ten years
> now. It's definitely time to sunset acceptance of shorter keys
> at this p
> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
> I think the only good way would be starting considering shorter keys as
> insecure in FIPS mode.
Agreed. We’ve been using 2408-bit ZSKs for more than ten years now. It’s
definitely time to sunset acceptance of shorter keys at this point.
Petr Menšík writes:
> Our crypto team is
> responsible for preparing RHEL 9 for FIPS 140-3 certification. They said
> there is legal obligation to stop using all RSA signatures with keys
> shorter than 2048 bits.
Either they're wrong or you're misquoting them by merging "signing" and
"verifying"
Hello,
I have sent already a notification about SHA-1 not validated in default
configuration. However that was not end of the story.
A new and even more severe issue has arisen. Our crypto team is
responsible for preparing RHEL 9 for FIPS 140-3 certification. They said
there is legal obligation t
10 matches
Mail list logo
