Re: Comments on the PKIX Roadmap

["Parag Namjoshi" <parag@xxxxxxxxxx>]

>>
>> 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.)

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.

>>
> Okay except for the last sentence.  I thought [ETNPT] gave you a format
> to store the information locally (like on your HD).


>I wasn't sure if
> TSP provided the same function (thought I guess it could if you stored
> the message).  If you think the goal for [ETNPT] needs to be clarified
> we should do that in a separate e-mail thread about ETNPT and not just
> put it in the roadmap.