Hello Krzysztof,

On Thu, Aug 06, 2026 at 12:11:06PM +0200, Krzysztof Kozlowski wrote:
> On 05/08/2026 12:29, Uwe Kleine-König wrote:
> > On Wed, Aug 05, 2026 at 08:32:22AM +0200, Krzysztof Kozlowski wrote:
> >> While as much as I like key signing, I do not believe in
> >> Zimmermann–Sassaman protocol to work, because of people's negligence. It
> >> requires the participants to check if THEIR key is correct, but based on
> >> my recent practice (people generated new key and week later they lost
> >> password to it; people received my signed keys and could not decrypt the
> >> message because they never used encrypted email, people sent me emails
> >> asking to send their keys) I think it has significant risk of this not
> >> happening. People just do not understand the security principles here
> >> thus they do not think certain steps are an absolute requirement.
> > 
> > I see your point. However if Bob confirms his fingerprint on the
> > Zimmermann–Sassaman list is right while he didn't actually checked and
> > as an effect a forged certificate is signed, that's mostly Bob's
> > problem.
> > 
> > Also if Bob doesn't check his own fingerprint, he probably also doesn't
> > check the certificates he signs carefully and thus his signatures
> > shouldn't be trusted.
> > 
> > That's why a keysigning is about a *web* of trust where the (little?)
> > trust in each individual path between me and a given other person sums
> > up.
> 
> I am rather thinking of someone planting their key in place of the
> person's one, thus of course Bob will have a problem, but bigger problem
> is that I would sign malicious actor's key.

Yeah, I got that. And that probably helps the attacker that Alice has
confidence in Bob's alleged key and thus that's also bad for Alice and
might come with a loss of trust into your and my signature.

But note that this isn't unfixable for eternity. You can still revoke
your signature once the fraud becomes known to you.

> >> IOW, I do not believe people will check their key fingerprints and email
> >> IDs, they will gladly accept what you prepared on the server and that
> >> could have been modified by an attacker or mischievous actor wanting to
> >> prank us.

I already wondered if I should delete 2 or 3 random nibbles in each
fingerprint on the list (e.g. making my line

      0D25 11_3 22BF AB1C 1580  266_ E2DC DD91 _266 9BD6

instead of

      0D25 11F3 22BF AB1C 1580  266B E2DC DD91 3266 9BD6

such that I have to tell "F-B-3" additionally to convince the potential
signer that I really checked my fingerprint).

> >> That's why I require that the keys to be given to me must be prepared by
> >> that owner, not by a third party. I have some proofs that at least that
> >> key was in the possession of the owner, when he was preparing it. I will
> >> be happy to sign keys of developers given to me that way.
> > 
> > Last time I talked to Greg about these paper slips, he had trouble
> > finding gpg-key2ps on Arch and I prepared the postscript file for him :-D
> 
> 1. gpg --fingerprint your-name
> 2. Paste it to a TXT file without the "sub" parts
> 3. Copy+paste to fill up the page
> 4. Print and cut
> 
> No need for gpg-key2ps.

There is no *need* for gpg-key2ps, but it's convenient that you can just
do

1. gpg-key2ps ukleinek@kernel.org > mycert.ps
2. Print and cut

instead of your four steps above. (Actually I would recommend a step 1.5
in both your and my recipe to double check the output before further
processing, or at least use the fingerprint instead of your-name or the
email address.)

> >> I know that you want to speed it up, but honestly korg keysigning should
> >> not have that many participants, so exchanging key slips should be fine
> >> as I was doing in the past.
> > 
> > I think even if we're only 10 in the end, the speedup is noticeable. And
> > it also simplifies the actual signing process for everyone, as I will
> > provide a keyring of all the handed in certificates.
> 
> And now I have one more doubt because Bob, who I did not trust that he
> understands security principles of key signing (see my previous email
> why), might not verify that keys in above keyring are the ones from the
> paper. IOW, Bob will happily sign whatever you send him, to speed things
> up. Otherwise there is no speed up comparing to:
> 
> $ gpg --recv-key <here goes keyID, which one has to manually type, thus
> it is 100% verified>

`gpg --recv-key` has its own problems. You can use it with a full
fingerprint, but the Bob you talk about will probably use it with the
"long id", i.e. only the last 16 nibbles of the fingerprint (assuming
pgpv4). And it also doesn't give you 3rd party signatures which might
give a hint that the received certificate is valid without exposing you
to Certificate Flooding[1].

So getting the certificates to sign from a curated source (like the
keyring I'll provide, or WKD or the kernel pgpkeys repo or DNS) also has
its upsides. And I encourage you to not rely on my key collection, but
cross check it. But the effort to find a certain key and convince
yourself it's not forged obviously grows. So this is another trade-off
between security and comfort.

[1] https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding

Best regards
Uwe