Subject: Re: RFC3161(TSP): doubts about tcp protocol

From: [email-masked] (Peter Gutmann)
Date: Tue, 4 Mar 2003 07:19:19 +1300

Peter Sylvester <[email-masked]> writes:

>after more than 2 weeks of no response, it would be nice from the editor of
>3161bis to indicate a procedure to get whatever kind of answer to this
>question as a possible clarification into the 3161bis document.

Well, as a non-editor of 3161, I guess I can provide an implementor's comment
to help the original poster out: Since the TCP protocol in RFC 3161 serves no
identifiable purpose, and since I've seen implementations put all sorts of
weird stuff in there, my code just strips the TCP header out and uses the
ASN.1 data.  This means it works with any implementation, whether they get the
TCP protocol wrapper right or not (I think some do it via memcpy() of a
template, based on values I've had returned).

(I simpler alternative is just to forget about it and use HTTP transport,
 which has well-defined semantics).

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 04 Mar 2003 01:31:32 +0100

>>question as a possible clarification into the 3161bis document.
One possible solution would be that errors that can be detected at TCP 
protocol level without decoding anything in the data should receive a 
TCP protocol level error in return (errorMsgRep : 06).
3161 is restricting errorMsgRep to be only an answer to an invalid pollReq.
Is it really intended that it would be it's sole usage ?

In my opinion, it would make sense in a layer oriented handling of 
message to do that.
If the data didn't make it through the TCP protocol layer because that 
layer detected an inconsistency, then it will get back a TCP error.
If  the data makes it through up to the TimeStampReq decoding layer, 
then that layer will format a TimeStampResp message as an error response.

But for implementers, using only answers of finalMsgRep with the error 
inside the TimeStampResp would convert more directly to what is done for 
the http protocol (but you could map errorMsgRep to "Status: 403 human 
readable error\n\n" in HTTP).

>[...] my code just strips the TCP header out and uses the
What happens if the data is a human readable error message as ought to 
be the case for errorMsgRep ?

> which has well-defined semantics).
I agree.
In addition to other disadvantages, it's not necessarily easy to get 
access to port 318 enabled through firewalls.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 4 Mar 2003 07:05:10 -0800

So then the real issue is what are you trying to do with the timestamp?  is
it a piece of evidence and if so how is it sanctified?

Todd

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 04 Mar 2003 20:04:42 +0100

>it a piece of evidence and if so how is it sanctified?
This is a completely unrelated question, isn't it ?

It can be a piece of evidence, if you have a legal context that defines 
what is required for this.
Or a contract that defines what must be accepted.
The legal context does not exist now, but the "Policy requirements for 
Time-Stamping Authorities" document gives quite a few elements for 
constructing a trusted authority, and I have reasons to believe that at 
least in Europe the legal context will finally exist and have 
requirements rather similar to what is described there.

The timestamp itself is just a piece of data, and will have no more 
value than a qualified certificate profile conformant X509 certificate 
has if the required environment around is not there.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 5 Mar 2003 10:49:07 -0800

Jean Marc - TST's are only valuable if you can do something with them? so
what is it you would do with them and why? And then tell me why is that any
better than how it (time representation in transactional receipts) is done
today?

And then -  I ask you, if you replaced the timestamps in the massive DB
based applications with these particular TST's -

o-    would it (the use of the RFC3161 TSA/TST)  make the
        sanctity of the data models better?, and if so how?

        x-  would you add them (TSTs) to the record structures?

        x-  would you replace the standard Time Data blob with the TST?

o-    would it (the use of the RFC3161 TSA/TST)
        x-    Would TST use speed up any parts of the processing model, or
                not?

        x-    Would TST use slow down the processing model and if so how
               much? and for what gain?

        x-    Would TST use allow for the data models to stand up in court
                better and if so why (i.e. what is the legal-armor value add
                of using these TST's)

- PLEASE BE VERY SPECIFIC -

Todd

----- Original Message -----
From: "Jean-Marc Desperrier" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 04, 2003 11:04 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 07 Mar 2003 02:28:43 +0100

>- PLEASE BE VERY SPECIFIC -
Why should I ?
You are asking me to oppose RFC3161 token with DB Time Data blob which I 
never intended to do.

DB Time Data blob have their use and will never be replaced by RFC3161 
tokens in most contexts.
If the way you generate your DB time stamp offers enough garanty for you 
needs, then it can not be beaten.

The only think a RFC3161 token adds to a time data is a signature, and 
the real interest of that signature is to get an independent third party 
involved.
Only some specific application will really need to get a third party 
involved.
The second advantage is off-line checking.

If you'd restrict yourself to the cases where you can contact the third 
party on-line for checking, you could do only with records and no signature.
But it's very convenient to be able to check off-line.
If you are such a professional third party, you will like that most of 
the checking is done off-line, without being overloaded by the load of 
all the people constantly checking the data (this load has a cost, it 
might be a very high one).
For this kind of use, the overload of the 3161 token is not very 
significant, but the added convenience is.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 6 Mar 2003 20:51:13 -0800

----- Original Message -----
From: "Jean-Marc Desperrier" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 06, 2003 5:28 PM
Subject: Re: RFC3161(TSP): doubts about whole thing...

> The second advantage is off-line checking.

How so - What is the difference is reviewing logs automatically and
processing a token to see if it's math holds up?

> But it's very convenient to be able to check off-line.

The point of the token was to be of an evidentiary grade substance and such
that machiens could do "legal" things. But maybe that is not what is
needed - perhaps what is really needed is standards on how thes environments
around the transaction-envelope is to be managed. Then the proofing model
for the trust elements is much simpler to deal with. So now - with that
said - why do I need PKI based TST's at all?

The only answer was that by using PKI-enhanced TST's I can get the
transactional event granularity down to a single event or set of policy
decisions (this is the audit perspecitve of it).

> might be a very high one).

This is an assumption and its with this and many more assumptions that the
TSA was born. The problem is that we did not interact with the people that
would have to rely on this data service so we didnt understand that there is
really no difference in the quality of the transaction model whether the
PKI-TST is used or just plain time data is used. That's why the TST's
themselves need so much external data to reinforce or substantiate their
validity.

If we had looked at this better and understood that all that was needed was
an Evidentiary Receipt Standard and a method of representing that in a
smaller hashed data structure and this would have been done and put to bet
years ago.

> significant, but the added convenience is.

Nope - not from the bigger picture - stop looking at the use of the token as
a developer and start as someone looking for flaws in the external
transaction model or was to improve it. Then tell me what and why with
RFC3161 and I will listen.

I still think that RFC3161 - I am not in favor of trashing it - too much
work has gone into it - and it should be maintained but not as the IETF's
only time stamping standard.

NTP is now better that it ever was for these services and essentially can
provide similar TS generation facilities but has the added benefits of being
a real timing protocol. There are hundreds of millions of copies of it world
wide so it is ubiquitous in nature and TSA/TSP is not by comparison.  Also -
making NTP evidentiary in nature is inherently simpler than creating a new
TST from scratch - but hey who am I to say...

Todd