Dennis: If we are going to allow a certificate to include pointers to externally stored public keys, I think a solution that works for the Web PKI and other PKI environment as well. I would not object to the use of abridged certs as an option, but I would object if it is the only option.
Russ > On Oct 10, 2023, at 11:21 AM, Dennis Jackson > <ietf=40dennis-jackson...@dmarc.ietf.org> wrote: > > Hi Mike, > > On 30/09/2023 23:19, Mike Ounsworth wrote: > >> >> 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) > I think a bigger objection would be that caching the public keys is a > tracking vector and seems a bit redundant if the browser and server can do > session resumption instead (with less storage overhead). >> >> 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. > You could easily used abridged certs here, just with an enterprise specific > dictionary rather than the external public keys. That would let you reduce > the entire certificate chain to a few bytes, without having to implement any > key fetching logic in the TLS client. Would you be interested in that? It > would be easy enough to have a generic IETF draft for abridged certs schemes > and then a particular draft defining the WebPKI instantiation. I think Panos > may also be interested in a similar enterprise use case? > > I'm a little confused on why caching the public key independently of the > certificate is a good idea. It seems like a recipe for encouraging people to > issue new certificates without rolling new public keys, which would not be > great for security. > > Best, > Dennis > >> >> --- >> 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 <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
