Infrastructure support for GnuPG post-quantum keys

[have at anonymous.sex]

On Mon, 06 Jan 2025 09:09:28 +0100, Werner Koch <wk at gnupg.org> wrote 
(quotes rearranged):

>For initail key discovering (lookup) there are better methods:

Thanks for the tips.

>- Send the key with your initial may and start to build up trust.  
>(after all there must be some reason that you trust a mail address)

A question of netiquette:  Is it acceptable to do this on a first post 
to a public list?

To the end stated in OP, I have taken the liberty of hereby attaching a 
LibrePGP key with hybrid post-quantum encryption subkey and with the OCB 
feature flag enabled.  But I would not ordinarily send a key to a 
list—not even once (and especially not when FIPS 205/SPHINCS+ with its 
large signatures is implemented and used for long-term identity 
certification [C] keys).  It was my primary motive for attempting the 
keyserver.

When cold-contacting a stranger, I habitually attach one or more PGP 
keys as MIME type application/pgp-keys.  Users of some mail clients may 
need to be cautious about a wrong MIME type.

>-[...more suggestions...]
>
>- Distribute the key along with your mail address using the Web Key 
>directory.

What is the best practice for using WKD to distribute multiple keys for 
the same mail address, potentially with different PGP version bytes 
(v4/v5) during a time when early adopters of a new version want to 
continue supporting an obsolete version for awhile?  In preparation 
maybe to set up a WWW site, I’ve been intending to write a separate 
thread about that... here goes:

§ 3.1 of WKD (draft 19) states that a keyserver “may” return a revoked 
key and a new key in a single request as “concatenated key blocks”.  
However, it does not address the cases of:

  * Multiple valid keys.

  * WKD client acceptance of a key in a recognized version, when it is 
concatenated (prepended or appended) with a key is in an unrecognized 
version.  (It is presumed here that the packet formats are the same “New 
Format Packet” as defined in RFC4880/LibrePGP § 4.2; otherwise, it looks 
like binary garbage and packet lengths cannot be parsed.)

  * Prioritization of keys.  Prefer first?  Last?  Highest version?  Best 
crypto?

As a practical matter, in-the-wild client behavior needs to be tested.  
It’s a nontrivial problem; one of the major WKD clients is a “web app” 
which cannot be installed and scripted in a controlled test environment 
without an account on a remote server.

GnuPG’s behavior should also be tested by concatenating a v4/v5 key with 
a key in a nonexistent packet version, say v255.  If I take this up 
sometime, I will post to -devel.

I hope that I can find some automagical way for WKD to make all 
correspondents use the best key for me that they support, until I fully 
deprecate v4 keys.


Not-quite-OT:

>The concept of public keyservers is dead.  It worked well in a past 
>Internet with mostly friendly inhabitants.  But we are not anymore in 
>the 90ies and DoS is a major concern.  There is also the false 
>assumption of many users that keys from a keyserver are in any way 
>trustworthy.

And we are not anymore in the 90ies when the zeroth rule of security was 
not to run network-loaded executable code, most tech-savvy people 
disabled javascript and java in their WWW browsers (duh), people did not 
hide their mail addresses (good), mailservers accepted mail from 
friendly strangers without a stupid robot passing judgment on whether it 
should be silently junked (good), nobody except plan9 had proper UTF-8 
support (bad), timestamps were absolute and not relative time (good), 
SSL was only for shopping (bad), PGP users blithely documented their 
social graphs via Web of Trust (bad; thanks for GnuPG’s TOFU mode), the 
future author of NaCl had also not yet invented the term “post-quantum 
crypto” :-(, and people cared enough to have RSA tattoos and blue 
ribbons and such.

Did you know that early Hotmail worked in Lynx?  (Without PGP, of 
necessity for a few months when I was young and had limited options for 
Net access.)  Their frameset was tricky to navigate in Lynx, but it did 
work.

Not to put too fine a point on it, but I think getting more in-the-wild 
user PQ keys for the first major \*PGP implementation with usable PQ 
encryption would be consistent with the spirit of the Net.  GnuPG 2.5.1 
30 days after NIST final FIPS-203 = write code, protect users.

-- 
# Remember these on Wednesday, January 15, 2025:
https://web.archive.org/web/19971024171609/http://www.eff.org/blueribbon.html
https://web.archive.org/web/19971114041230/http://www.eff.org/pub/Legal/Cases/ACLU_v_Reno/19970626_eff_cda.announce
https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/23-1122.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: have-post-quantum-anonymous-sex.asc
Type: application/pgp-keys
Size: 3106 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/4732a382/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250107/4732a382/attachment.sig>