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

From: Peter Sylvester <[email-masked]>
Date: Mon, 3 Mar 2003 18:14:46 +0100 (MET)

Hi,

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.

Peter

> From: "Pere Fiol" <[email-masked]>
> To: "ietf" <[email-masked]>
> Subject: RFC3161(TSP): doubts about tcp protocol 
> Date: Thu, 13 Feb 2003 17:47:55 +0100
> 
> Hi,
> 
> I've developed a TSA but I have a doubt in TCP protocol: if a client
> sends a request to TSA with invalid TCP message (for example with a flag
> different of '00'H, with wrong number of bytes in length,...) What must
> do a TSA in this situations?? RFC3161 mustn't talk something about it??
> 
> Thanks and Best Regards,
> Pere Fiol

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 4 Mar 2003 17:01:54 +1300

Jean-Marc Desperrier <[email-masked]> writes:

>>[...] 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).
>
>What happens if the data is a human readable error message as ought to be the
>case for errorMsgRep ?

This is a wonderful circular argument: You need to have the TCP header in
order to return information about problems with the TCP header :-).  The
solution for this is obvious (and TSP has its own facility for returning error
information at the TSP-protocol level).

Peter.

---

From: Roger Younglove <[email-masked]>
Date: Tue, 4 Mar 2003 13:15:01 -0500

Todd,
The time stamp is a piece of evidence applied by a third party to a signed
document to show the time the document was digitally signed. This provides
evidence that the digital certificate was applied prior to its expiration
date and/or prior to it being revoked should that happen.

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [email-masked]
www.networksgroup.com

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2003 10:05 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: RFC3161(TSP): doubts about tcp protocol

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

----- Original Message -----
From: "Jean-Marc Desperrier" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 03, 2003 4:31 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol

>
> Peter Gutmann wrote:
>
> >Peter Sylvester <[email-masked]> writes:
> >
> >
of
> >>3161bis to indicate a procedure to get whatever kind of answer to this
> 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).
>
> What happens if the data is a human readable error message as ought to
> be the case for errorMsgRep ?
>
> >(I simpler alternative is just to forget about it and use HTTP transport,
> > 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.
>
>
>