[DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry

Petr Špaček <pspacek@isc.org> Tue, 14 July 2026 13:20 UTC

Return-Path: <pspacek@isc.org>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8A022116870E7 for <dnsop@mail2.ietf.org>; Tue, 14 Jul 2026 06:20:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784035223; bh=KWbGCUUYzZIsg7P+KVDtg3UanncO+adG18XfiVLmmM8=; h=Date:Subject:To:References:From:In-Reply-To; b=hfJABwgL5MtuUJ8FI35jSO7ZqeAGexR/bVSmoUIj+3aYJ/l3qFkLclmoNvT5iIybx gigo/liJ7kMYXK742ytontOsGZj2rGyEXfAokZSzfRV/y1zgSQcokfnIcH1KUeAn/c f6R4OT50g2wzwTKdxp7wd2m5pa0yyXyCdPZ5QhKk=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="cQRcSayJ"; dkim=pass (1024-bit key) header.d=isc.org header.b="jO1prG5C"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzeDjUjn9omz for <dnsop@mail2.ietf.org>; Tue, 14 Jul 2026 06:20:23 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1FB2F116870DF for <dnsop@ietf.org>; Tue, 14 Jul 2026 06:20:23 -0700 (PDT)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 53D8C4E40B1 for <dnsop@ietf.org>; Tue, 14 Jul 2026 13:20:22 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 53D8C4E40B1
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1784035222; cv=none; b=W71qPqdFpiQLMGnapure9Rx/13kNowsvlE0xthhioPlGMxbaPYRaYrcd+9cSnDCPpD7U4q2TQh8cihSPCwVIoSdmnSbFf+/YDzXSNFwhbB3DTJakZpAqjPn8Ft4X+NJ4Yfr2HSNBZLu3erbdNPLck0KIK/wmsYaPmvZpCF0Ytzg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1784035222; c=relaxed/relaxed; bh=LfW6JZMTmAMMwfjV39ml3UWW8fttfZDjUkDVrQBzPRM=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=DvlC4xi4jVh6EBW5WgbDelVAIqUurEhwEj+GOGxz2EUZX+f3WZ2+6+ptAikVzYPmapSmMwN+y3CObPwlj69dRIcM5sVBBD/QNzUZjrp8Az/351nG33v5kXbaJobFdcCa2bfc/lSIQKlx2SapQg/XvdznmpRpBy+hJTULCNFs0KA=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 53D8C4E40B1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1784035222; bh=KWbGCUUYzZIsg7P+KVDtg3UanncO+adG18XfiVLmmM8=; h=Date:Subject:To:References:From:In-Reply-To; b=cQRcSayJ8AynNIjOMzVikX0C9QdATn4NoYg5BwqYloZciaLRUekEfsyPGdNZWH8/Y khRJnoBpD0idsP3719E9jYtkVW38XMC+EbgHyaWeSADp+U65yuyg5De1lDT3CCUoQc 5Gv8qf8sqC9kqzQ8yGx8Y7sIegwUmwmFXc2VPQfo=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 523D02E6012E for <dnsop@ietf.org>; Tue, 14 Jul 2026 13:20:22 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 4E98E2E601BE for <dnsop@ietf.org>; Tue, 14 Jul 2026 13:20:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 4E98E2E601BE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1784035222; bh=LfW6JZMTmAMMwfjV39ml3UWW8fttfZDjUkDVrQBzPRM=; h=Message-ID:Date:MIME-Version:To:From; b=jO1prG5CpYi0qau66uLb1fwtdwfJbP3v1AmmZmcjk24FmoSUpunJYJISNIZ6FRdqG Uq1qqKwQnMDERDlno830EBD66BJt4EsxyWkdwpl2XARt+Udo2mlGl8siQbDoQ6FaTP tLJLqK4GJFz0utWwbZsImZauooetRkzPgHtvixLE=
Received: from [192.168.44.118] (78-80-19-161.customers.tmcz.cz [78.80.19.161]) by zimbra10.isc.org (Postfix) with ESMTPSA id A90352E6012E for <dnsop@ietf.org>; Tue, 14 Jul 2026 13:20:21 +0000 (UTC)
Message-ID: <23252039-7276-43bb-a693-3dd5f035c49d@isc.org>
Date: Tue, 14 Jul 2026 15:20:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dnsop@ietf.org
References: <A08D5A2A-8E4F-41EA-BA03-DE1DDDA2FD2C@internetstiftelsen.se> <64062B01-D590-4826-9971-4E39A8113018@icann.org> <A4680B45-FF8B-4489-A4BF-0A2EE91DFA98@internetstiftelsen.se> <33D11D8F-3E27-4F14-859B-A5F3F0FA46AB@icann.org> <m1wdS9U-0000O4C@stereo.hq.phicoh.net>
Content-Language: en-US
From: Petr Špaček <pspacek@isc.org>
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmkt8P0FCQtoiX8ACgkQq9WHzfBlga4m OxAAhBZyC7vnxl3kjFPFRT39ocbZy1jJX4fiaJmiIgKma06c9Eled/w2IN9pzRc0+iI6jSQa 40NfHFV8g2KZfZUNEVE3BOliWdEFi61OcwxB/UeryGDJUFYfK4un7ibYv4Rzvrfpz13aQ0/z MVm2HA3OVwkTqnK+dJL//d3AmED66oJKUFXU9tG5kUGNqbVrZNSiegZXC/TloO0+eYYN63Fm EHvWE20NcgdciG4y/pdtBXcWSwt21tSeqiZqN5L8LvfAGmJ1gdi6p4eHvPEH1WSOqUEZmy5l +5BE6xA2z4bfNpCYSir6GwFTOQwxHeekLKJktgsLjYY8oHbmPjIIdEzkcV8dD8czJEPo0sqe VB4qTun8cCE4AkVofpo5MMwni/3DLlm9bgV8tKJ3sAqwo6bEWk8dU9QqlcwiYb5S1KPbWrwO 89cIJNLIu9rO3nemWFDwNq6mFuNdNWSDciLV434P5xZ0y5Xy09n5dGhCgYZTRv1JTLmXEO+H aw6iRgLNZmImYB0VpoPPHBjIavsY211qyLIwDRaUykELhGaBk7P1zKhC91ZD866CbR3x6ptv EuFuJ2myZT1dIalWiFf0HaVhrMHm8y8ih1sn9Ezdxnle7Hxyjgp//CtM92GCjU8iuqYQOzNq B9LWBU6NTtGx5Tktf2/Vin2ADqiiVN1EDOQd9tvOwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC aS3xCAUJC2iJigAKCRCr1YfN8GWBrgJJD/4oabL/T67M7GNPB1Q+1ghSpi3LJEwDqeaULNZv 2exo7N59cChW5DXD5e/rkvQM7yOsaKJBwkpjY2+vk4+Tw9iU1iqzS0iavr9A3i9mHJjlp4it u6oDBHCGMqBGZHHGP4O9xPuIoW6s50yP31NLbIGP4KGD03S1JtOBrETlTyr6a0mN4HrRnAkz nOa2l7npRvgkRpdr/vDmbAkyZYXcUCQSWsOKzRrcCrqRxzF7Ob39Xw+SrPv7hMBShzOVJCj6 XwOsu+F/hmRK5TML8+yZ+wGbrcTyxJ8qkKtwtDJXPMVY993f1k50/bquRdjX5wHTthvf6o9A 2cmZtbL0fVm2KEWNV3xDk52cJj7MqBk1M/mj1q8+6UzN9hTxN0N77u1sosgguW/8PWu/v2yy kUs2huxaqDkdrPc6kKuKbCGpkT5/89S6gvQSNx5IlVl0uWzJRat1h9HkdkO0CBYRX51Rv33W BF4qJ73o2dfrUchs70rher6734c21z8DUhDkvnPGIgLh4tYrYHNcM4akBTUt9k38xMGrj6yo kRjP6Pq9jhLwJBxxBRDEXn3vse8uy1s1sp9rhBxSS7bEHfmyz71h6ccALCFBlBzqfMediCAE 0PEMOPrXM0NU+o25vNC8BuWWpPf+fzvkLf+sEyYcIdwbHZ/V2qv97JvYX0FpMwmeyw4O2g==
In-Reply-To: <m1wdS9U-0000O4C@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: KB4CLVGYE74GMJZXJ2FZ4T3BCFJZFPKL
X-Message-ID-Hash: KB4CLVGYE74GMJZXJ2FZ4T3BCFJZFPKL
X-MailFrom: pspacek@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nUqNagM2eZKzYY-s1UMxbZJfgIE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On 27. 06. 26 14:28, Philip Homburg wrote:
>> Not only that, no. Given the problems that other groups have had
>> well-documented problems with experimental ranges (code $experimental1
>> is used for FALCON testing, later FALCON is assigned code $real1,
>> now developers have to guess how long to keep using $experimental1),
>> we think that using 253-with-lead-in is actually better for the
>> community.
> 
>>From a developer point of view, this is exactly the same problem. For the
> question how long to support $experimental1 it doesn't matter whether it is
> an expiremental code point or a third-party registry built on top of a
> an extension mechanism for private algorithms.

I think the fundamental problem is: The registry range is too limited so 
we need to care.

If we had registry and 32 bit value with FCFS allocation policy, we 
could just allocate a new algorithm number every week and still have 
plenty. And if the algorithm did not took or/was retracted by NIST, who 
cares, just leave the number in there and move on.

253 and 254 can do the same but have their own quirks which are people 
seemingly unwilling to fix.

Would it help if we extended the range by allocating one value which 
says 'EXTENDED-ALGORITHM' followed by 4 bytes unsigned int, which would 
be present in DNSKEY/DS/RRSIG payload?

Should be simple enough if people are actually willing to do any work at 
code at all.

-- 
Petr Špaček