[jose] Algorithm identifiers for ML-KEM and ML-DSA

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 20 August 2024 18:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7750EC15109F for <jose@ietfa.amsl.com>; Tue, 20 Aug 2024 11:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.654
X-Spam-Level:
X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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
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 1-SlJ5elmrtC for <jose@ietfa.amsl.com>; Tue, 20 Aug 2024 11:26:13 -0700 (PDT)
Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) (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 D49CFC14F706 for <jose@ietf.org>; Tue, 20 Aug 2024 11:26:13 -0700 (PDT)
Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-5d5af7ae388so2933278eaf.0 for <jose@ietf.org>; Tue, 20 Aug 2024 11:26:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724178372; x=1724783172; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=a7HdJQouPLXefpd3E1vJwkQBviJIcqZXkxjb116HviU=; b=rjRmBJUTXj95InI59GVkq7fVyeiTKeG+rjkp/LQEiLjnMEKSlxvVDf7gj4sIB2dHph FmLZlIMXJYJnWmL+d4yydBvBvcsGe+bvd1lb68tylLcs1aK8/jJ1HFeDdfCieiWfH6xc k1i3cw7aBBYQMe53hlMVfUJVoP0gRlwBat4NDPT1uxvzf6mBIJ+QF1aqABdWbGXitHsI iZBxUFXE3dwZ6ViMka8yIz7tVK4ufSxywV6JZOHmf6v3IlzQD/Gc39JQlSDX/QLgL+Ep ASE3NW57b+1DKo1aE7hFq0UuZq30ngsHstDuo1mMjbBhH4Xg6rs0gVdwGmt1sqxQpYEk pKVw==
X-Gm-Message-State: AOJu0Yw60L4aMc3tNmuP3opHs9sQby+lPO8Rof91BD7dqjNY9fQ5BedA En05hjQhQ6JqFoGSDCxYscuHaa0tzKLVYzXcG6o3XkNqxhL1UEGZkP8wogZPYNw6Lrhq0eIwnbR qqiu39zcqewNQnO3g14gj9o5D+zQ/y0B4
X-Google-Smtp-Source: AGHT+IHudiEw0hAde3MIYubHLymnyiHNZMPflSorh7di3gmItt+2lfxnpOaE/aaSNtmrVtOas1MofAfWHh+YcNMw1dU=
X-Received: by 2002:a05:6870:3294:b0:25e:b7e5:6b6 with SMTP id 586e51a60fabf-2707cd63b9emr1695994fac.12.1724178372498; Tue, 20 Aug 2024 11:26:12 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 20 Aug 2024 14:26:00 -0400
Message-ID: <CAMm+LwirtxesE0+4hwUOKgduoPbbqvbZ67qa-kZVSWmkW9GeEg@mail.gmail.com>
To: jose@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006c1c240620218fc3"
Message-ID-Hash: LIHAYG6JZM62P23EBYBVSYFPYLEJ2GVB
X-Message-ID-Hash: LIHAYG6JZM62P23EBYBVSYFPYLEJ2GVB
X-MailFrom: hallam@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Algorithm identifiers for ML-KEM and ML-DSA
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Cvkpi_7dziWiRSBK0ZfTusIl22w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

All,

I am looking for guidance on algorithm identifiers for ML-KEM and ML-DSA, I
understand that the drafts are not yet final. But I need to push code that
has PQC roots embedded before that is going to happen and would like to
follow as close as possible to what the final choices are going to be.

I did try to look for this info but the work is spread thinly across many
forums...

My preference is for fully specified algorithms with the strength
specified. I am also partial to longer rather than smaller identifiers but
that does not seem to be to the taste here. So my IDs would be


MLKEM512
MLKEM768
MLKEM1024
MLDSA44
MLDSA65
MLDSA87

If we want to go denser:

MLK512
MLK768
MLK1024
MLD44
MLD65
MLD87

Actually, I like the second as they are more readable. I have been reading
a large number of tweets by an elderly person who types in all caps online
of late...


Since I need to ship before the specs are final, I will probably use:

MLKa1024
MLDa87

I see no need for other identifiers since I cannot imagine anyone who is so
concerned about CRQC robustness as to use PQC not using the highest
strength available at this point. Also, I want to stress test with the
biggest payloads.

Signing every message with MLD87 turns out to have a very serious impact.
And not one I think I can justify for every application when a CRQC is
still at least a decade out. So the real goal at this point is to ensure
that if people start deploying the system and make use of it today, they
know they can transition seamlessly to a PQC version of everything in the
future.

Turns out that costs only an extra 200 bytes or so in the user profiles!

And before folk start whining about me mentioning my work on the Mesh, the
point of building a completely green field infrastructure is to test out
design approaches which we might attempt to retrofit to PKIX and SAML.