Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver

[Daniel Kahn Gillmor <[e-mail]>]

On Tue 2019-04-16 21:56:14 +0200, ilf wrote:
> Daniel Kahn Gillmor:
>> I've only seen a few merge requests, and none of them from "ilf"
>
> Sorry, my Gitlab skills are weak. I created patches but forgot to create 
> merge requests. They are now submitted, but unfortunately against the 
> now-outdated version. I assume that some are fixed, but most should 
> still work to merge easily.

Wow, thanks!  I've reviewed and rebased all of those editorial cleanups,
and closed the series of merge requests.  Much appreciated.

> The "Terminology" section sais:
>
>> "Certificate discovery" is the process whereby a user retrieves an 
>> OpenPGP certificate based on user ID
>> "Certificate update" is the process whereby a user fetches new 
>> information about a certificate
>
> IMHO:
>
>> "Certificate discovery" is the process whereby a user retrieves an 
>> OpenPGP certificate based on the fingerprint (or key ID)

With this proposal, i think you're asking for three distinct changes,
all of them interesting, but which i aim to dispose of differently:

 * you are using the word "retrieve" where i had used either "retrieve"
   or "fetch".  Good catch, i'll use the same word consistently across
   the definitions.

 * You're including lookup by key ID, which wasn't previously mentioned.
   For what this draft defines as certificate update, lookup by key ID
   would be a mistake (because the client already has access to the
   fingerprint of the primary key).

   That said, this identifies a distinct use case, which is retrieval of
   an unknown certificate based on fingerprint or key ID alone (possibly
   of subkeys, not just primary keys!), typically at signature
   verification time, taking its parameter from the Issuer (i.e., keyid)
   or Issuer Fingerprint (full fingerprint) subpacket from the
   signature.  The section titled "Signature Verification and
   Non-append-only Keystores" mentions an architectural change (shipping
   the issuing certificate alongside a signature) that would make this
   use case unnecessary, but this draft should still call it out
   explicitly as it will continue to be relevant.

   I think the next draft will use "certificate discovery" to refer only
   to this third case, and will rename lookup-by-user-id to "certificate
   lookup".  Does that make sense?

 * you've conflated looking up a certificate (or a set of candidate
   certificates) based on their (spoofable) user ID, with retrieving a
   certificate based on cryptographically-verifiable hash.  These two
   use cases have dramatically different consequences for the
   architecture of abuse-resistant keystores themselves, which is part
   of what this draft is trying to tease apart.  So i don't think the
   draft should conflate them.

Let me know what you think, or if you have any objections.

    --dkg