On Tue 2016-04-12 10:38:29 -0400, Derek Atkins wrote:
Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> writes:
[snip]
I tend to agree with the discussion elsewhere in this thread that
"internal database ID" is *not* the defining use case for the
fingerprint, so i'm not including it here.
I think there are only two use cases:
a) looking up a particular OpenPGP key in some remote database like a
public keyserver
b) confirming that a particular key matches some out-of-band
communication
I would argue that (b) is more important than (a). Your use-case (a)
sounds more like a DB Handle, so arguably it should be elided because
you've scoped your specification saying that "internal database ID is
not the defining use case". Or are you saying that we have both an
internal database ID and an external database ID?
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.
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.
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?
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp