RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

Francois,

> However, the problem I see with a published TSA practice 
> statement is that
> it would not currently lend itself to automation unless XML 
> was used.  This
> is why in the first place I had suggested using the S/MIME 
> capabilities
> attribute to indicate any static information about TSA's capabilities.

I do not think, really, that a TSA client will need to be 'automated', as
opposing to been statically configured for using a particular TSA(s). You'd
never let a TSA client 'go in the wild and free hunt' for some TSA service
out there. The cost, the legal liabilities, the quality of service and a lot
of other factors contribute to the fact that a decision has to be taken to
which TSA to use. Before the TSA can be first used by the client. You
configure the client, telling it to use THAT TSA, with THAT hash algorithm,
with THAT TSA certificate or some other trust parameters. I see the
configuration of the client to be an essentual part of the whole
timestamping framework. But it is just my opinion.

I agree that having the TSA policy and capabilities structured as XML would
help automating the client configuration task.

> Checking the S/MIME capabilities attribute should not be a 
> major issue for a
> requestor since he/she must be able to use S/MIME to verify 
> the integrity of
> a TimeStampToken.
> 

timeStampToken is defined as basic CMS construct. The requestor does not
have to implement/use/understand full S/MIME in order to parse the token. 


> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> frousseau@chrysalis-its.com      Tel. (613) 723-5077 Ext. 419
> http://www.chrysalis-its.com       Fax. (613) 723-5078
>