On 2020-09-15 at 13:29 +0200, Neal H. Walfield wrote:
On Tue, 15 Sep 2020 12:16:01 +0200,
Justus Winter wrote:
PQ keys being way off doesn't mean it is a good idea to come up with
features now that may stop working when PQ gets here.
Raising the maximum subpacket area size may help, but brings its own
problems, like increasing the size of signatures that need to be kept in
memory. Also, fundamentally, the problem is trying to stuff an object
The sun will explode. But, I'm still making plans for the future.
Indeed, just because a wire size limit is raised to 32 bits, that
doesn't mean apps should accept and read into memory up to 4 GiB of data
as a key.
Surely the sensible approach is to raise the size limit in the packet
structure now, so that we don't need to change yet again, but advise
implementers to think about reasonable limits and perhaps default to a
16-bit 64KiB limit unless and until cryptographic suites come along
which _need_ higher. Folks will need to update their software to
implement the algorithm anyway, so raising the parsed limit at that time
makes sense, and implementers should also be guided to skip past
subpackets for unimplemented crypto instead, so that they soft-skip
instead of aborting on larger packets.
It might even be worth example large packets for conformance testing, to
make sure they're handled gracefully?
I disagree that keyservers are going to die. Even signal has key
servers (and, think about all of the prekeys).
And this one is the reason for my speaking up: I think that there are
two different definitions of keyserver being used here. I also think it
important to understand the status because it explains the assumptions
which client implementations will need to make.
In the sense of some abstract entity you go to, to retrieve keys,
keyservers are a solid design choice. Nothing will kill that approach.
In the sense of the current reconciling network of OpenPGP keyservers,
using the SKS reconciliation algorithm, as implemented by SKS and
HockeyPuck, using an append-only data store for whatever data people try
to put into it, and traditionally run by volunteers: those keyservers
are dying.
When I ran one, there were routinely over 100 active keyservers
available for the pool selection algorithm to select from, and our work
on debugging, interop, and performance issues had resulted in
operational guidance which got the keyserver network to become reliable
enough that people once more started taking it for granted.
There are now fewer than 20 keyservers in the pool, 12 of which are run
by 5 operators (and over IPv6, 6/10 servers are from just 2 operators).
Reliability is now frustratingly low. The pathology leading to this is
probably off-topic for this list.
The keyserver design approaches available which implementers should
account for, IMO:
1. Validating non-synchronising keyservers, which require people to
account for each one and choose to publish to it; the Sequoia-based
https://keys.openpgp.org/ is a good example here, I use it, it does
not fill all the old use-cases but it works for what it does, is
performant, and is as close as we have today to "central keyserver"
plus "reliable (within constraints)".
2. <https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore>
Dan Gillmor's Abuse-Resistant Keystore spec is probably required
reading for anyone thinking of implementing any kind of keyserver.
Even if we don't get new peering keyservers out of it, the
terminology and profiles it defines are important for being able to
clearly communicate what folks are trying to achieve.
3. Federation, with a keyserver per domain, perhaps outsourced to
central servers; WKD is probably the sanest path forward here:
<https://tools.ietf.org/html/draft-koch-openpgp-webkey-service>
since it doesn't require updating DNS for each PGP key, and provides
a read-only template HTTP schema along the lines of PKS.
kernel.org, debian.org, various other OS distributions and software
projects are implementing this today.
There are others, but those are the three sets which I think developers
of OpenPGP key-using software need to be familiar with before designing
their remote key management sub-systems.
-Phil
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp