RE: Time Stamp and Notary Drafts

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Thanks for your comments.  My replies are embedded below.

> ----------
> From: 	Santoni Adriano[SMTP:santoni@sia.it]
> Sent: 	Monday, October 05, 1998 5:15 AM
> To: 	'Robert Zuccherato'
> Cc: 	'ietf-pkix@imc.org'
> Subject: 	R: Time Stamp and Notary Drafts
> 
> Regarding the nonce field in timestamp requests and responses: the
> draft
> says (at page X) that the TSA must include the same nonce value the
> requestor specified in his request, in case he did. But how is the TSA
> going
> to determine that the requestor did specify a nonne value? I can
> imagine two
> possible answers: either the nonce field is OPTIONAL in the
> TimeStampReq,
> too (and not only in the response), or a "blank" value is established
> by
> convention (e.g. zero).
> 
I had a request to include a second type of time stamp request.  This
lower quality of service request would be http based and would just
return a "blank" token without a message imprint or nonce.  Basically,
it would just be a signature on the current time.  This would be a lower
quality of service because without a trusted source of time, one could
not verify that the returned token was "fresh".  People would be able to
just go to a web site and pick up one of these tokens.  

I am in the process of adding this option and have included the nonce in
the token as OPTIONAL to allow for it, but haven't fully described it
yet.  If people want this service, I will include it.  Otherwise, I
won't and the option on the nonce will be removed.

Notice however that the way things are presently described, the nonce in
the token must be present if the nonce is present in the request.
However, the nonce is mandatory in the request.  Thus, using the present
protocol, the nonce is mandatory.    

> Regarding the timestamp response (token): would not it be useful to
> include
> a pointer to an on-line repository, supposed to be run by the TSA,
> were all
> tokens are held and made available to everyone for browsing and
> downloading?
> 
I am not entirely sure of the usefulness of this service.  How would
such a repository be used?  Could the tsaFreeData field be used for this
pointer?

> Remarks. The draft should make use, IMO, of the usual keywords (in
> all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD,
> etc.)
> as per RFC 2119. 
> 
Certainly.

> A more elaborate explanation of how to intepret the
> reqPolicy field and some real-world scenarios would also be helpful.
> 
I agree.  There is a need for a document describing time stamp policy
and time stamp practice statements.  These are all important issues.
However, in this document we are only trying to describe the protocol
that is to be used between these entities.  Discussion of actual policy
issues is outside of its scope.

	Robert.