Subject: RE: WG Last Call, RFC 2510bis

From: Carlisle Adams <[email-masked]>
Date: Fri, 19 Jan 2001 17:15:14 -0500

Hi Magnus,

Very sorry for the frustratingly long delay in responding, but a number of
things (including the Christmas break!) have kept my attention away from CMP
for the past month.  Anyway, responses are embedded below.

> ----------
> From: 	Magnus Nystrom[SMTP:[email-masked]]
> Sent: 	Friday, December 22, 2000 9:01 AM
> To: 	[email-masked]
> Cc: 	Richards, Gareth
> 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.

> b) In ir, cr and kur message types, the CertReqMessages SEQUENCE
> has the following restrictions (see Appendix B4 and rfc2510bis-02):
> 
> 1. The SEQUENCE can contain one or two CertReqMsg structures.
> 2. The first request MUST contain a public key in the certTemplate.
> 3. The second request if present MUST NOT contain the public key
>    bits in the certTemplate
> 
> This therefore restricts server side key generation to situations where
> two certification requests are being made.  This seems overly restrictive
> especially in the kur/kup situation where an end-entity would generally
> only update one key pair.
> 
> It is not clear why the two CertReqMsg structures are restricted in
> this way. We therefore propose that restrictions 2 and 3 above are
> removed and that the two requests are treated equivalently.
 
Firstly, note that Appendix B is only a minimum profile for interoperability
purposes.  In practice, conforming implementations can do much more than
this profile (and, as you point out, may wish to do slightly different
things for kur/kup support).  That is, the restrictions given need not
govern day-to-day operation (this understanding is in accordance with normal
IETF rules of specification compliance).

Having said that, however, I will note that you are not the first person to
ask about this, and that this request seems perfectly reasonable.
Therefore, I will modify CertReq and KeyUpdateReq to remove restrictions 2
and 3 above (the restrictions will still apply to InitReq).

> c) Related to b), when a CMP client chooses not to include a public
> key in a certTemplate, how shall it inform the RA/CA of the
> particular algorithm it wishes the CA to generate a key for? And
> parameters - e.g. "Please generate a 1024 bit RSA key with F4 as
> public exponent".
 
In general, this could happen with a separate genMsg/genRep exchange (e.g.,
keyPairParamReq / keyPairParamRep, or perhaps a new pair as yet undefined).
Alternatively, a control could be defined to carry this information.  But
there is no syntax available to do this within CertTemplate today.  (Note
that RSA presents a bit of a difficulty because "parameters" have not been
defined for this AlgId, otherwise the keyPairParamReq/Rep could conceivably
be used for this algorithm.)

> Any clarifications or comments would be most welcome.
> 
> Thanks,
> -- Magnus Nystrom & Gareth Richards,
> RSA Security
 
I hope this helps to clear some things up!

Carlisle.

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 25 Jan 2001 15:32:21 -0800 (Pacific Standard Time)

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.

> 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.

> > has the following restrictions (see Appendix B4 and rfc2510bis-02):
[...]

> Having said that, however, I will note that you are not the first
> person to ask about this, and that this request seems perfectly
> reasonable.  Therefore, I will modify CertReq and KeyUpdateReq to
> remove restrictions 2 and 3 above (the restrictions will still apply
> to InitReq).

Thanks for this.

> > c) Related to b), when a CMP client chooses not to include a
> > public key in a certTemplate, how shall it inform the RA/CA of the

> In general, this could happen with a separate genMsg/genRep exchange
> (e.g., keyPairParamReq / keyPairParamRep, or perhaps a new pair as
> yet undefined).  Alternatively, a control could be defined to carry
> this information.  But there is no syntax available to do this
> within CertTemplate today.  (Note that RSA presents a bit of a
> difficulty because "parameters" have not been defined for this
> AlgId, otherwise the keyPairParamReq/Rep could conceivably be used
> for this algorithm.)

Ok. Presumably, it would be an advantage to include this in the cr or
ir message, which means that the PKIHeader.generalInfo alternative
would be suitable, since there doesn't seem to be much point in having a
genMsg/genRep exchange to establish the parameters. Seems more logical
to place the InfoTypeAndValue in the generalInfo.

Note however, that the meaning of 3.3.19.8 may change slightly now -
what we want to do is to send the AlgorithmIdentifer to the CA so the
EE would have to send a keyPairParamRep. This is a bit odd.

-- Magnus