<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Fri, 11 Dec 2020 17:56:24 +0000<br>From: Stefan Claas <<a href="mailto:spam.trap.mailing.lists@gmail.com" target="_blank">spam.trap.mailing.lists@gmail.com</a>><br>To: Casey Marshall via Gnupg-users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>>,<br>        <a href="mailto:sks-devel@nongnu.org" target="_blank">sks-devel@nongnu.org</a>, Casey Marshall <<a href="mailto:casey.marshall@gmail.com" target="_blank">casey.marshall@gmail.com</a>><br>Subject: Re: [Keyserver] Hockeypuck 2.1.0 released<br>Message-ID:<br>        <<a href="mailto:CAC6FiZ6EPR-eUD0AzMCVz7m4c9Hxga1iSfG7jSC2HXwsOvFmWA@mail.gmail.com" target="_blank">CAC6FiZ6EPR-eUD0AzMCVz7m4c9Hxga1iSfG7jSC2HXwsOvFmWA@mail.gmail.com</a>><br>Content-Type: text/plain; charset="UTF-8"<br>On Fri, Dec 11, 2020 at 10:25 AM Werner Koch <<a href="mailto:wk@gnupg.org" target="_blank">wk@gnupg.org</a>> wrote:<br>><br>> On Thu, 10 Dec 2020 11:07, Casey Marshall said:<br>><br>> >    - Authenticated key management. This adds a couple of extra endpoints<br>> >    which allow a key owner to replace and delete their key, authenticated by<br>> >    signing the armored key in the request. This allows a key owner to still<br>> >    update their own key once it has been inflated beyond the key<br>><br>> Finally after more than 20 years waiting for someone to implement such a<br>> feature.  Yeah.  Where can I find the specs?<br>><br>> Did you consider that an authenticated request to delete a key may not<br>> actually remove the key from the keyserver?  Instead the the primary key<br>> should be kept and the server prepared to receive and merge even<br>> unauthenticated revocation certificates.  This is important in case of a<br>> lost key (or passphrase forgotten) so that a pre-created revocation<br>> certificate can be uploaded.  Also avoids DoS after a key compromise.<br>Hi Werner and Casey,<br>I have a question for both of you.<br>When I reported a while ago on GitHub about a fake uat packet on Werner's<br>key you quickly fixed the issue and the added image of 'Donnie' no longer<br>showed up at the Ubuntu keyserver. Interestingly now GitHub shows zero<br>issues as of today, while yesterday still some issues where open and a lot<br>of them closed.<br></blockquote><div><br></div><div>Hockeypuck has several issues still open on Github: <a href="https://github.com/hockeypuck/hockeypuck/issues">https://github.com/hockeypuck/hockeypuck/issues</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Now my second question how is/was this done with Werner's key?<br>SKS still shows Werner's key with signatures, while the Ubuntu keyserver<br>shows only a very small key now. Before that the Ubuntu key server showed<br>the sigs too and additionally the fake uat packet (Donnie image).<br>Does this mean that a GnuPG user can modify his key in such a way<br>and re-submit it, so that the result is now like Werner's key or can a<br>Hockerpuck operator do this (on behalf) of the key owner? The key<br>in question, on the Ubuntu keyserver has also no longer a UID, which<br>I thought only sequoia-pgp can handle and not GnuPG.<br><a href="https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex" rel="noreferrer" target="_blank">https://keyserver.ubuntu.com/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex</a><br><a href="http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex" rel="noreferrer" target="_blank">http://keys2.andreas-puls.de:11371/pks/lookup?search=0x7b96d396e6471601754be4db53b620d01ce0c630&fingerprint=on&op=vindex</a></blockquote><div><br></div><div>The fix to this issue was to have Hockeypuck remove all packets lacking a currently-valid self-signature from responses. This removes fake packets (like the uat example) as well as expired identities. The self-signature on the UID packet in your example expired 2008-12-31, so it (and all of its third-party signatures) are pruned from the response. Only the public key packet remains.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Regards<br>Stefan</blockquote></div>