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


Dimitri;

> Verification of a token issued by a TSA implementing a simple 
> linking scheme is done by carrying out a verification protocol 
> with the issuing TSA 
...snip...
>  All communication must be done 
> over a channel providing data integrity and origin authentication 
> (for example, by using keys that do not need to last longer 
> than the transaction lapse).
...snip...
> Any verification protocol with a TSA or other authorized 3rd party 
> assumes that the verifier has established through out of band 
> means that the specific TSA or 3rd party may authoritatively speak 
> for the tokens issued in the name of the TSA named in the "tsa" field 
> of the timestamp token.

In other words, in order to verify the token you must still trust the TSA
(or some other 3rd party) and you must receive the verification message
protected for integrity and authenticity.  In practical terms, this means
protected by a signature of some sort, or possibly by a MAC using a
pre-existing shared key.  Thus, I fail to see the practical advantage this
scheme has over the traditional RFC 3161-style timestamps.  

Given that there are also IPR concerns, it is my opinion that the TC should
not put its effort into supporting these methods at this time.  This may be
something we would want to look at for a 1.1 or 2.0 draft however.

	Robert.


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