Re: [dss] Comments to draft 6

[Trevor Perrin <trevp@trevp.net>]

[I tried to send this out yesterday, but my ISP is having problems.  Simeon 
has already responded to it, but just for the record...]


At 09:01 AM 6/2/2003 +0000, simeon.sheye@cryptomathic.com wrote:

>Section 3.4.3 states that "The server may return the signature 
>immediately, or may return a transaction identifier, which instructs the 
>client to call back periodically and see if the signature is ready yet".
>
>I propose to move this into section 3.3 (generic request reqs). This would 
>allow the response to any request to be delivered either immediately or 
>delayed. The bullet in line 330 (section 3.5.2) should go with it.

As I recall there were 2 rationales for delayed response on the "signing" 
request/response exchange (I think we're in agreement this exchange is also 
going to be used for time-stamping):
  - where a human or other process has to approve the signature
  - linked timestamping may require it, in certain cases

I'll add those rationales to the document itself.  Is there a good 
rationale for allowing delayed response to the "verifying" request/response 
exchange?


>In section 3.7.4 ("time-stamp/time mark"), the text says "If the 
>verification was carried out for some time in the past (see 3.6.2, bullet 
>2), a time-stamp or time mark for that time should be returned as well."
>I think we should be cautious here because this makes it possible to 
>produce timestamps that dates back before the signature was actually created.
>I propose that back-dated time-stamps are ruled out completely.

Sounds good.  I'll take that sentence out unless someone disagrees.

Trevor