Re: WG Last Call, RFC 2510bis

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

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?

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.

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

Any clarifications or comments would be most welcome.

Thanks,
-- Magnus Nystrom & Gareth Richards,
RSA Security