RE:

[Andrew Probert <AndrewP@xxxxxxxxxxxx>]

This standard seems to be restricting capability based upon a bandwidth
assumption.  With the right business case, the bandwith may well be
available?

Why not have the MessageImprint as a PKCS#7 construct, in that way you
could service many options.

1)   SignedData with empty content (detached signature) would meet
current requirement
2)   SignedData with content would meet your request
3)   EnvelopedData sent in for timestamping would allow encrypted
content i.e. solving trust issue in TSA
3)a Specific encoding of PKCS#7 => SMIME payloads

Regards

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
+61 3 9690 8877

> -----Original Message-----
> From:	Denis Pinkas [SMTP:Denis.Pinkas@bull.net]
> Sent:	Wednesday, November 25, 1998 1:11 PM
> To:	Carmen Garcia
> Cc:	ietf-pkix@imc.org; cert-talk@structuredarts.com
> Subject:	Re: 
> 
> > Hi all,
> >
> > We are involved in a time stamp project.
> >
> > We need to send a request for a timestamp to the Time Stamping
> Authority including in the request itself alternatively the hash value
> of the data or the entire document.
> > Further we could ask for more than one timestamp, thus we need to
> put, in the same request, the number of required timestamps that the
> TSA should give back.
> >
> > At this point we have two questions to propose you for discussion.
> >
> > 1. In the time stamping request described into the draft "Internet
> X.509 Public Key Infrastructure Time Stamp Protocols" (at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt
> )....
> >
> > TimeStampReq ::= SEQUENCE  {
> >      version                      Integer  { v1(0) },
> >      reqPolicy                    PolicyInformation OPTIONAL,
> >      tdas                         SEQUENCE OF GeneralName OPTIONAL,
> >      nonce                        Integer,
> >      messageImprint               MessageImprint OPTIONAL
> >        --a hash algorithm OID and the hash value of the data to be
> >        --time stamped
> > }
> >
> > ....there is no reference to the possibility to send the ENTIRE
> DOCUMENT to be timestamped, instead of  the hash of the message.
> 
> This choice was deliberate. It saves bandwith, e.g. if the message is
> 2 Mbytes long, you do not send the whole message to the TSA, but only
> the imprint (160 or 128 bits). It also allows better performance for
> the Time Stamping server (responding to short messages improves
> performance). Another advantage is that the TSA does not see the
> content of the message and it cannot disclose the content to anybody:
> it places less trust in the TSA. For, at least,
> theses reasons, the message itself is never sent to the TSA.
> 
> > If we want to have the possibility to send the whole document into
> the request, how can be done? Can we include into the request another
> optional field in order to send the whole document? What kind of
> interoperability implications with others implementations could occur?
> Is this one the right way or are there other solutions?
> 
> See above.
> 
> > 2. As above, there is no a specific field to hold the NUMBER OF
> REQUESTED TIMESTAMPS. Can we work in the same way?
> >
> 
> You can send multiple such elementary requests in a single message:
> the transport layer is not mandated.
> 
> Regards,
> 
> Denis
> 
> 
> > Obviously the second point influences the format of the response
> described in the draft if we want
> > to receive in a unique response all the required timestamps.
> >
> > Regards,
> >
> > Carmen Garcia.
> >
> > _____________________________________________
> > Carmen Garcia
> > Software Engineer
> > _____________________________________________
> >
> > ________________________________________________________
> > http://www.latinmail.com. Tu correo gratuito en espaņol.
> 
>