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
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp