New keyserver at keys.openpgp.org - what's your take?

[Andrew Gallagher]

On 2019/07/01 14:26, Robert J. Hansen wrote:
> A thought that would unfortunately require an adjustment to the OpenPGP
> spec itself: why do we put certification signatures on the target's
> certificate, anyway?

I think it's mostly to do with key size. This works fine either way when
it's among peers, but in large organisations you'll tend to get one key
that certifies a large number of others, while the median number of
certifications made by any of the other keys is zero. Better to
distribute lots of keys each with one signature, than lots of keys with
no signatures and one key with all the signatures.

Also, given that there tend to be a small number of super-certifiers, it
is easier to trace back the possible verification paths given a list of
certifiers on a newly-encountered key. The question is rarely "what is
the list of the keys that I can verify?", and almost always "how can I
verify this particular key?". X509 uses this model also, and for the
same reason.

> The current debacle is completely the result of allowing *anyone* to
> append a cert signature to *anyone else's* cert.

Yes, which is why we've informally had "let the owner choose whether to
publish her incoming certifications" as best practice for a long time.
Cross-signing would enforce this, but the client-side tooling is lacking.

>> * It MUST cryptographically verify all fetched material.
> 
> Note that this amounts to "SKS must die".  SKS does no cryptographic
> verification of material.

SKS as we know it must die, but I think that has been obvious for a
while. Its reconciliation algorithm can live on, however. The crypto
verification doesn't need to be performed in the synchroniser. It might
be best if it didn't so that we don't run into potential issues re some
systems being able to verify, a new algorithm and some not. Better to
let the synchroniser just do its job, and move all the verification and
caching stuff to a higher level. It need not be in the same binary.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190701/40176aa4/attachment-0001.sig>