Re: CONFIRM message in http used as transport

"Life is hard, and then you die." <ronald@trustpoint.com> Fri, 10 March 2000 16:45 UTC

Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15491 for <pkix-archive@odin.ietf.org>; Fri, 10 Mar 2000 11:45:21 -0500 (EST)
Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA23467; Fri, 10 Mar 2000 08:44:09 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 10 Mar 2000 08:43:03 -0800
Received: from gandalf.trustpoint.com (IDENT:root@gandalf.trustpoint.com [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23418 for <ietf-pkix@imc.org>; Fri, 10 Mar 2000 08:42:58 -0800 (PST)
Received: from ronald.trustpoint.com (ronald.trustpoint.com [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id IAA24216 for <ietf-pkix@imc.org>; Fri, 10 Mar 2000 08:43:40 -0800
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id IAA20565 for ietf-pkix@imc.org; Fri, 10 Mar 2000 08:43:40 -0800
From: "Life is hard, and then you die." <ronald@trustpoint.com>
Message-Id: <200003101643.IAA20565@ronald.trustpoint.com>
Subject: Re: CONFIRM message in http used as transport
To: ietf-pkix@imc.org
Date: Fri, 10 Mar 2000 08:43:40 -0800
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Transfer-Encoding: 7bit

> how can CONFIRM message be sent over http which used as transport of CMP?
> 
> the 3 way message exchange seems couldn't be done in http.
> 
> anyone who has an idea about this?
> 
> end entity can always stop the connection suddenly
> ( it makes things harder :-( ).

The different messages in a transaction are not associated with each
other via the connection. The association is done via the transactionID
field in the PKIHeader. So the Confirm may be sent on the same or on a
different connection, doesn't matter.  In fact, you may even be getting
requests for multiple transactions on the same connection, all
interleaved (i.e. just because a message arrives on the same connection
as another one doens't mean it belongs to the same transaction) - this
may happen, for example, when an http proxy sits between the client and
the server. You always use the transactionID to figure out which
transaction a messsage belongs to. The only requirement is that you send
back responses in the same order as the requests came in (this is an
http requirement, actually).

Note that this is the same when using TCP directly as transport.

Have a look at the latest CMP draft (draft-ietf-pkix-rfc2510bis-00.txt)
- it explains the transactionID field a bit better. Also, take a look at
the transport drafts (draft-ietf-pkix-cmp-http-00.txt and
draft-ietf-pkix-cmp-tcp-00.txt).


  Cheers,

  Ronald