[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
There are some advantages with these methods from a practical point of view, mostly in the reduced number of values that are kept online. =20 On the other hand, disk space limitations are not what they used=20 to be six years ago :) These techniques do require a return trip=20 to the TSA to bind the token to the subsequent "round" value=20 (the token already contains a binding to the previous "round" value=20 when it gets issued). I hope this helps with your questions some. =20 > - You mention a client getting a timestamp from a TSA, which can be=20 > verified by running a verification protocol with a TSA or other=20 > authorized=20 > 3rd party. In this case, a client who wanted to verify a timestamp = would=20 > only need to read the time from the timestamp, and enough identifying=20 > information to know which verification service to contact. The client = > could treat the evidence (i.e. the BindingInfo data) as opaque. So = maybe=20 > our timestamp data format should be something like: >=20 > <TimestampData> >=20 > <Time> > <!-- An indication of the time --> > </Time> >=20 > <IssuingTSA> > <!-- URI of issuer, if exists --> > </IssuingTSA> >=20 > <VerifyingTSA> > <!-- URI of a verification service, purely informative; may occur = > multiple times --> > </VerifyingTSA> >=20 > <Evidence Type =3D "http://www.oasis.org/dss#SomeTimeStampType"> > <!-- Linked/aggregated/accumulated values and so on --> > </Evidence> >=20 > </TimestampData> >=20 > Then it could be left to follow-on work (maybe even a later document = from=20 > this TC) to define different <Evidence> types? This is similar to = what=20 > Karel's paper suggests, except his paper goes further in=20 > describing generic=20 > structures that can be used with all different linking schemes. = That's=20 > probably how things should be done eventually, but it seems=20 > complex enough=20 > that we should work on the core protocol first, and just make sure it = can=20 > be extended in the future. >=20 > Trevor >=20 > ...=20 >=20 I think Karel's document provides a lot of material for the necessary=20 XML elements. Dimitri
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]