Subject: Re: WG Last Call, RFC 2510bis

From: "Amit Kapoor" <[email-masked]>
Date: Thu, 25 Jan 2001 11:25:07 -0800

Magnus Nystrom <[email-masked]> on 01/25/2001 03:32:21 PM

Please respond to [email-masked]

To:   [email-masked]
cc:   [email-masked], "Richards, Gareth" <[email-masked]> (bcc:
      Amit Kapoor/Certicom)

Subject:  Re: WG Last Call, RFC 2510bis

Carlisle,

Thanks for your response. Some follow-up remarks below.

On Fri, 19 Jan 2001, Carlisle Adams wrote:

> Hi Magnus,
>
> Very sorry for the frustratingly long delay in responding, but a
[...]

No problem.

> > From:       Magnus Nystrom[SMTP:[email-masked]]
> > Sent:       Friday, December 22, 2000 9:01 AM
> > To:         [email-masked]
> > Subject:    Re: WG Last Call, RFC 2510bis
> >
> > Dear CMP and CRMF editors,
> >
> > In response to the last-call on rfc2510bis and rfc2511bis, we do have a
> > couple of related questions. While answers to these may exist in the
> > documents we have not been able to find them.
> >
> > a) What is a CMP client which receives a PKIMessage response with a
> > PKIStatus of "waiting" supposed to do? A procedure for CMP using TCP
> > as transport seems to be to use the pollRep/pollReq pair, but it
> > seems as if polling should be part of CMP rather than dependent on
> > its transport?

> A long discussion/debate occurred some time ago on the ca-talk list
> regarding whether or not polling belonged in CMP or in the transport
> layer.  There certainly was not consensus, but "rough consensus"
> (very rough!)  seemed to lean toward the transport layer.
> Therefore, the transport layer needs to deal with this in some way
> (e.g., a polling mechanism for TCP; perhaps nothing for e-mail --
> the client simply waits for an e-mail that contains more of the
> response).  In any case, nailing this down for the various
> transports is something that could/should be done in the transport
> draft.

If this is the case, then I suggest this to be documented in
rfc2510bis itself (the decision to defer polling to the transport
layer). But even if it is implemented in the transport layer there is
still the waiting status in CMP.  What is supposed to happen if the CA
returns this?

Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed.  If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.

AK> As Carlisle said we have had a long discussion/argument on this in the
ca-talk.  For exactly the same reasons
AK> outlined by you, Ronald and I wanted two new messages (pollRequest and
pollResponse) added at the CMP
AK> level to allow for polling.  This also addressed a concern raised by Peter
Biltzinger (TrustCenter) that there was
AK> no security at the transport level.

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 26 Jan 2001 09:06:28 +0100 (W. Europe Standard Time)

[...]
> AK> no security at the transport level.

Hm. Perhaps there is some support for this modification to CMP then? I
must say it appears cleaner, if the protocoll already includes a
"Wait-Come back later" status message, to also include a "I'm back,
what's the status" request.

-- Magnus