IETF Logo Mail Archive

[lamps] Re: [EXT] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

Mike Ounsworth <ounsworth+ietf@gmail.com> Wed, 08 October 2025 14:56 UTC

Return-Path: <ounsworth@gmail.com>
X-Original-To: spasm@mail2.ietf.org
Delivered-To: spasm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2AE656F6D505 for <spasm@mail2.ietf.org>; Wed, 8 Oct 2025 07:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l0Ml5mmqNEXq for <spasm@mail2.ietf.org>; Wed, 8 Oct 2025 07:56:47 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 mail2.ietf.org (Postfix) with ESMTPS id 9BD976F6D4FE for <spasm@ietf.org>; Wed, 8 Oct 2025 07:56:47 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-92b92e4b078so313815639f.0 for <spasm@ietf.org>; Wed, 08 Oct 2025 07:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759935400; x=1760540200; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EMDEOz2oOTHOQPukQVPL8XOluJOgwZ3ObaMkE5IfbCI=; b=R84nvOpDq4ff+DwhkqaQTDMkZU4rdPjjsQwT0w+a+G9f16iQa6cnKnMY8Eeil/zEac Ga9fW+0AwAwwH4xf+FoDnhVTnTqMxF66fVvPR2maHLpqqpO3Gr274men+uwimVdrmoit 8kfOUkw9xXG+/Rox+PZAAyg0WjAvFB74EUUCB5XDe3w7j4J2PgcLFRkcb/nRoOoMF+Wt W38BPJzNd+5/K4d5avUIzSArmOMuCiMbnSgmDlkD7hrW1+Zw/Tp3S0deJDsT8xD1gqnr 9r/JBkpnn5dQSizwroKrUIkyY1SWlr0Il29+ni2Ahh6B3qhQ+73O/tYgeJltLlAX30dO +tCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759935400; x=1760540200; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EMDEOz2oOTHOQPukQVPL8XOluJOgwZ3ObaMkE5IfbCI=; b=BR3BdV94/5sdhTvPN8/oP39ZwRYb42nZoCyfHqdULl3sicpb5zL3MnZuU21OEPHhvZ 1rahuP3JrrVeGqypdDKa5CKT80DemYv6xDtfL1H7meksZ42uz9AOCOsM4ToL3wkXzVgm P6Ls+dRqMaSXw5DjP3+G+U1XdY5R/X1hKH2y5Oe9b1hJjLDgLD9/TUVawoAEAhKdo1EV 1Yws6QKWc988Z67NaDi1SLbHo4ZQ7MAXHg6x52lDxY6O79AJ0ewNm0S1/9YK7spmrMxm NPSUeNv3HXxprmXKPyKYNcWJEW3DJApbQxoJ8dG4auoF9Wg9nZmA18if6y7P663DOYYu s81w==
X-Gm-Message-State: AOJu0YzD6/hlgHHuJ8kzjSkEoxJ3ysut7gTnR/V9jxDAnKPxyyTNBkQU aY/5/HBL/LXcAy6MmRCDU+/MU2DwOFO42kwzqz6LiA7dGiM2LBUIYIUIElXEb5fzY4rrLfHaHu+ WMoN44mQUcfVsvmkL2N6r8P3XERmPB6YaiejH
X-Gm-Gg: ASbGncvDDm3oy1rYDbpcjK2+g+4moF5Ai2Iiy1Ijjr6dQyC1BGyvGYyLqcDrs0H8QBC FiPZ4v2Zb+pSfbxQDKUZpq53GBqfgHbv/rCQJK1z/Y0x2ziHcDQ5X3LQdqq51Oharw4jFESS0yq sXQ3rTJMFn5mLx7NLTWi80f4hxXNCvRT3nTlHwVdQrCsRL65UAqCnnuIq/mTVMGhwYtis0X16Y2 tBqaT0Tp8oqP1ZZIjf5jb5Vu9Ikd46o
X-Google-Smtp-Source: AGHT+IHfgRslx99RZV2YxFLdhhKv3iIRMf98T4YABguu9DSXwfI16ZngyNOwZ5t1LN7eY4+oPkY9W4XkYSSBYrlVP8g=
X-Received: by 2002:a05:6e02:1a8f:b0:427:b642:235 with SMTP id e9e14a558f8ab-42f87374f3bmr34924645ab.10.1759935400063; Wed, 08 Oct 2025 07:56:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAEEbLAbQAs1-yzOHgoAtsMxOYCtVkcRcbuhyoDCoQQJ-FO_G0A@mail.gmail.com> <4910a47c-199d-4c00-86ef-73df3c60b689@crypto4a.com> <CAKZgXHo=xJTvvLKvw=E6qh7jLbgP5b5b_cpoOcneHGHqzqJxaQ@mail.gmail.com> <a8fa1db6-bde4-4775-9ebc-e47ea963f367@dennis-jackson.uk> <CAKZgXHrn45OK-X=JxWY0E9m=s7+pCBqFQk3bKTJ7fOQ=A2LeLg@mail.gmail.com> <BN0P110MB14193AD8816C7FCD4A5F643790E3A@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM> <CAKZgXHqw4qf_SOg0bDnd36rX3=RiVwPrb+XsebN7OisMxcU7tQ@mail.gmail.com> <BN0P110MB14199859C1563EF8F4FAA2E690E3A@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM> <aOX61dE1dmS4Ty2x@chardros.imrryr.org> <CACsn0cnJso0tbc9wN4wuPrCQHs4sRJMRuMgEteviVAQAn4Yigw@mail.gmail.com> <aOYtD5ylURp_cnx2@chardros.imrryr.org>
In-Reply-To: <aOYtD5ylURp_cnx2@chardros.imrryr.org>
From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Wed, 08 Oct 2025 09:56:27 -0500
X-Gm-Features: AS18NWBtNoJdYeNmqgOGG5H5qVcJl3uzfGCXv2eYnBX-BRC8x3BXYXHcq4qzmhM
Message-ID: <CAKZgXHqWHU7=zQThLOX3nfWOnGUOt2uY_LQOfRKHeQPVMJv5-g@mail.gmail.com>
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000059425f0640a6e45a"
Message-ID-Hash: CDIWVUXTQKU2JCYDSHZU5IISF24ZGZBM
X-Message-ID-Hash: CDIWVUXTQKU2JCYDSHZU5IISF24ZGZBM
X-MailFrom: ounsworth@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: [EXT] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/OSue8GihY1IO5oJ_sGaRWNBEubU>
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>

Hi Viktor,

Thinking about this more, the composite draft specifically allows for
alternate private key storages -- ie the CompositePrivateKey is only a
recommendation.

"""
Variations in the keygen process above and signature processes below to
accommodate particular private key storage mechanisms or alternate
interfaces to the underlying cryptographic modules are considered to be
conformant to this specification so long as they produce the same output
and error handling. For example, component private keys stored in separate
software or hardware modules where it is not possible to do a joint
simultaneous keygen would be considered compliant
"""

So if you have some underlying crypto module that can't do ML-DSA seeds,
then I think your "workaround" is to do the composite private key as one
P12 that contains two P8's (or something like that), and then within the P8
for ML-DSA, you have access to the full ASN.1 CHOICE thing. And that's not
even bespoke; that's just cobbling together RFC building blocks. The
CompositePrivateKey is an optimization, not a requirement.


> rather than just reuse the ML-DSA private key format (just as the RSA
ASN.1 version 1 key format is reused largely without changes).

But that's not true; we didn't just reuse the RSA ASN.1 key format; we
profiled it down to forbid CRT and multi-prime within a
CompositePrivateKey. We also profiled down the allowed encodings for ECC,
and we profiled down the allowed private key encodings for ML-DSA. The
LAMPS WG gave the authors very clear directions on this in Madrid to
profile down to a single encoding for each algorithm.


About ASN.1 within the composite encodings; we've also been around this
ring multiple times. Remember that Composites are in LAMPS only because
CFRG wouldn't take it; not because it actually has anything to do with
X.509. It's an _algorithm_ and the primitive we're defining here is being
reused verbatim across other protocols -- just on a quick search:

JWT: draft-prabel-jose-pq-composite-sigs
TLS: draft-reddy-tls-composite-mldsa

Yes, it's true that 30 years ago, all cryptography was done over ASN.1, but
that's not true anymore, and tying composite encodings to ASN.1 would harm
its adoption across other protocols. I hope that explains why we have
removed ASN.1 from the core composite encodings.


On Wed, 8 Oct 2025 at 04:21, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Tue, Oct 07, 2025 at 11:31:06PM -0700, Watson Ladd wrote:
>
> > > The PR in question affects only the *private key* format.
> > > Interoperability requirements for private keys apply only in the not
> > > very common case that such keys are exported across incompatible
> > > implementations.  The more typical situation is that the private key is
> > > used within just a single s/w stack.
> > >
> >
> > How are you measuring this?
>
> Well, exchange of private key material between stacks, unlike exchange
> of public keys, is not part of most protocol data flows, and so is
> unquestionably much less frequent.  The sensible *interoperable* choice
> for ML-DSA private keys is to support export/import of either or both of
> the seed or expanded key.  The encoding really should be the ASN.1
> choice form, just as RSA keys are encoded in ASN.1 form.
>
> But, if the only way to get expanded key support is with a bespoke
> length-discriminated encoding, then while regrettable, that'd at least
> overcome a key limitation of the current seed-only design.
>
> The argument that the ML-DSA key format cannot be a very simple ASN.1
> encoding is perplexing, but if that is a real obstacle and not a
> fundamental objection to non-seed forms, then perhaps we'll just need to
> cope with a regrettable bespoke format, rather than just reuse the
> ML-DSA privatre key format (just as the RSA ASN.1 version 1 key format
> is reused largely without changes).
>
> > I see Java, OpenSSL, Go all generating and exchanging private keys every
> > day. It's not uncommon to have a generation tool install a per user cert
> > and key that all applications are required to use to authenticate the
> user.
>
> The key can be converted to the requisite forms as part of key delivery.
>
> > Even on server side it's not always the case that the application code
> that
> > uses the cert is the same as the tool that generated the key pair.
>
> Both for users and for servers.  I've written server key provisioning
> tools that e.g. delivered, the same key material and certs both as a PEM
> chain file (for OpenSSL and similar apps), and as a P12 file (for Java
> apps).  Once a particular end-user has the key in hand, it is not
> typically or at least frequently re-exported.
>
> --
>     Viktor.  🇺🇦 Слава Україні!
>
> _______________________________________________
> Spasm mailing list -- spasm@ietf.org
> To unsubscribe send an email to spasm-leave@ietf.org
>

v2.38.3 | Report a Bug | By Email | System Status