Modified user ids and key servers and a possible security risk?

[Chris Knadle]

On Wednesday 25 August 2010 20:13:50 Hauke Laging wrote:
> Am Donnerstag 26 August 2010 01:45:07 schrieb Chris Knadle:
> > There's a problem with this idea, which is that there's no opportunity to
> > notify the client that there was a problem if the check is done /later/.
> 
> That's not a problem. You cannot require a server to make this decision
> immediately.

My definition of "later" is "after the client-server connection is closed".  
It is unusual for any specification to require decision to be made later than 
while the client-server connection is still open.

> The server can tell you that this decision is postponed and
> for how long it well be at most. The client can decide then to make a
> query at that time or later to check if the requested update has been
> made.

This now increases overhead by requiring the client to make several 
connections to the server to ask "did you do that thing yet?", also forcing 
the client remember what request was made in order to go check up on "half-
done" transactions.

This also messes up human feedback.  "Made the request, check back later" is 
not an actual answer.

> This way the information what kind the error was of is lost, though.

Humans need feedback of what the problem was.  "General Error" doesn't 
suffice.

> But if
> you like to make it more complicated then the keyserver could log failed
> updates and their check result so in case of error (no update visible to
> the client after the given check period) the client would upload the same
> data again and then the server could respond with the error information
> without causing CPU load.

All these problems become far simpler if the final response from the server is 
made during the client-server connection.  Without this there are state issues 
to remember and handle on both the client and the server side.

  -- Chris

--

Chris Knadle
Chris.Knadle at coredump.us
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100825/aecb1372/attachment.pgp>