Subject: Timestamp: 04: comments

From: "Manger, James" <[email-masked]>
Date: Tue, 9 Nov 1999 11:02:40 +1100

Accuracy:
Why is 1 second the default?  This seems an arbitrary figure.  There is no
reason why clocks will have this accuracy instead of any other.  If you
really want 1 s as the default, use the ASN.1 syntax to specify this:
	accuracy [0] Accuracy DEFAULT seconds:1
I suggest keeping the field optional, but with no default value.  If absent,
no statement is made about accuracy (2 tokens from the same TSA can still be
meaningfully compared).

Token:
The timestamp token is the most important feature.  The request syntax is
far less important (it has no security associated with it).  Reorder the
draft to specify the timestamp token first, giving its syntax and explaining
the semantics for each field.  In a later section, define a protocol for
requesting a timestamp.

Serial number:
The timestamp token now has a "monotonically increasing" field and a
"strictly monotonically increasing field", even though the later has no
meaning other than its strict monotonicity and the former is trivial to make
strictly monotonic if the issuer desires.

Name:
The timestamp signer's name (often a large field) is identified in
triplicate: in the token as a "hint", in an ESSCertID authenticated
attribute, and in signerInfo.  Ditch the first, allow (but don't require)
the second and require the third.

Extensions:
Even though no critical extensions are defined you still need to state what
an application should do on receiving an unrecognized critical extension.
Better still, offer explicit extensibility via a SEQUENCE OF Attribute,
instead of Extensions.

---

From: Paul Koning <[email-masked]>
Date: Tue, 9 Nov 1999 10:17:53 -0500

>>>>> Manger, James <[email-masked]> writes:

> no statement is made about accuracy (2 tokens from the same TSA can still be

If you don't make a statement about accuracy, you cannot necessarily
compare tokens even from the same TSA.  It might be reasonable to
think you can do this IF the TSA hasn't rebooted in between.  (Then
again, a TSA implementer might also reasonably interpret "no
statement" to mean "NO statement at all"...)  But if you don't have a
known accuracy, that means you may not know what the clock will do
across a power glitch (because your OS timekeeping clock and your NV
clock may not match, and by not making an accuracy statement you're
making no guarantees about any bound on that offset).

> strictly monotonic if the issuer desires.

This terminology has been discussed before; it clearly causes
confusion (especially with the redundant "strictly" thrown in, which
suggests that plain "monotonically increasing" should be
misinterpreted as "monotonically non-decreasing").  Better would be to
state the requirement in plain English.  ("If token B is generated
after token A, the serial number of B must be larger than that of A,
for all A and B.")

	paul

---

From: "Todd Glassey @ GMTsw" <[email-masked]>
Date: Sat, 13 Nov 1999 17:46:50 -0800

----- Original Message -----
From: "Manger, James" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 08, 1999 04:02 PM
Subject: Timestamp: 04: comments

> the semantics for each field.  In a later section, define a protocol for

If the token architecture is important then I suggest that it is what must
be standardized. The rest of the draft is the specific use model for the
token itself.

Stephen Kent has authorized us to take the BERT Token Structure into STime
and actually that makes sense. However the Token from the existing TS Drafts
should likewise be done that way tand the existing draft rewrtitten to
accomadate this new architeture.

My feeling is that this will increase the public acceptance of both
standards proposals and that this is good for all.

> strictly monotonic if the issuer desires.

these are specific to the use models and should probably be standardized at
the use level.

> the second and require the third.

these are specific to the use models and should probably be standardized at
the use level.

> Better still, offer explicit extensibility via a SEQUENCE OF Attribute,

these are specific to the use models and should probably be standardized at
the use level.

The real big win would be rearchitecting the token so that it has
essentially a definable header and manifest so that one can determine:

    1)     What the token components are
    2)    What trust model services this token requires or is bound to
    3)    The state of the token itself
    4)    The use models for the token (i.e its policy)

Todd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Nov 1999 18:27:34 -0500

Todd,

We're moving forward with the TSP, based on the model we have adopted 
for TSAs.  That model does not require tokens to contain GPS 
coordinates, or some of the other sorts of data that BERT contains.

Also, just because I said it's fine for you to go the STIME WG with 
BERT does not mean that STIME will accept that proposal.  Since that 
WG has a narrow focus on securing NTP, it is not clear to me how 
receptive they will be to BERT, but that's their call.

Steve