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> *On Behalf Of *Mike Ounsworth
*Sent:* Saturday, September 30, 2023 5:16 PM
*To:* 'LAMPS' <sp...@ietf.org>
*Cc:* John Gray <john.g...@entrust.com>; Markku-Juhani O. Saarinen
<m...@pqshield.com>; David Hook <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 <internet-dra...@ietf.org>
*Sent:* Saturday, September 30, 2023 5:12 PM
*To:* D. Hook <david.h...@keyfactor.com>; John Gray
<john.g...@entrust.com>; Markku-Juhani O. Saarinen
<m...@pqshield.com>; John Gray <john.g...@entrust.com>; Markku-Juhani
Saarinen <m...@pqshield.com>; Mike Ounsworth <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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
