RE: Time Stamping: comments on nonce field

["Juan G. de la Vega" <jgonzalez@xxxxxxx>]

Thatīs fine.

-----Mensaje original-----
De: Robert Zuccherato <robert.zuccherato@entrust.com>
Para: Robert Zuccherato <robert.zuccherato@entrust.com>; 'Denis Pinkas'
<Denis.Pinkas@bull.net>
CC: ietf-pkix@imc.org <ietf-pkix@imc.org>; 'Juan G. de la Vega'
<jgonzalez@fnmt.es>
Fecha: jueves 8 de abril de 1999 17:30
Asunto: RE: Time Stamping: comments on nonce field


Okay.  I will make it optional in both the request and response.

> ----------
> From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net]
> Sent: Thursday, April 08, 1999 6:10 AM
> To: Robert Zuccherato
> Cc: ietf-pkix@imc.org; 'Juan G. de la Vega'
> Subject: Re: Time Stamping: comments on nonce field
>
> Robert,
>
> Some refinements to your response.
>
> The nonce is there for systems that do not have their own reliable clock
> and
> thus cannot test the freshness of the response by simply looking at the
> signing
> time. This is a replay protection. This has nothing to do whether a hash
> of the
> message is or is not present.
>
> I would make it OPTIONAL both in the request and in the response and
> maintain
> the current text that says: " ...must be present if the similar field in
> TimeStampReq is present ..."
>
> Regards,
>
> Denis
>
>
> > > ----------
> > > From:         Juan G. de la Vega[SMTP:jgonzalez@fnmt.es]
> > > Sent:         Wednesday, April 07, 1999 5:39 AM
> > > To:   ietf-pkix@imc.org
> > > Subject:      Time Stamping: comments on nonce field
> > >
> > >         First of all, the declaration of this field in the request and
> > > token is somehow incoherent, while the nonce is mandatory in
> TimeStapReq
> > > (it is not declared OPTIONAL), the TimeStampTokenīs nonce is OPTIONAL
> but
> > > it is stated that "...must be present if the similar field in
> TimeStampReq
> > > is present..." and hence the clause OPTIONAL is meaningless and
> confusing
> > > for this field shall always be present.
> > >
> > As I have said in the past, this was a mistake that I made because I did
> not
> > manage to fully include support for TSA production of a "signed time".
> This
> > would be a token which does not include a nonce or message imprint.
> TSA's
> > could produce these tokens and make them available (for example on a
> > website) for anyone who wants to obtain them.  This will be rectified in
> the
> > upcoming draft.
> >
> > > I would suggest this field to be declared OPTIONAL both in the request
> and
> > > token or better deleted if we take into account the following:
> > >
> > >     As far as I understand, a nonce value is present in the request
> and
> > > token in order for the requester to be able to match the responses
> from
> > > the TSA with her requests when using an asynchronous transport. It can
> be
> > > argued that such functionality should be left to the transport layer
> when
> > > required, but furthermore I must say that the nonce is not necessary
> since
> > > matching can be performed using the "messageImprint" field.
> > >
> > Actually, the reason that the nonce is there and mandatory is to prevent
> > replay attacks.  Someone else could have obtained a time stamp on the
> data
> > before your request.  Thus, it is possible that the time stamp you
> received
> > is not "fresh".  Without a nonce, determining the freshness of the
> timestamp
> > is difficult.
> >
> >         Robert.
>