Thanks for these details, John. This is exactly the sort of thing that
i wanted to start getting fleshed out.
On 05/08/2013 12:02 AM, John Clizbe wrote:
Daniel Kahn Gillmor wrote:
0) "I have no key material matching this name/keyid at all"
1) "I have too many keys that match this search to bother you with an
insanely long list"
You /must/ mean documenting how those two are already implemented?
well, this is how they're implemented in SKS, which is the defacto
reference implementation, for sure. so yes, documenting this in the
only public spec of the HKP protocol would be good.
X-HKP-Results-Count: number of matching keys
This header (i think you're implying that it is an HTTP response header)
doesn't seem to be used at all in GnuPG if i'm searching
git://git.gnupg.org/gnupg.git properly.
I know there are other HKP client implementations but (like sks on the
server side) gnupg is a sort of defacto reference implementation. If
it's not making use of this header, then it probably needs to be better
documented and patches pushed to gpg.
What should a responsible client do or assume if this header is absent
from an HKP response?
How should a responsible client respond if X-HKP-Results-Count is
greater than the limit query parameter? for that matter, limit itself
doesn't seem to be documented in draft-shaw-openpgp-hkp-00. This seems
like another detail worth including in any update. looking in
dbserver.ml, i don't see any corresponding offset= query parameter. so
if X-HKP-Results-Count == limit + 2, if an HKP client wants to get the
last two that were beyond the limit, they have to re-fetch the whole
list of keys. Is that right?
2) "something is broken in my database, and I'm confused"
Could you /maybe just possibly/ tie this down to something like a real error
condition instead of something so ambiguous? Taking a look at lines 245-307
of wserver.ml may be helpful.
I'm thinking here of the protocol from the perspective of an HKP client;
i don't think a client should need to know the gory details of how any
particular HKP server is implemented in order to be able to interact
with it robustly. While we may decide that there are certain error
cases that are common enough (or dangerous enough) to call them out
specifically in the protocol spec, it seems simplest to start by
specifying a general error code that we expect to be interpreted as
"Server broken, please try again later or try someone else" (perhaps
this is HTTP's "500 Internal Server Error"). It would also be useful to
provide guidance for how we expect a responsible HKP client to respond
to that error state.
For those of us who run sks or other keyservers behind reverse proxies,
there may also be system errors that come into play at the proxy level.
So having an explicit understanding of what sorts of errors HKP clients
expect to see and how they should handle them would help to inform best
practices for reverse proxy configuration.
It might turn out that these answers are all very simple. that's great!
in that case, let's document them explicitly, and then we can set about
testing the various HKP clients and reverse proxies to ensure that they
behave reasonably in the face of the expected range of responses.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp