R: Time Stamp and Notary Drafts

[Santoni Adriano <santoni@xxxxxx>]

Thank you for you reply.

So, where you say "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" ...you imply that
whatever value the requestor puts in the nonce field of his request, the TSA
must copy that same value in the nonce field of the response (token), right?
If things are going to stay that way, I'd suggest to issue a new draft
(well, when the time is right for doing that) with the field "nonce" in both
the TimeStampReq and the TimeStampToken structures marked OPTIONAL. The
criterium that "if the requestor sends it, the responder must also send it"
can be explained, and declared REQUIRED, in the text.

The reason for having a repository URL in the response would be that of
binding the TSA to mantain an available online repository of all timestamp
responses ever generated (or, well, a large enough sliding window of them),
so that people may retrieve them at will in case they ever need. After all,
a timestamp response is much like a certificate (it just do not bind people
to keys but hashes to times), and a CA is suposed to have such a repository.
However, I agree that this concept needs more thinking (and, yes, the
tsaFreeData would be the obvious place to put that sort of information,
lacking other possibilities).

Regards.
  Adriano

> -----Messaggio originale-----
> Da:	Robert Zuccherato [SMTP:robert.zuccherato@entrust.com]
> Inviato:	luned́ 5 ottobre 1998 15.17
> A:	'Santoni Adriano'
> Cc:	'ietf-pkix@imc.org'
> Oggetto:	RE: Time Stamp and Notary Drafts
> 
> 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.
>