From: | Bear Giles <bgiles(at)coyotesong(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pgcrypto: PGP keyring FDW ?... |
Date: | 2024-11-08 02:42:59 |
Message-ID: | CALBNtw7Lr4TXRW7OH9iFTcJaTRqdEbHiFjxLVoEt9s2QeGtiqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wanted to bounce a few related ideas off people.
Foreign Data Wrappers
One of the biggest vulnerabilities of the current system is the need for
the client to know the PGP key. There's a better alternative for many (not
all) use cases - loading the PGP key from a file located on the server or
securely downloaded from a trusted source on an as-needed basis.
In other words - a Foreign Data Wrapper for PGP keyrings. The initial
milestone could be a readonly table containing:
- keyid
- alg
- not_before
- not_after
- public key
- secret key (if available)
I've included type --list-keys below. I know the FDW should include the
[SCE] flags and '[unknown|lultimate|...] values, and possibly the uid
values. (It would need to be text[]). Secret keys add a 'ssb' element.
UDT and UDF
This still exposes a lot of information so it makes sense to consider a UDT
for PGP_KEY and possibly more. This UDT can be opaque - the secret key can
be write-only. Otherwise the UDT can be a drop-in replacement for the
existing text and bytea UDFs.
A similar idea, one that I'm still exploring, is PGP_CIPHERTEXT. It's a
drop-in replacement for bytea but makes it easy to add type-safe functions
to extract metadata from the ciphertext.
The keyring FDW would return a PGP_KEY for the secret key. This prevents
the exposure of a secret key loaded from a keyring.
Sample output of --list-keys
pub rsa4096 2011-02-08 [SCE]
BFC61E9C8BE9942EAE818A95E5D9A0503AD31D0B
uid [ unknown] Fedora-SPARC (15) <fedora(at)fedoraproject(dot)org>
sub elg4096 2011-02-08 [E]
pub rsa4096 2015-07-25 [SCE]
5048BDBBA5E776E547B09CCC73BDE98381B46521
uid [ unknown] Fedora (24) <fedora-24-primary(at)fedoraproject(dot)org>
pub rsa4096 2015-07-27 [SCE]
8C6E5A80A399BABE791985BAB8635EEB030D5AED
uid [ unknown] Fedora Secondary (24) <
fedora-24-secondary(at)fedoraproject(dot)org>
sub elg2048 2015-07-27 [E]
pub rsa4096 2016-03-31 [SCE]
C437DCCD558A66A37D6F43724089D8F2FDB19C98
uid [ unknown] Fedora 25 Primary (25) <
fedora-25-primary(at)fedoraproject(dot)org>
pub rsa4096 2016-03-31 [SCE]
838BD48E1B70069F4111BDE91A185CDDE372E838
uid [ unknown] Fedora 25 Secondary (25) <
fedora-25-secondary(at)fedoraproject(dot)org>
sub elg2048 2016-03-31 [E]
pub rsa4096 2016-09-09 [SCE]
E641850B77DF435378D1D7E2812A6B4B64DAB85D
uid [ unknown] Fedora 26 Primary (26) <
fedora-26-primary(at)fedoraproject(dot)org>
pub rsa4096 2016-08-08 [SCE]
19AA0442249191098B3D80354560FD4D3B921D09
uid [ unknown] Fedora 26 Secondary (26) <
fedora-26-secondary(at)fedoraproject(dot)org>
sub elg2048 2016-08-08 [E]
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-11-08 02:45:44 | Re: Inconsistent RestrictInfo serial numbers |
Previous Message | Bear Giles | 2024-11-08 02:15:00 | pgcrypto: better memory management?... |