Subject: TSP interop update

From: Joe Morgan <[email-masked]>
Date: Wed, 16 Jan 2002 11:47:38 -0500

Just a quick update on our progress with TSP interop testing.

Cheers,
Joe

SERVER                           |   HTTP     |   TCP     |
                                 |            |           |
                                 |            |           |
Peter Gutmann                    |            |           |
host = tsa.cryptoapps.com        |            |           |
port = 3318                      |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
IAIK                             |            |           |
host = bais.iaik.at              |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
Datum                            |            |           |
host = 64.241.183.87             |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
SIA                              |            |           |
host = 193.203.230.166           |            |           |
port = 318                       |            |           |
policy id = 1.3.135.1.2.0        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
EdelWeb                          |            |           |
url =                            |            |           |
http://www.edelweb.fr/           |            |           |
   cgi-bin/service-tsp           |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.5309.1.2.2           |   SUCCESS  |   n/s     |
                                 |            |           |
                                 |            |           |
CNSG                             |            |           |
host = tsp.test.polito.it        |            |           |
port = 318                       |            |           |
policy id = 0.4.0.1.1.1          |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
C&A                              |            |           |
host = 195.223.2.6               |            |           |
port = 3318                      |            |           |
policy id = 0.4.0.1.1.1          |            |           |
url =                            |            |           |
http://195.223.2.6:8080/         |            |           |
   timestamp                     |   SUCCESS  |  SUCCESS  |

n/s = Not supported.
n/a = Not available.

--
Joe Morgan
[email-masked]
Software Engineer
Phaos Technology Corp.
http://www.phaos.com/

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 19 Jan 2002 13:49:37 +1300 (NZDT)

Jean-Marc Desperrier <[email-masked]> writes:
>Peter Gutmann wrote:
>>The RFC doesn't
>>specify any particular extensions which you have to (MUST/SHALL/SHOULD) handle
>>and says the critical bit is ignored (in violation of RFC 2459), so it looks
>>like accepting/ignoring anything that you "recognise" is fine.
>
>The text in the RFC sounds a lot more like any extension should be handled as
>if it had the critical flag, and the request rejected if you don't know
>exactly the meaning of the extension.

But "know exactly the meaning of the extension" is never defined.  If I get a
request with a subjectAltName (which my TSA did during interop tests) then
although I know perfectly well what a subjectAltName is I have no idea what I'm
supposed to do with it when I see it in the request.  Do I reject it or accept
it?  Since the RFC never defines any extensions which must be handled, all
extensions can be regarded as being unrecognised in the context of the RFC.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:02 +0100 (MET)

>  
> If we transpose this sentence in the context of TSP then we should have:
> 
> A server MUST reject the request if it encounters a critical extension 
> it does not recognize and in that case SHALL return a failure
> (unacceptedExtension); however, non-critical extensions MAY be ignored, 
> if not recognized.

X509 has an additional requirement which was added in a defect report, 
i.e., if an extension is known, then the interpretation is independant
of the value of the critical bit.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 14:57:19 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:

>It is simmple: if a client requests a policy and if the server supports that
>policy, why should the server choose a different policy ? Just to annoy the
>client ?

What if the client prefers policy X, but will accept anything if that's not
available?  This is standard procedure for restaurants, libraries, ...

Twitchen: "We'll have the duck".
Fawlty: "Duck's off, sorry".
Twitchen: "We'll have the trifle then".

TSP however requires:

Twitchen: "We'll have the duck".
Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
         trying to run a TSA here. Have you any idea how much there is to do?
         Go away".

Ah, we have an RFC which standardises Fawlty Towers.

Peter.