[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Comments to draft 6
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]