Subject: CMP transport protocol - who should close the connection?

From: "Martin Lindström" <[email-masked]>
Date: Wed, 5 Jul 2000 15:24:13 +0200

Regarding draft-ietf-pkix-cmp-transport-protocols-00.txt:
One of the reasons of introducing a protocol for transport of
CMP messages was that interoperability testing showed that there
were no clear definitions on who should close a connection and
when. The new protocol tries to solve these issues, but during
the PKIForum initiated CMP interoperability testing I have run
into some cases not covered by the draft.

Suppose that a CR/CP is sent in one connection and when the
client is about to send its certConf it connects to the server
and sends the TCP message with the close bit set.
Should the client wait for the server to close the connection
or should it do it itself?
IMO the client cannot really do it itself since it must be prepared
to receive a pkiconf message from the CA (e.g. that the cert hash
comparison failed), and if the server does not close the
connection the client will either hang or timeout.

So what I want is that section 2.3 is extended with:
"If the connection close bit is set on a request, then the server
 MUST set the bit in the response and close the connection after
 sending the response. <add - begin> In the case the server does
 not intend to send any response to the client request, the server
 should close the connection directly. <add - end>"

Comments?

/Martin

********* Entegrity Solutions *********
 Martin Lindström, Systems Designer
 Finlandsgatan 60
 S-166 74 Kista, Sweden
 Direct: +46-(0)8-477-7735
 Fax:    +46-(0)8-477-7731
 Cell:   +46-(0)70-483-0024
***************************************

---

From: "Life is hard, and then you die" <[email-masked]>
Date: Wed, 5 Jul 2000 10:00:44 -0700

> Regarding draft-ietf-pkix-cmp-transport-protocols-00.txt:
[snip]
> connection the client will either hang or timeout.

The client has two possibilities: it can either do a shutdown on
the client->server direction immediately, or then it has to wait
for the response from the server.

As an aside, and a purely implementation problem, quite a few
systems don't properly support shutdown(). Hence it is usally
safer for the client to wait for the server response and then
doing a close().

>  should close the connection directly. <add - end>"

That case never occurs. The protocol is a request/response protocol
and there is *always* a response.

  Cheers,

  Ronald

---

From: "Martin Lindström" <[email-masked]>
Date: Thu, 6 Jul 2000 10:01:52 +0200

Ronald,

See my comments inline.

>for the response from the server.
Martin> But this doesn't solve the question. If the client does a
Martin> shutdown he will not receive the CA pkiConf (if any),
Martin> and if the client decides to wait for a response that never
Martin> comes, he'll hang unless the server closes the connection.

>and there is *always* a response.

Martin> Well, the case occurs during the PKIForum CMP testing anyway :-)
Martin> So what is the response to a certConf? RFC2510bis states that
Martin> a confirmation ack is optional.
Martin> Or, should the response from the server be a 'finRep' TCP
Martin> message in cases where no CMP response is to be sent?
Martin> In that case the transport draft need to be more clear.

/Martin

---

From: "Life is hard, and then you die" <[email-masked]>
Date: Thu, 6 Jul 2000 01:29:57 -0700

On Thu, Jul 06, 2000 at 10:01:52AM +0200, Martin Lindström wrote:
[snip]
> Martin> shutdown he will not receive the CA pkiConf (if any),

Of course he will - by shutdown I mean the standard shutdown()
socket call where you only close the client->server direction -
the server->client direction still stays open. This is *not* a
close(), which closes both directions.

> Martin> comes, he'll hang unless the server closes the connection.

See below.

> Martin> Well, the case occurs during the PKIForum CMP testing anyway :-)

Not unless somebody had a bug...

> Martin> message in cases where no CMP response is to be sent?

Exactly. I.e. there is always a response at the TCP level (and as
soon as certConf goes away then that is also true at the CMP level).

> Martin> In that case the transport draft need to be more clear.

Ok, will add some text.

  Cheers,

  Ronald