OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Timestamping


Trevor;

My response is below.

>   - You mention a client getting a timestamp from a TSA, which can be 
> verified by running a verification protocol with a TSA or 
> other authorized 
> 3rd party.  In this case, a client who wanted to verify a 
> timestamp would 
> only need to read the time from the timestamp, and enough identifying 
> information to know which verification service to contact.  
> The client 
> could treat the evidence (i.e. the BindingInfo data) as 
> opaque.  So maybe 
> our timestamp data format should be something like:
> 
> <TimestampData>
> 
>    <Time>
>      <!-- An indication of the time -->
>    </Time>
> 
>    <IssuingTSA>
>      <!-- URI of issuer, if exists -->
>    </IssuingTSA>
> 
>    <VerifyingTSA>
>      <!-- URI of a verification service, purely informative; 
> may occur 
> multiple times -->
>    </VerifyingTSA>
> 
>    <Evidence Type = "http://www.oasis.org/dss#SomeTimeStampType">
>      <!-- Linked/aggregated/accumulated values and so on -->
>    </Evidence>
> 
> </TimestampData>
> 
> Then it could be left to follow-on work (maybe even a later 
> document from 
> this TC) to define different <Evidence> types?  This is 
> similar to what 
> Karel's paper suggests, except his paper goes further in 
> describing generic 
> structures that can be used with all different linking 
> schemes.  That's 
> probably how things should be done eventually, but it seems 
> complex enough 
> that we should work on the core protocol first, and just make 
> sure it can 
> be extended in the future.

Actually, I would prefer to just leave a general extension mechanism that
could be used by later work.  For example, in Entrust's timestamping
submission we included an <Extensions> element:

  <element name="Extensions">
    <complexType>
      <sequence>
        <any namespace="##any" minOccurs="0" maxOccurs="unbounded"
processContents="lax" />
      </sequence>
    </complexType>
  </element>

I don't think there is any need to include any tags at this time unless we
have a clear use for them.

	Robert.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]