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

Mike Ounsworth <Mike.Ounsworth@entrust.com> Tue, 21 January 2025 15:01 UTC

Return-Path: <Mike.Ounsworth@entrust.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 A8620C1E642F; Tue, 21 Jan 2025 07:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.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 pETQnyHiPzfR; Tue, 21 Jan 2025 07:01:16 -0800 (PST)
Received: from mx07-0015a003.pphosted.com (mx07-0015a003.pphosted.com [185.132.183.227]) by ietfa.amsl.com (Postfix) with ESMTP id BEC31C1DCDE5; Tue, 21 Jan 2025 07:01:14 -0800 (PST)
Received: from pps.filterd (m0242864.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50LDEgjS028463; Tue, 21 Jan 2025 09:00:20 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=mail1; bh=WmaPS5oyCTKlGn+WhrYexTnwFPRx +FkyE04OQaF5Evc=; b=KOiFMBln34icClC2vQ9sE+0LKernGsak3tz2LmxjXvFT /qrq47unzK90Pc9UzNZEjhBhsLYyfrfVCHFDAPV15FmmYZmmQLWcVqH+O+0NZcUp BNsj1NIIwqTU67Q99XniYwJHMniz82dAbiZcRHiK4pJ3m+gFz4CRjgxkzaL9cmkK XfAz/GW8H/RQNXXSkKuF1RZjiSjZZ4I5VdLoCiLkjnKI+BSZpDy7zluQhjYong/U miIXUQVUnutXBFJpHjTDarZ0MoXO6b+7olILphW+sy28XA98BkY5SUywV6jVpg+w rdojBtFqetP9Z0F7zoaqqu41MN3EAo8ZlA9dbkcPbA==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2045.outbound.protection.outlook.com [104.47.66.45]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 4489v59jg0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2025 09:00:15 -0600 (CST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kgX5fIr1C8xNdmbJi3/xbCnlf8SF4Q8PJEcEEZjQ0ZmA2PBm6R18CF0SbsyF/i387cGYSfiybjllVSshNwx0V9CO9fh+T6hiUuCMQ8AmkU4adj91auPA6inTt3+6IeZ7ktsXotszu/61wai8CMJlsNDQ+86zuOEJ/WrpP7s2q+5xaM6B3hWi3smgCr29G3KwhwT6yLioxtG1NAlH/VcsEj7UAdQVMHulZ76drBaFx6X2GTVfN4dZa63d0PnUSsOOmQP15oi7y5HYDm7bAocXkMQ0X5KD06PoQTP43MjXHoQd770iC949c4F137YDJ8XoHtrdeXQUDHJieykUWFcbIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hiYvfoEfSxdAFWeIvg8BfpA/++awSA63lxnLPwbKqgw=; b=gUSGWyUMR2wJXXvl8CN6Uv87yJhLj3m4NqmK4WfIrYJ8TNTuN6V8yFu7dGO9iQJWnyxq8ztW1RFE8bxtHnpSnKw4WUgzzCD1kkGaEM3qN2JqAv53spOBBkmIaRGlmzDdljos0h/x/B5OKquQ1Xj0Uy2OEP47rKkyB4ahIyxIOQJvJ3Ye7YCfUYtHR1qblhQM1tQR2u54Q4UEC0W9lung294Z5JdvyEOjauGW7maRqd0grOTVzcJbktjD3wRc8SXCc5PQ1DOuesvY375lmR4/UeW/QzVWxVXzv5NGorh2yHBPTW67Opwf2YeRNF9AxrLGDDMAPilUGRVYWLq/tecJAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by MW4PR11MB6788.namprd11.prod.outlook.com (2603:10b6:303:208::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.21; Tue, 21 Jan 2025 15:00:09 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::b93d:b2d:3ad8:9702]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::b93d:b2d:3ad8:9702%5]) with mapi id 15.20.8356.020; Tue, 21 Jan 2025 15:00:09 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: Russ Housley <housley@vigilsec.com>, Viktor Dukhovni <ietf-dane@dukhovni.org>, Tim Hudson <tjh@openssl.org>
Thread-Topic: [EXTERNAL] [lamps] Re: Request to Extend IETF WGLC for ML-KEM and ML-DSA private key format Specifications
Thread-Index: AQHbbA7+wRSkCaSnOUeZWrMQYe73R7MhTLlw
Date: Tue, 21 Jan 2025 15:00:09 +0000
Message-ID: <CH0PR11MB5739AE89ED949863BE8AB93E9FE62@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <Z4-ph-f_2sm5JTS2@chardros.imrryr.org> <A370B6D8-D9D2-4698-B406-A70F733E419F@vigilsec.com>
In-Reply-To: <A370B6D8-D9D2-4698-B406-A70F733E419F@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-Mentions: ietf-dane@dukhovni.org,tjh@openssl.org
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH0PR11MB5739:EE_|MW4PR11MB6788:EE_
x-ms-office365-filtering-correlation-id: 448a3f8c-e43e-4ded-d40d-08dd3a2c4c71
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|4022899009|366016|376014|7416014|8096899003|13003099007|38070700018;
x-microsoft-antispam-message-info: I0SrL5x9rLKAC3e5D32wpaKdiGwCFUI88ZPyabUeiFwBGHcIJzx3WlW+MIdvqlX6fWxV8i552sLGwjq1Ymzdvj0/inOKAW8/zpYQsz9BzIYNaCDovgrYQRcl9PTScELEtcF/My/WRf02l5oVarkTGqABwQa9i7JcdBUDM1fzmcWOHfL2rysbUNgHXaijxKeVKQ3+xS5dhBBOXkOzejR3AceKJPer50e6gAoqH7yCMFCTEL0lTxwpm5oveVE3lL9Ydoh6eAtRj8A2Nv4LFP+2lhQy190diA/bC74GKPrY20uFYQ8vrj5MUVygbmO4CEJJwb2MAcFPlvwcSca0Pnvi3a1QiIJGnrebvb1trkMAhnWW0o4D6AFJxGhekCRXSUZeRCAT6nRL+N+Vyk/zOYd2t3rJbnuJKXdVfY2bkEvHJa/X2nCtevtwoPLmJi92HeCH1qlOxMX+aGfTMF09zWDK+DA1lBeU1jDCXnRvZvrp5UX9pmf3LYF/VHlW66Q8EwctbrqFBOYr/VNLrFeKXl3qdsXT6EfLYXnrxytQQGx8XJIu20CpSt7fziDdvDqA4AgoOBZ+/dAJL3bqBP9vT5aDJgjQ1FNrX1RcbWWaqMOKLQ7NZUN9yFqJlsSDmfD/wg7GhkVwpx8OjrHPC9+hwuDhSAB7p3fcUBNauf+DKyMQX7C5LQtjtFhmHEO6OvueebF+Mjs71hpSjVQ8/UYtdnblFvjP9BhgcoyP6nWJ7hak+GPvoRDsNIh61fI6zmcFWiURWLB0OT5ABy83aBriNZaDIqKwwV8OVI7XxajWZIWpl/e+juDS92it1oZGkXjWHopIlponjxONf3WRQKxoCyXtW+sPs3g/cIrdWp3/oeT/T5FEHbhplTkpVjsrUt+g8Wz1lUP3k+6vPOXCB+onVIqokXABQPlO1teOMkMfKAyOdJO6KaLdY5ouWy6UMT0WjI/HFY7hJ/WhFGjyDrOAkGOwO8zv/KdVrWfKx/PjVstW84SEJ2b0LPaaiDfA1iWAbzBLp1UHojM+ggUt7czC7pe/Bj4IwTxmlY4sFs9TT1TbOeOnuIZY5F7Hrx3ToYXeIIyhzDluGk+/oD4qkxDOBeXmJqQngFTwXXM3LGa3wYV7tPEnFXJV9UpGOUNk8fPANsNvuETi5iTf09cDwyiDJKdB4ljXxyUO7CrKZuk4a1TE6Fv/2lW9DUJhvD37lgWD6mZoODkWr5yEIOPjk2uqCQg3tdVOZE/JfJBNUiKbZnj9+pRWA89AzUdSbX4HZA5Erz3c/BgddYHslv5eJJmg54x6cpocsO9pGr3dRgT2eDZFU2CFo7YAbzerFFD5ztwR1rXDtXNWp4oPExqJcSWblwK7mAUF2Q3BB51hrE1tIAzxfAu48Oq0fcpUrrq7bAfWZy4u
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR11MB5739.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(4022899009)(366016)(376014)(7416014)(8096899003)(13003099007)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: uQze86ywL9Ogbox6hNykaH/4YEcdrFyI6J+E/rFuBTWGkASQtlc+kqt9pyMym0SbzeX8qIAaSWs5OsNCyczjBcRj4b7wp2Zawt1QrR7vpoeH6lgGAkwIcM+b2sEaSMG17KQbA9h0dgilb/fqPveY/pwwdER7ewZuF/mW+rGi7q3FKblN/TRjr4Zii0P2Lz2geBIhPi1/AumhA2eH+6MjkBOBwmrXYqyswJkUJntMMFRm4vplxqVEtR/Lcb80bHtvEz0KjvJsj5cvZ02cT0OWEIKarn6e6dNABq507czylBUWHoRFW4Zh2HgBj9t/8eFLF9BpKvt7+9YIXdy6UAJjJMAgI5Lp8fFA5TrIWb9v7XD/7E3kKBfFL4Y87WeOzVL5GHBbdHftXiKnmXARaqvh1t8OsA/+vWDduaN8UexwTjfmVy6VFGLu194jjeIUhd2hggnQ/Uv2nMfr74LOBJ9Gf631Lz5cIHpacE959tvRYVaYXckUa8sUectyI/+i/JZZk5+Oaxwc56e7i6aE9DBDgM/+DQ9E4gHQWbGBe4OV+2X/zHNEa5QSqRj+g19SYwBRtIOlij2E7YsBA5LuVHwQHRRB7ybw5/RrtMq1++GeU826sl2BWYo6Phr9cOOw1ELmfW7Acb94dCUE2Euhlbcagfnntpe+8YlCPnGHizHFCzt/rAgsrJVoP1LClcrBHaNKOXQ4Q+uYxGxM+2zGTFRKSO4uBZR9F/icJwIumxE6Am0AgGLW88aenQWjxXd8KPT02io8cD5gJ4CJRpgt+tkWPRORn+dj7aLNaS8E476WHS8dQLSlmt5SccduHbB/641BZemsIeJuUeN3ymffOzPjodfrn8mxVRiC3R3nvKaOk+G+iZ5adGOQ20Pwi02O8/EsU1qt9M+HB9uqjbUpGORCSUW2RRJG6+5MVKWD6DgXTJYTDGPICL/sXD4Lu+b4X7aw9qKFdv5Qxmgpb5aOiCeWkOeP95AoO8C77XVB5A+IfyQpb2k84gjQEY7g+8Jo5f63S8Bffhb31eyqo1xeQYvjyVXI5vCgngFbTbtotxwBL3T40SurwBjdhuY+UE7WnvZI/Pbpl7cp9YEcZd1cTcvxBLD62iZIf11c1mpJXr+XvXir35R1fmjI+SXTNlgQmoBv6UHKWtjJJ7MFE11WdxJxAGOijDTQq7ds3Eo0L1YtN/701G+tsSjvjo3zW5vPKiAo6Jg1y4oXj0lH5MHso5IGxj1B1RKgr7b3IEPq6Mt2suQQ+kY1o+yhjrlPv9QmPKQrhzY876HFepRceyzVYycKsNWXIEMe1yct9j2GbgMXvMy4akSDEsRC5jMI7x9kSmQzEebj8wMQxRz6OwE37TMaKIulVdrJgdxPtnSbH+1IIB9Qi+wMuULPJHkyAWDY6GDur3vqi3T+Unwylt3Xd6B++0Q93vh8ftkjLErETnJmuCRznzg5Reruos11GX1JDI6Z4BQRw/DZ3EaXxzKndOLa8CdPUSz6iTpYTkR7xaJ38XVYEIvd7NriHjLe8Kftm9sp80br0GYxCVu3nnR9cdMcq2P1S2EnaVWyWsD3Yvc1r1LOUB7nb/YBRljH/z9CiJ1+kFLLLSBMEwYFX/cgd2ervA==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0065_01DB6BE2.DDFCE140"
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 448a3f8c-e43e-4ded-d40d-08dd3a2c4c71
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2025 15:00:09.1674 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wIvUz3eXz/pVmJxfn5XoSSYuA04Jfa+AQliKpmYCDjdFxOsOmqeIESDGlyZjDfsiwXt5kPeI4Coes08+vqbFWikE8jxZtSXzbpq545UTvc8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB6788
X-Proofpoint-GUID: C_0kVTHsogCAfs7Vu1slW1lxQCQab8eO
X-Proofpoint-ORIG-GUID: C_0kVTHsogCAfs7Vu1slW1lxQCQab8eO
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-21_06,2025-01-21_03,2024-11-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 spamscore=0 bulkscore=0 impostorscore=0 mlxscore=0 malwarescore=0 adultscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.21.0-2411120000 definitions=main-2501210123
Message-ID-Hash: OOY6JCEVIGUDTSM66G25AFFXBFCJIZBK
X-Message-ID-Hash: OOY6JCEVIGUDTSM66G25AFFXBFCJIZBK
X-MailFrom: Mike.Ounsworth@entrust.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
CC: "spasm@ietf.org" <spasm@ietf.org>, "lamps-chairs@ietf.org" <lamps-chairs@ietf.org>, "lamps-ads@ietf.org" <lamps-ads@ietf.org>, Dmitry Belyavskiy <dbelyavs@redhat.com>, Matt Caswell <matt@openssl.org>, David Hook <dgh@bouncycastle.org>, Robert Relyea <rrelyea@redhat.com>, Simo Sorce <ssorce@redhat.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [lamps] Re: [EXTERNAL] 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/_x2YkooxAt7eNd_1fDBKYpL6XnI>
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 Russ and LAMPS,

 

I support this open letter from the OASIS community. I think it makes good points. While I don’t agree with every detailed point, this open letter shares my concern that the draft LAMPS and OASIS standards as they are now are headed for interoperability nightmares. 

 

If I understand correctly, the core ask is for the authors of draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-dilithium-certificates to consider the following change:

 

OLD (well, current):

>    When used in a OneAsymmetricKey type, the privateKey OCTET
>    STRING contains the raw octet string encoding of the 64-octet
>    seed.

 

NEW:

>    PrivateKey ::= SEQUENCE {
>        seed OCTET STRING OPTIONAL,
>        expandedKey [1] IMPLICIT OCTET STRING OPTIONAL
>    }
> 

 

Personally, I think this is brilliant for a few reasons:

 

1. SEQUENCE allows you to carry SEED or Expanded or both with only one structure.

2. Leaving SEED untagged provides a small space savings for the already small seed value.

3. IETF makes technology, we don’t make policy. Only providing a way to encode SEED priv keys feels, to me, like an overstep into policy.

 

I believe the ball is in the court of the authors of draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-dilithium-certificates to comment on whether they consider this to be a friendly change.

 

 

 

ExternalMu-ML-DSA

 

 <mailto:ietf-dane@dukhovni.org> @Viktor Dukhovni,  <mailto:tjh@openssl.org> @Tim Hudson – while we are having this discussion, do we also need a thread discussing ExternalMu-ML-DSA? Does that also have an interop problem between draft-ietf-lamps-dilithium-certificates-06 and PKCS#11v3.2-08 ? In order to support this, I believe that at a minimum PKCS#11 would need to define an interface for ML-DSA.Sign( mu ) – ie where M and CTX have already been combined into Mu -- in order to support cases where Mu has been pre-computed by a separate cryptographic module. I have read section 6.67 of PKCS#11v3.2-08 and I do not believe that such an API has been defined. Would you be amenable to adding it? The argument here is that this is explicitly allowed in [FIPS 204] by the following comment in Line 6 of Algorithm 7:

 

6: 𝜇 ← H(BytesToBits(𝑡𝑟)||𝑀′ , 64) ▷ message representative that may optionally be computed in a different cryptographic module

 

And therefore the PKCS#11 API should support it.

---

Mike Ounsworth

 

From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, January 21, 2025 8:15 AM
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Cc: spasm@ietf.org; lamps-chairs@ietf.org; lamps-ads@ietf.org; Dmitry Belyavskiy <dbelyavs@redhat.com>; Matt Caswell <matt@openssl.org>; David Hook <dgh@bouncycastle.org>; Tim Hudson <tjh@openssl.org>; Robert Relyea <rrelyea@redhat.com>; Simo Sorce <ssorce@redhat.com>
Subject: [EXTERNAL] [lamps] Re: Request to Extend IETF WGLC for ML-KEM and ML-DSA private key format Specifications

 

Thanks for your note. Do you believe that you can complete your review by 31 January 2025? We look forward to hear more from this group. Russ > On Jan 21, 2025, at 9: 04 AM, Viktor Dukhovni <ietf-dane@ dukhovni. org> wrote: > > Dear



Thanks for your note.  Do you believe that you can complete your review by 31 January 2025?
 
We look forward to hear more from this group.
 
Russ
 
> On Jan 21, 2025, at 9:04 AM, Viktor Dukhovni <ietf-dane@dukhovni.org <mailto:ietf-dane@dukhovni.org> > wrote:
> 
> Dear LAMPS WG particants, chairs and ADs,
> 
> We, the undersigned, would respectfully appreciate the IETF WGLC
> on private format key specifications for PQ algorithms, namely
> draft-ietf-lamps-kyber-certificates-07 and
> draft-ietf-lamps-dilithium-certificates-06, being extended until
> the end of January for WG members and other interested parties to
> be able to fully consider the information outlined in this
> document. Presently we feel we are unable to both serve our user
> bases and conform to the proposed specification, and have little
> choice but to offer our users alternative private key formats.
> 
> We will represent keys in a manner that maximises their usability
> for our users. Specifically, the simplest ASN.1 encoding (see
> below) that can represent the {SEED}, the private/secret {KEY}, or
> both. We do acknowledge that our case is from the perspective of
> hindsight and that it is very unlikely that previous comments on
> the IETF WGLC drafts would have been in a position to take these
> things into account.
> 
> For those who do not closely follow the PKCS#11 and KMIP technical
> committees in OASIS Open, both of those standards have been
> tracking the various NIST specification updates and final
> publication and have early adopters working across ML-KEM, ML-DSA
> and SLH-DSA.
> 
> The consolidated viewpoint within the PKCS#11 and KMIP TCs is that
> we cannot mandate that all implementations (especially HW-based)
> must be able to support import and export of the SEED. 
> 
> For those not familiar with PKCS#11 version 3.2, which adds
> support for ML-KEM and ML-DSA the definitions for the private key
> for each algorithm are formed using three attributes -
> CKA_PARAMETER_SET, CKA_SEED and CKA_VALUE. The latest draft of
> PKCS#11 v3.2 is available at
> https://urldefense.com/v3/__https://groups.oasis-open.org/higherlogic/ws/public/download/72453/pkcs11-spec-v3.2-wd08.docx__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFokuLRJpu$ <https://urldefense.com/v3/__https:/groups.oasis-open.org/higherlogic/ws/public/download/72453/pkcs11-spec-v3.2-wd08.docx__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFokuLRJpu$> 
> 
> The PKCS#11 specification explicitly states the following:
> 
>    At least one of CKA_SEED and CKA_VALUE must be specified on
>    C_CreateObject. Tokens may reject creation requests that only
>    specify one of these values. For highest compatibility
>    applications should set both.
> 
> Similarly, for KMIP version 3.0 which adds support for ML-KEM and
> ML-DSA, the technical committee is closely aligned with the
> PKCS#11 technical committee and mirrors the recommendation to
> return both for maximum interoperability. The update delta to the
> latest draft of KMIP v3.0 is available at
> https://urldefense.com/v3/__https://groups.oasis-open.org/higherlogic/ws/public/download/72473/kmip-spec-v3.0-wd18-markup.pdf/latest__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFoj_gLKa1$ <https://urldefense.com/v3/__https:/groups.oasis-open.org/higherlogic/ws/public/download/72473/kmip-spec-v3.0-wd18-markup.pdf/latest__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFoj_gLKa1$> 
> 
> The KMIP specification explicitly states the following:
> 
>    At least one of Seed and Key SHALL be specified.
>    Implementations MAY reject operations involving managed
>    objects using this Key Format if only one of these values is
>    specified and that value is not supported by the underlying
>    implementation. For maximum interoperability applications
>    SHOULD set both Seed and Key. 
> 
> The various IETF drafts have operated on the assumption that it is
> possible to mandate {SEED} and that all other standards will
> correspondingly mandate it and that all the various
> implementations in cryptographic toolkits will also provide
> interfaces that always support the retention, import and export of
> the {SEED}.
> 
> The PKCS#11 and KMIP standards do not share this IETF assumption.
> Once you accept that multiple formats for import and export need
> to be supported then an encoding format to support multiple
> formats must be defined.
> 
> For a variety of reasons other standards groups and users have
> reached a different view to that of the IETF. We feel it would be
> a distraction at this time to debate the legitimacy of those
> reasons, our view is that we simply need to be able to support
> those users by implementing a more flexible private key format.
> 
> Maximum interoperability necessitates that implementations should
> export the {SEED} and the private {KEY} if possible, or just the
> private {KEY} (if the {SEED} is unavailable). For imports,
> whichever of these are supported by the ultimate implementation
> should be used (i.e. if the underlying cryptographic module or
> hardware solution supports {SEED} as an input, it should be used;
> if it does not then the private {KEY} should be used). In short,
> {SEED + KEY} is recommended, {KEY} is mandatory to support, and
> {SEED} is optional to support.
> 
> Separately, the decision to remove the ASN.1 encoding from the
> PrivateKey in PKCS#8 format is not only against standing and
> expected practice, but doesn't leave a sustainable solution to
> support both formats. PKCS#8 is ASN.1 at its core, and the use of
> PKCS#8 should reflect that (and does with every other algorithm).
> When combined with the requirement to support multiple formats,
> using ASN.1 to represent the alternatives is the natural outcome.
> 
> Like the IETF (“"rough consensus and running code"), actual
> implementation experience is critically important to PKCS#11,
> KMIP, OpenSSL, Bouncy Castle, and other major standards and
> implementations. Within OpenSSL, our collective experience is that
> length-based discrimination to distinguish input formats is
> fragile and should be avoided. Unambiguous ASN.1 tagging avoids
> such heuristics and better aligns with how the keys of all other
> algorithms are handled.
> 
> Both OpenSSL and Bouncy Castle have implemented support for the
> various changing formats over time - and attempted to maximise
> interoperability. The resulting code necessitated determination of
> the format by performing length check and other heuristics and as
> such is considered an undesirable approach. The history of such
> heuristics based code suggests that it is likely to result in CVEs
> as it results in additional complications.
> 
> Flexibility on input allows us to interoperate with other
> implementations, however, absent a format that can represent both
> the {SEED} and {KEY}, when we come to selecting an output format
> we'd have to place the burden on the user to determine which to
> choose. If {SEED}-only is selected there are interoperability
> issues, if {KEY}-only is selected there are interoperability
> issues. This leads to a conclusion that the maximally
> interoperable format is {SEED + KEY}. 
> 
> As interoperability is an industry-wide guiding principle, we have
> selected to output {SEED + KEY}, when possible, and {KEY} or
> {SEED} (whichever is available) otherwise. This will be in our
> next release (for OpenSSL this is version 3.5 which will be
> released in April 2025; for Bouncy Castle, this is version BC Java
> 1.81 which will be released April 2025). 
> 
> Therefore, the private key format that best serves our users and
> we are advocating the IETF adopt is:
> 
>    PrivateKey ::= SEQUENCE {
>        seed OCTET STRING OPTIONAL,
>        expandedKey [1] IMPLICIT OCTET STRING OPTIONAL
>    }
> 
> As opposed to the current definition at the end of section 5 of
> the draft:
> 
>    When used in a OneAsymmetricKey type, the privateKey OCTET
>    STRING contains the raw octet string encoding of the 64-octet
>    seed.
> 
> If the IETF Working Group decides to output {SEED}-only and not
> support {SEED + KEY} or {KEY}-only, it would interoperate on input
> with OpenSSL and Bouncy Castle, provided the seed is preceded by
> exactly four bytes of ASN.1 encapsulation. In hexadecimal, these
> are: 30420440, indicating a sequence of length 66 enclosing an
> OCTET STRING of length 64. The additional four bytes cannot
> reasonably be argued to be overly burdensome to produce on output,
> or to match and discard on input. Of course if that is the only
> selected option, interoperability will suffer as the specification
> would be unable to represent {SEED + KEY} or {KEY} alone.
> 
> OpenSSL Statement:
> 
>    We have working code that can accept all three input variants
>    and generate all three output variants proposed. We also
>    accept the existing oqs_provider ASN.1 encoded variants but we
>    don’t expect that others will do the same. The reworked code
>    is cleaner and clearer than our code based on length
>    heuristics and processes the ASN.1 encapsulation using a very
>    simple table-driven parser, without resort to our
>    general-purpose ASN.1 parser (this demonstrates how simple the
>    proposed format is to encode and decode).
> 
> Bouncy Castle Statement:
> 
>    We have working code that can accept both the proposal
>    detailed here and the {SEED}-only proposal. For output we will
>    attempt to echo the original encoding, although, particularly
>    for the case of ML-KEM, it has become obvious that we need to
>    follow  the proposal here (for the sake of our user
>    community), as import of keys for the {SEED}-only case may be
>    impossible for other FIPS providers where the direct
>    processing of encodings is outside of the FIPS boundary. We
>    will attempt to migrate {KEY}-only users to the proposal here,
>    which will (hopefully) limit us to just {SEED}, or the {SEED +
>    KEY} SEQUENCE.
> 
> Authors and Contributors:
> 
>    Viktor Dukhovni (OpenSSL)
>    Dmitry Belyavskiy (RedHat, OpenSSL maintainer)
>    Matt Caswell (OpenSSL Foundation President)
>    David Hook (Legion of the Bouncy Castle Inc,
>                co-founder and maintainer)
>    Tim Hudson (OpenSSL Corporation President, Cryptsoft CTO,
>                OASIS Open PKCS#11 Profiles Co-Editor,
>                OASIS Open KMIP Profiles Co-Editor,
>                Formal liaison between the OASIS Open PKCS#11 and KMIP
>                Technical Committees)
>    Bob Relyea (RedHat, NSS developer,
>                OASIS Open PKCS #11 Co-chair)
>    Simo Sorce (RedHat, OASIS Open PKCS #11 member)
> 
> -- 
>    Viktor.
> 
> A formatted copy of this note can be found at:
> 
>    https://urldefense.com/v3/__https://openssl-corporation.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFomtJOKcW$ <https://urldefense.com/v3/__https:/openssl-corporation.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFomtJOKcW$> 
> 
> A work-in-progress snapshot of of a proposed revision of the draft
> specification ML-KEM can be temporarily found at:
> 
>    https://urldefense.com/v3/__https://vdukhovni.github.io/ml-kem-certificates/__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFoiPnJTKG$ <https://urldefense.com/v3/__https:/vdukhovni.github.io/ml-kem-certificates/__;!!FJ-Y8qCqXTj2!aGxVd-jJAslvCx0lfOxnlOz7BzsneLUdhqGnasLFz3DtS0mUAtQTKr8MYU0AaKWDbDSlZMKwAFGE52di-TIFoiPnJTKG$> 
> 
> similar changes would be needed ml-dsa.
 
_______________________________________________
Spasm mailing list -- spasm@ietf.org <mailto:spasm@ietf.org> 
To unsubscribe send an email to spasm-leave@ietf.org <mailto:spasm-leave@ietf.org>