Personally, I am against any practical use of McEliece given all the other available options. 1MB public keys are unnecessary, impact performance, and are wasteful.
Regardless of the public key in the cert though, RFC7924 allows (with other caveats) for not sending the server cert (and public key) if the client has prior knowledge of it. So, it solves the issue for TLS at least in one direction. Are there any other uses for this draft? For example, what use-cases would see a material difference by omitting 1-2KB of the Dilithium or Falcon public key when the rest of the cert will still amount to 2-3KB (4-7KB if we add in SCTs)? From: TLS <tls-boun...@ietf.org> On Behalf Of Mike Ounsworth Sent: Saturday, September 30, 2023 6:19 PM To: tls@ietf.org Subject: [TLS] FW: [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt Hi TLS WG! This is both a new draft announcement, and a request for a short (5 min?) speaking slot at 118. We want to socialize the idea of X.509 certificates with external public keys (ie the cert contains a link and hash of the public key that can be fetched or cached out-of-band. The primary motivator of this LAMPS draft is Classic McEliece encryption certs, but we think this could also be valuable for TLS authentication certs. Consider the following two potential use-cases: 1. Browsers Browsers already have mechanisms to cache intermediate CA certificates. It does not seem like a big leap to also cache external public keys for the server certs of frequently-visited websites. (yes, yes, I know that the idea of caching server public keys runs counter to the desire for the Internet to move to 14-day certs. Shrug) 2. Mutual-auth TLS within a cluster Consider a collection of docker containers within a kubernetes cluster. Consider that each container has a local volume mount of a read-only database of the public keys of all containers in the cluster. Then container-to-container mutual-auth TLS sessions could use much smaller certificates that contain references to public key objects in the shared database, instead of the large PQ public keys themselves. --- Mike Ounsworth From: Spasm <spasm-boun...@ietf.org<mailto:spasm-boun...@ietf.org>> On Behalf Of Mike Ounsworth Sent: Saturday, September 30, 2023 5:16 PM To: 'LAMPS' <sp...@ietf.org<mailto:sp...@ietf.org>> Cc: John Gray <john.g...@entrust.com<mailto:john.g...@entrust.com>>; Markku-Juhani O. Saarinen <m...@pqshield.com<mailto:m...@pqshield.com>>; David Hook <david.h...@keyfactor.com<mailto:david.h...@keyfactor.com>> Subject: [lamps] FW: [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt Hi LAMPS! This is both a new draft announcement, and a request for a short (5 min?) speaking slot at 118. Actually, this is not a new draft. Back in 2021 Markku and I put forward a draft for External Public Key -- draft-ounsworth-pq-external-pubkeys-00 Hi LAMPS! This is both a new draft announcement, and a request for a short (5 min?) speaking slot at 118. Actually, this is not a new draft. Back in 2021 Markku and I put forward a draft for External Public Key -- draft-ounsworth-pq-external-pubkeys-00 (the only reason this is an -00 is because I included "lamps" in the draft name). The idea is that instead of a putting the full public key in a cert, you just put a hash and pointer to it: ExternalValue ::= SEQUENCE { location GeneralName, hashAlg AlgorithmIdentifier, hashVal BIT STRING } That allows super small PQ certs in cases where you can pass the public key blob through some out-of-band mechanism. Here's the mail list discussion from 2021: https://mailarchive.ietf.org/arch/msg/spasm/yv7mbMMtpSlJlir8H8_D2Hjr99g/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spasm/yv7mbMMtpSlJlir8H8_D2Hjr99g/__;!!FJ-Y8qCqXTj2!Zd43cLS69sWmcBMfl8B4DXLSmHivO2lV6eZBd1HGdOOH1HkbSdEkE6KLgwCFLkNgywEjJNS9cLsHiJFUdc1KAcLsfs2v7QC4E85ZS7KR6w$> It turns out that BouncyCastle has implemented this at the request of one of their customers as a way around megabyte sized Classic McEliece certs; it is especially useful for usecases where clients have a way to fetch-and-cache or be pre-provisioned with its peer's public keys out-of-band. As such, Entrust and KeyFactor are reviving this draft. We suspect this might also be of interest to the TLS WG, but I will start a separate thread on the TLS list. --- Mike Ounsworth From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Sent: Saturday, September 30, 2023 5:12 PM To: D. Hook <david.h...@keyfactor.com<mailto:david.h...@keyfactor.com>>; John Gray <john.g...@entrust.com<mailto:john.g...@entrust.com>>; Markku-Juhani O. Saarinen <m...@pqshield.com<mailto:m...@pqshield.com>>; John Gray <john.g...@entrust.com<mailto:john.g...@entrust.com>>; Markku-Juhani Saarinen <m...@pqshield.com<mailto:m...@pqshield.com>>; Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>> Subject: [EXTERNAL] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt A new version of Internet-Draft draft-ounsworth-lamps-pq-external-pubkeys-00. txt has been successfully submitted by Mike Ounsworth and posted to the IETF repository. Name: draft-ounsworth-lamps-pq-external-pubkeys Revision: 00 Title: External A new version of Internet-Draft draft-ounsworth-lamps-pq-external-pubkeys-00.txt has been successfully submitted by Mike Ounsworth and posted to the IETF repository. Name: draft-ounsworth-lamps-pq-external-pubkeys Revision: 00 Title: External Keys For Use In Internet X.509 Certificates Date: 2023-09-30 Group: Individual Submission Pages: 9 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pubkeys-00.txt__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBk-Pj4sTw$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pubkeys-00.txt__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBk-Pj4sTw$> Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ounsworth-lamps-pq-external-pubkeys/__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBkkYgTr5Q$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ounsworth-lamps-pq-external-pubkeys/__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBkkYgTr5Q$> HTML: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pubkeys-00.html__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBl7Vdm1HQ$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pubkeys-00.html__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBl7Vdm1HQ$> HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ounsworth-lamps-pq-external-pubkeys__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBkvqLzpPQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ounsworth-lamps-pq-external-pubkeys__;!!FJ-Y8qCqXTj2!fFxgFxvNeJTdMaLp5fvEIV3na4HQv08Bf45rm_nHnLspsbNAUvZrJ5ARZ4HCz0lX11oN90OXcEwsqbdWPhtqwBkvqLzpPQ$> Abstract: Many of the post quantum cryptographic algorithms have either large public keys or signatures. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and signature algorithms for referencing external public key and signature data by hash, URL, etc. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. The IETF Secretariat Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
