Comments on ETNPT

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Parag,

This E-mail was initiated by a comment on the roadmap, but since
Sean erecommned to discuss this separately I changed the title of
this thread to ETNPT only.


> >> Page 9: The text says:"
> >>
> >>    [ETNPT] was developed to use [DCVS] to maintain the trust in a
> >>    token issued by a non-repudiation Trusted Third Party (NR TTP) after
> >>    the key initially used to establish trust in the token expires.
> >>     I would propose instead:
> >>
> >> [ETNPT]was proposed to maintain the trust in a token  issued by a
> >> non-repudiation Trusted Third Party (NR TTP) after the key initially
> >> used to establish trust in the token expires. However, since TSP
> >> provides that service, its goal needs to be clarified.
> 
> The basic purpose of the draft is to keep alive the trust in "long living"
> non-repudiation tokens/certificates even after the key used by the *service*
> ( say TSA )to sign the token has expired. This is logical extension of the
> the services provided by TSA/DVCS for extending the lifetime of signatures ,
> to extend lifetime of their own signatures. (somewhat similar to "old with
> new" of CMP.)

I still have difficulties to understand the rational for the (rather
complex) scheme that is presented. The basic time stamping protocol
provides a token (TST) that allows to make sure before which time a
document and/or a certificate was signed. If some signed data needs
to be protected by a time stamp, it seems more natural to append the
TST to the data structure rather than going down a tree of
"NRStorage". 

In addition, the data structure that is presented is twice
recursive. :-(

Thus I am wondering the need for such a document. If you are present
in Washington, I would appreciate a talk on that topic.

Regards,

Denis

> The draft uses the CS (now "VSD") service from DVCS
> to "recertify" the original token/certificate. The  ASN structure
> (local storage format ) is defined so that opeartion of the
> recertification of token & later verification ( maybe after 10 years
> when service has changed keys , say 5 times ) can be performed easily.
> (This would be much simpler and faster than retrieving tokens from
> an archive , getting some kind of certification from the service
> provider about its authenticiaty ect which would involve human
> interaction thus (comparatively) much larger delays.)
> 
> The format also allows for linking multiple such tokens (very likely from
> different service provider ) for same data. (Each of these tokens
> can (and should) be recertified to keep alive the initial trust in the
> token.)
> 
> This is absolutely necessary in the case that your service
> does not provide for archiving . And even if the archiving
> is provided you may not want to put all eggs in one basket.
> As an example,you do trust the service to protect its signing key well
> but not with the lagre token archive over a long period of time.
> 
> I hope I have clarified the goals for the draft well enough.
> 
> Note : The draft is somewhat out of date since after it was written ,
> 2/3 versions of TSA & DVCS draft have come out.
> 
> Regards,
> Parag.