Hi,
On Tue, April 12, 2016 12:13 pm, Daniel Kahn Gillmor wrote:
On Tue 2016-04-12 10:38:29 -0400, Derek Atkins wrote:
Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> writes:
[snip]
yeah, i thought about this and went ahead with an inclusion of (a)
anyway; think we don't need to specify any internal DB handles, but we
do need a way to communicate across external database boundaries.
Do we?
I concede that if we define the fingerprint for use as an *external* DB
handle, it's entirely likely (and reasonable) for implementers to use it
as an internal DB handle as well, but i don't think we need to specify
it as a target use case.
That's kind of what's happened already, and it's what brought us to where
we are.
If we say that use case (a) isn't a motivating use case for the
fingerprint, do we have a story to tell about how an implementation
might retrieve a specific key from an external database? or do we not
need to tell that story?
When a human needs to look up a key there is usually some other identifier
involved. Most likely it would be the UserID.
The way I see the process is:
1) I receive business card or some other form that has email + Fingerprint
2) I download key from some server using the email address
3) I verify the key using the fingerprint (to make sure it's the right one).
The fact that the fingerprint *could* be used as an identifier is what led
us to these questions.
If I want to verify a signature it can use the internal database ID -- no
human interaction required.
So I just don't see the use case where a human ONLY has a fingerprint
without any other identifying information and needs to download the key.
--dkg
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp