ietf-openpgp
[Top] [All Lists]

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

2019-04-16 15:46:07
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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp