[lamps] Current efforts in the direction of draft-truskovsky-lamps-pq-hybrid-x509?

Iyán Méndez Veiga <imendez@ethz.ch> Fri, 07 July 2023 14:04 UTC

Return-Path: <imendez@student.ethz.ch>
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 4DFC2C151075 for <spasm@ietfa.amsl.com>; Fri, 7 Jul 2023 07:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 4zea-liDsEWX for <spasm@ietfa.amsl.com>; Fri, 7 Jul 2023 07:04:48 -0700 (PDT)
Received: from mailg110.ethz.ch (mailg110.ethz.ch [IPv6:2001:67c:10ec:5605::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C068C151064 for <spasm@ietf.org>; Fri, 7 Jul 2023 07:04:47 -0700 (PDT)
Received: from mailm214.d.ethz.ch (2001:67c:10ec:5603::28) by mailg110.ethz.ch (2001:67c:10ec:5605::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 7 Jul 2023 16:04:38 +0200
Received: from thinkpad.localnet (178.195.170.82) by mailm214.d.ethz.ch (2001:67c:10ec:5603::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 7 Jul 2023 16:04:44 +0200
From: Iyán Méndez Veiga <imendez@ethz.ch>
To: spasm@ietf.org
Date: Fri, 07 Jul 2023 16:04:43 +0200
Message-ID: <7857448.9X9Kdy9spX@thinkpad>
Organization: ETH Zürich
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: [178.195.170.82]
X-ClientProxiedBy: mailm114.d.ethz.ch (2001:67c:10ec:5602::26) To mailm214.d.ethz.ch (2001:67c:10ec:5603::28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ZDrD6KA1IxDM2CRCruljIn_woQs>
Subject: [lamps] Current efforts in the direction of draft-truskovsky-lamps-pq-hybrid-x509?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2023 14:06:08 -0000

Hello,

I recently found the interesting draft-truskovsky-lamps-pq-hybrid-x509, which 
I think it would allow a much smoother PQC transition.

Unfortunately, the draft has expired some time ago, and I couldn't find any 
derivative work apart from a small reference by Mike that this was 
standardized by ITU-T [1]. I guess he was referring to section 7.2.2 of their 
X.509 (10/2019):

https://www.itu.int/rec/T-REC-X.509-201910-I

There was also some recent mention to the draft in the IETF 116 Hackathon "PQ 
Use in the Read world: X.509 Keys, signatures, certificates and protocols", but 
I couldn't find any details.

It was also pointed out to me [2] that this approach was protected by a patent 
owned by ISARA, but later it seems they relaxed this restriction [3].

DigiCert seems to be testing this idea as well [4].

Could anyone summarize to me the current status of this work? Why this draft 
never got updated? Are there any plans to continue working on this with an 
active draft?

People from the Open Quantum Safe project have shown interest in implementing 
this, since it's a good approach with a straightforward backwards 
compatibility, but since changes have to be made to OpenSSL as well, and I 
quote here "not having this at least in active Draft state at IETF makes this 
a non-starter".

Looking forward to learning more about the status of this work.

Best regards,
Iyán

[1]: https://mailarchive.ietf.org/arch/msg/spasm/VJPJXLquDjEjEmRysiGrdsL-Nwc/
[2]: https://github.com/open-quantum-safe/oqs-provider/discussions/209
[3]: https://www.helpnetsecurity.com/2022/10/26/isara-digital-certificate-patents-quantum-security/
[4]: https://docs.digicert.com/en/certcentral/certificate-tools/post-quantum-cryptography.html#idm45907393047856