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

From: Robert Zuccherato <[email-masked]>
Date: Wed, 12 May 1999 11:33:39 -0400

Michael;

My responses are below.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Wednesday, May 12, 1999 2:46 AM
> To: 	'Robert Zuccherato'; 'PKIX mailing group'
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> Comment1.
> The new draft does not address the problem of defining an optional 'tag'
> field to help associating a stamp with its origin.
> The need for the tag has been discussed intensively by the mail group, and
> I
> do not recall anybody arguing against it.
> 
As I said at the time, I'm not against this.  However, my records show that
there was also a counter-proposal asking that this information not be
included in the request (in order to prevent leakage of information to the
TSA), but that a new structure be defined in an annex that includes both the
tag and the presently defined token ("3 Time Stamping issues" from Denis
Pinkas on April 1, 1999).  This proposal also had some support and there was
the suggestion that the tag could be included by the requester as an
unauthenticated attribute in the token.  It was my impression that this was
acceptable to all.  However, in order to include this unauthenticated
attribute in an annex, I will need a concrete proposal and some text.

> Comment2
> The SerialNumber is defined as OPTIONAL. The need for having it is clear,
> it
> is not anyhow request-specific, or a difficult thing to implement for the
> TSA. So why is it optional?
> 
Actually, it isn't clear to me that it should be mandatory.  I may be wrong,
but it seems to me that the serial number is only required if the
application is going to be referring to tokens without actually presenting
the tokens themselves (i.e. issuer and serial number).  It isn't clear to me
that this will always be the case (unlike with certificates, for example).
Thus, I am reluctant to mandate their use.  

> Comment3
> in TSTInfo: "TSA services MAY produce "signed times" which are timestamp
> tokens that do not contain a nonce or message imprint and are thus not
> linked to any request". Does it mean that a stamp with the imprint but
> without a nonce is regarded as a 'signed time'.
> 
No.  Signed times are "timestamp tokens that do not contain a nonce or
message imprint".  

> Comment4
> The description of the precision field is somehow difficult to understand,
> and the name 'precision' is misleading. It is not a precision, it is the
> precision factor. I had to guess that 31.25 is actually a product of
> division of 1 by 32.
> My suggestion would be:
> "The precisionFactor field is an 8 bit signed integer. The actual
> precision
> of the clock is calculated as a power(2, precisionFactor). Negative
> precisionFactor value produces a precision as a fraction of a second - for
> instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec (31ms). This
> precisionFactor would account for the 50-Hz (20ms) or 60-Mh (16.67ms)
> power-frequency clock, for example. Note that this method defines a
> precision of a clock as 'being around the value', not as an exact figure."
> 
Your wording is probably easier to understand.  Absent any objections, I
will use that.

> Comment5.
> The socket based protocol is apparently borrowed from the CMP spec. Should
> we stop being shy, make one more step forward, and expand the CMP-defined
> messages by adding TSA messages? That is, the message will contain a
> proper
> PKIHeader (as defined by the CMP), and the PKIBody with ID=XXX (XXX > 23,
> as
> 23 is the last ID reserved by the CMP). The actual PKIBody would be the
> DER-encoded TSA message.
> This would set a good example for other PKI services, such as AC and
> Notary.
> 
I am hesitant to require the extra layer when it isn't really required.  The
PKIHeader would serve no purpose here.

	Robert.

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 May 1999 13:26:38 -0400

>>>>> "Robert" == Robert Zuccherato <[email-masked]> writes:

 >> Comment4 The description of the precision field is somehow
 >> difficult to understand, and the name 'precision' is
 >> misleading. It is not a precision, it is the precision factor. I
 >> had to guess that 31.25 is actually a product of division of 1 by
 >> 32.  My suggestion would be: "The precisionFactor field is an 8
 >> bit signed integer. The actual precision of the clock is
 >> calculated as a power(2, precisionFactor). Negative
 >> precisionFactor value produces a precision as a fraction of a
 >> second - for instance, precisionFactor=-5 would yield 2^(-5) =
 >> 0.03125 sec (31ms). This precisionFactor would account for the
 >> 50-Hz (20ms) or 60-Mh (16.67ms) power-frequency clock, for
 >> example. Note that this method defines a precision of a clock as
 >> 'being around the value', not as an exact figure."
 >> 
 Robert> Your wording is probably easier to understand.  Absent any
 Robert> objections, I will use that.

I have a concern but it is common to the existing text and the
proposed new text.

The term "precision" is not defined.  Several interpretations are
possible, but the most natural one is contradicted by the example.

If the intent is that it indicates merely the step size of the local
clock, the name should be "resolution", defined as the delta between
one time value and the immediately following distinct time value.

If the intent is that it indicates the worst case error, i.e., the
delta between the time value and the actual UTC when it was issued,
"precision" is ok ("tolerance" might be even clearer).  But in that
case, the example is misleading; while the tolerance of a 50 Hz clock
clearly can't be significantly smaller than 20 ms, it might very well
be a whole lot larger.

For the latter, some examples might be: (1) a fine resolution clock
closely synchronized to UTC, for example with GPS -- 1 ms.  (2) a
typical computer's clock synchronized to UTC once a day: 8 seconds.

Given a choice between the two interpretations, I strongly prefer the
latter (i.e., tolerance w.r.t UTC); reporting resolution seems rather
pointless. 

	paul

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 13 May 1999 12:02:29 +1000

Robert,
>PKIHeader would serve no purpose here.

I can see one apparent need for having something more in the protocol frame
then just Length,Flag,<TST structure>. That is, the originator info.
Otherwise, billing becomes a real problem.
CMP format would solve it by specifying the Sender in the header and signing
the whole lot ( so nobody can send a request on somebody else's behalf). Or
just a signature may suffice, as a minimum.

To me, billing alone can justify having more complex structure.

Regards
MichaelZ