[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Observations on TST
Colleagues - I'll work on a revision of the Timestamp token specification. Specifically ... 1. Import and use the ds:Signature element definition. 2. Introduce an optional Issuer element. 3. Leave the Accuracy and Ordered elements as they are until we have completed further discussion and come to a conclusion. 4. Leave out the nonce for now. The issuer/serial will serve to uniquely identify the token. We can easily add it back, should we subsequently decide we need it. All the best. Tim. -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: Friday, August 15, 2003 2:57 PM To: Nick Pope; 'DSS' Subject: RE: [dss] Observations on TST At 09:32 AM 8/15/2003 +0100, Nick Pope wrote: > > Trevor wrote: > > One thing that worries me about the Accuracy field, as in RFC > > 3161 and the > > Entrust proposal, is that the client has to add and subtract the Accuracy > > field with the timestamp time to determine the upper and lower bounds. > > > > Isn't this non-trivial? The client might have to know how many > > days are in > > each month, leap-years, leap-seconds, that sort of thing. > > > > Would it be easier for the server to explicitly return an upper and lower > > bound, instead of an Accuracy? > > > >I am not expecting that the upper and lower bounds is the main interest. I >see accuracy as a quality indicator. Changing to upper and lower bounds >make it much more difficult to decide whether the time-stamp is accurate >enough for my purposes. That's true. I wonder if there's anyone with experience using RFC 3161 who can tell us how useful Accuracy is, and what it's most commonly used for. Trevor You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]