Subject: TSP Draft 08

From: Denis Pinkas <[email-masked]>
Date: Wed, 14 Jun 2000 16:55:59 +0200

I take advantage of a pause on the mailing list about TSP, to post a
new draft and provide a summary of the main modifications performed
to produce draft 8:

1. serial number now matches with the definition of serial number
from RFC 2459.

2. The Authority Information Access (AIA) extension has been
replaced by a Subject Information Access (SIA) extension which
*should* appear in the son of RFC2459.

3. The field: 

extensions            [0] Extensions  OPTIONAL

has been replaced by:

extensions            [0] IMPLICIT Extensions  OPTIONAL

4. The explanations around the certReq field have been
corrected/clarified.

5. Time Stamps users must now be ready to accommodate serial number
integers up to 160 bits.

6. An additional field called ordering has been introduced in the
response after accuracy:

ordering                  BOOLEAN           DEFAULT FALSE,

This allows to build two categories of TSAs, whether ordering of
Time Stamp tokens from the same TSA within the accuracy of the
genTime (e.g. within the same second) is or is not a requirement.

7. The tagging of the two last parameters of the response has been
modified in the following way:

     tsa                   [0] GeneralName      OPTIONAL,
     extensions            [1] Extensions       OPTIONAL

8. The tagging of the three parameters of Accuracy has been
simplified:

Accuracy ::= SEQUENCE {
        seconds        INTEGER              OPTIONAL,
        millis     [0] INTEGER  (1..999)    OPTIONAL,
        micros     [1] INTEGER  (1..999)    OPTIONAL
}

9. A new item 6 has been added to the security considerations
section.

If you have any comment (I hope you have none. :-| ), please wait
until the new draft is made available.

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 15 Jun 2000 20:44:33 +0200 (MET DST)

I find it somewhat unelegant to change the functionality of
ordering is such an incompatible way. I think it
would have been wiser to at least inverse the meaning
or BOOLEAN ordering. 

It is not said anywhere whether a TSA has to set the ordering
in a identical way in ALL of its time stamps.

The ordering bit defines two different services; there is
no way fore a TSA to publish which of the services it supports,
there is also no way for the client to indicate whether
ordering or not is desired when requesting a time stamp?

The text says: 'Using a nonce always allows to detect replays'
This should be 'using a nonce reduces the possibility of replay attacks.'.

P

---

From: [email-masked]
Date: Thu, 15 Jun 2000 19:57:06 -0400

Peter,

I disagree that the addition of the ordering flag is creating any
incompatibility issue since the TSA document is still only an Internet Draft
that should not have been used to develop any commercial product until it
becomes an RFC. In addition, I think it is much more meaningful to require
the flag to be present to indicate that ordering is supported as currently
mandated by the latest TSA document.

I agree however that there must be a way for a TSA to publish which of the
ordering services it supports. As a minimum this should be done through the
TSA's policy and it could possibly be done through the Subject Information
Access (SIA) extension from the son of RFC 2459 if it contained a similar
ordering flag. By using the reqPolicy field a requester could then request
the appropriate service if a TSA offers different ordering services.

I also agree that the document should indicate if a TSA has to set the
ordering in a identical way in ALL of its time stamps. I would think that if
a TSA explicitly indicate that it will not support ordering (e.g. through
the TSA's policy or the SIA extension), Time Stamp tokens issued from this
TSA MUST NEVER have the ordering field set to true. However, if a TSA
explicitly indicate that it will support ordering, all Time Stamp tokens
issued from this TSA SHOULD have the ordering field set to true unless the
TSA can not longer do this because of some technical problems. This would
then be a good reason to use the value of one (1) in the structure
"PKIStatus" (i.e. grantedWithMods).

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Thursday, June 15, 2000 2:45 PM
To: [email-masked]
Subject: Re: TSP Draft 08

P

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 19 Jun 2000 21:36:16 +0200 (MET DST)

> mandated by the latest TSA document.

I did not say that the changings had created any incompatibility in
commercial products. 

I have said the spec is incompatible with the previous texts
Some parts of the text had been 'stable' since two years or so, and
get suddenly changed. Well, the token format is so small, that 
modifications of the actual syntax do not really influence product
designers to prepare all the other stuff. 

An implementation that used draft 7 spec and did not
set accuracy and by used a serialnumber that contains some encoded value
can easily retransform the serialnumber into genTime with the need
of using ordering for comparisions. 
Thje only problem is that when you receive such a time stamp, 
it doesn't tell that there is ordering.   

Since the very beginning the ordering was defined solely by the order
of the serialnumber. There was no even mention about the order of the genTime
values. Thus you could have all kinds of equal genTime values and 
even genTimes in different order than the serialnumber. 

In version 8 the serialnumber of the timestamp has no real purpose anymore
inside this protocol; it is not used at all in any
other protocol elements like in crls or esscertid etc. 

To resume (somewhat flame) : I disagree with Ed Gerck; the model is not broken,
there is simply no service model.   

> the appropriate service if a TSA offers different ordering services.
I would like to repeat a question that I had already asked several times
on that list: An equivalent of SIA was in drafts of X.509 and 2459. 
When did this disappear and why? There were two extensions, the other
one was telling something about a CA subject. 

> "PKIStatus" (i.e. grantedWithMods).

You suggest that a TSA that provides an ordered set may want to switch 
to a reduced service. 

Why not just giving an error? An application that really need an order
would have to loop and reask until a orderable stamp is returned. 
If the order is not necessary then I would use the other type of service. 

Or, if grantedWithMods is done, one can simply add a failurebit indicating
that 'order not guaranteed contrary of what is indicated in the TSA's cert.'

/P