[lamps] Re: Request to Extend IETF WGLC for ML-KEM and ML-DSA private key format Specifications

John Kemp <stable.pseudonym@gmail.com> Wed, 22 January 2025 18:51 UTC

Return-Path: <stable.pseudonym@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8761BC14F74E for <spasm@ietfa.amsl.com>; Wed, 22 Jan 2025 10:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-XoL4r_6rVG for <spasm@ietfa.amsl.com>; Wed, 22 Jan 2025 10:51:01 -0800 (PST)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E89EC14CEE4 for <spasm@ietf.org>; Wed, 22 Jan 2025 10:50:59 -0800 (PST)
Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-51c7b5f3b8bso36016e0c.2 for <spasm@ietf.org>; Wed, 22 Jan 2025 10:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737571858; x=1738176658; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=Iq6FtF0nuFBbvsugLTtDrQOzTbBhYE5UZFnHk1kz1Ag=; b=bcWM5MnNfH7snzo+h9Vy4iglNLxXcgNEvh3d0vjcXao7WT7KXuX20nTeU1hiwMVCrn fqsBN1QUQxDEsCb29jnN/uZzplwXemxvUXyMkWPwnkb876F2Ipu9dQg0YaMnQbBqvfeC aqWYhck1kOnttoFMDjy7gFmJKMSN6fkeDUCgxFwl7OY5/LV2Axk6K2sUFxjuRKABZa2z HpiddQ2ElyiEEjURD0cNYtiBUmALb73j3P7MKuSzUAaL/0SS/FdM0n+HjrTyFt2K4BDs /3lyWQHVLXzw1i3Bg+RhunLF8+NXFB3CgNGuLYbSkoibkESMy1Y91UxerCQOBNy1zp4l Y4DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737571858; x=1738176658; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Iq6FtF0nuFBbvsugLTtDrQOzTbBhYE5UZFnHk1kz1Ag=; b=U5HLV0oR0G92Q1PT+Qz0s+UyKtjZ58X3+th1XbJfyM0H7Jp3uDdR895QG/97P03E4F ex3mBQvuA0JX105544CEr4/IXqcenrEZQLYMBPgv7dK9ekvjClO11Mzw0GHXsxXrpFcj 6T+PRcp7tssfKJ5/SvqqOYP+TKYe3Yfje7K5dyQW0lnqZBczk0INm1iRMLxA3RMJsVLO /xsGSt36ilWU2b5jF/aO4w+M7F1nN8LbU3Nk3gJPCrXZBTG6NIsSyCHqLU4DzG7wQhyM hMCfXP8DjkdF0l+Cwf8KMz7PKTlxEKpETuT8c49xLH/4Atx9Cz2ySw4ZwTjmzr0HzovB aZWQ==
X-Gm-Message-State: AOJu0YwtMKmvBhOeCBzgU7jME9L1M9Ve+kOAwJEtVlYEMZqJXnNP1kzk 3NsRHCPM72h938JJyjhSGXq3c4WcgDL6XhBvIebMyw6s8H1mW8lNpEokOHMwk0r5+H9r
X-Gm-Gg: ASbGncvPVAh5hMjYjr8YQZ8X46psD+zzHcJLA7RVJAfCHuG9Lhh48Ah+ygibu6kwhX0 oYWAc1coAsWW7SFsBA+ymFcgq6TsMi1XyGB990xp2d7xXi5WkwS+bHz9c9UpzE229nfcNj1BrFp NVkbiwis4rmxPdwW//uVGR8FZnoT+8Vlzz9Sk6gfHW/DMqaXlasr4etNzYZFx0ZnBK0OU985WcI UZAto6Tu9VS0dFMI2woAApvuDmTdLdDkK/LiMGJ+1HfuyE1pGQN/SdpW7Q5mdwWCLXD726INBCq wPqI8A==
X-Google-Smtp-Source: AGHT+IHXualoNpgnXwcYBXJJNvcL3sisXkbYTe93/1fQN37+IIMYmVIX1Dro1nkGoSURglYcQ9w9ww==
X-Received: by 2002:a05:6122:2402:b0:518:a0ac:1f42 with SMTP id 71dfb90a1353d-51d592ca33amr16296887e0c.1.1737571858472; Wed, 22 Jan 2025 10:50:58 -0800 (PST)
Received: from [192.168.11.65] ([70.35.134.82]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-51cf56bdb68sm2291847e0c.37.2025.01.22.10.50.57 for <spasm@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2025 10:50:58 -0800 (PST)
Message-ID: <51259d25-7460-4119-b073-f856bb59c534@gmail.com>
Date: Wed, 22 Jan 2025 14:50:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: spasm@ietf.org
References: <11c0eaaa13b74f78b2c0abe9aeae8820@amazon.com> <2460be7f-bc9d-4480-a5d4-615eb512409c@bouncycastle.org> <CAEEbLAa88c4bQQEoK7STBwjt8so3uKVXeRfoHPqZFMRf+m4qgQ@mail.gmail.com> <E85156DA-1B03-404E-96DA-0534264DCA91@akamai.com>
Content-Language: en-US
From: John Kemp <stable.pseudonym@gmail.com>
In-Reply-To: <E85156DA-1B03-404E-96DA-0534264DCA91@akamai.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: BCN6GLMOW52PK5UCXURFRJ4O7H7R3JMO
X-Message-ID-Hash: BCN6GLMOW52PK5UCXURFRJ4O7H7R3JMO
X-MailFrom: stable.pseudonym@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.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: [lamps] Re: Request to Extend IETF WGLC for ML-KEM and ML-DSA private key format Specifications
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KG4Gr7bz3sevHEzc9SvKYfHT98Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>

On 1/22/25 2:44 PM, Salz, Rich wrote:
> 
> 
>> If a format for NIST’s semi-expanded private key is needed, it should have a separate OID.
> 
> I strongly agree that playing clever ASN1 games to accommodate two key formats is going to cause problems. Hasn’t the IETF learned by now that clever ASN1 is bad? Just like key parameters?

+1

I feel like we're going down a really bad path here, where we neither do 
the most secure thing, nor do we ensure good future interoperability, 
and in fact arguably make it worse.

- johnk

John Kemp
-- 
Independent Security Architect
t: +1.413.645.4169
e: stable.pseudonym@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj