Subject: CMP Discussion References

From: "Mikhail Blinov" <[email-masked]>
Date: Fri, 7 Jun 2002 09:56:43 +0100

Hi,

I've heard a lot of talk about the CMPv2 Interoperability Testing
but I failed to find any mailing list archives related to this activity
or any technical documents describing the results of it.

(The only document that I could find was the <draft-ietf-moskowitz-cmpinterop-00.txt>
Internet Draft dated June 1999, but it was too small to address all the questions.
I looked through the ietf-pkix archive but there were only a few discussions
related to the CMP details.
The CMPv2 Spec mentions the ICSA CA-talk mailing list but it seems to be gone
without a trace. Carlisle Adams pointed me to Bob Moskowitz and I tried to contact him
but with no response.)

I guess nobody is going to claim that the CMP Spec is sufficient for developing
an interoperable CMP implementation. So I am pretty sure that there was a lot
of technical discussion about how particular scenarios are to be implemented
and how various parts of the Spec are to be interpreted. I would appreciate
if somebody could point me to any resources related to this.

Just one example of what kind of questions I would like to find the answer to.

If 
* an RA batches several EE's certification requests into one NestedMessage
    like this
        {sender=RA; recipient=CA; transactionID=5; body=nested {
                sender=EE1; recipient=CA; transactionID=10; body=cr;
                sender=EE2; recipient=CA; transactionID=22; body=cr }}
* the RA establishes a connection to the CA and sends this message in the 
    pkiReq TCP message 
then 
how the CA is expected to reply ?

The CA cannot send several response messages like
        {sender=CA; recipient=EE1; transactionID=10; body=cp}
        {sender=CA; recipient=EE2; transactionID=22; body=cp}
because one pkiReq TCP message can have only one pkiRep response.

The CA cannot batch the responses in the NestedNessage like
        {sender=CA; recipient=RA; transactionID=5; body=nested {
                sender=CA; recipient=EE1; transactionID=10; body=cp; 
                sender=CA; recipient=EE2; transactionID=22; body=cp }}
because the pkiRep is not allowed to contain the NestedNessage.

The only scenario that I can imagine is that the CA replies with the finRep
and then establishes a separate connection to the RA and sends the 
NestedNessage with the responses in the pkiReq TCP message.
But overall it does not sound very interoperable with anybody.

Regards,
Michael Blinov

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 12 Jun 2002 11:22:03 -0400

Hi,

I have no idea.  The authors that were doing that draft have let it expire
and no one else has yet volunteered to take this on.

Carlisle.

> ----------
> From: 	Mikhail Blinov[SMTP:[email-masked]]
> Sent: 	Wednesday, June 12, 2002 9:14 AM
> To: 	Peter Gutmann; [email-masked]
> Cc: 	[email-masked]
> Subject: 	Re: CMP Discussion References
> 
> So.
> I appreciate the humour of Peter but seriously
> what's happened with the CMPv2 transport mapping ?
> 
> Michael
> 
> ----- Original Message ----- 
> From: "Peter Gutmann" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, June 10, 2002 11:39 AM
> Subject: Re: CMP Discussion References
> 
> 
> > "Mikhail Blinov" <[email-masked]> writes:
> > 
> > >The CMPv2 Spec does not address the transport issues. So what is the
> standard
> > >mapping of the CMPv2 to TCP/IP at present?
> > 
> > RFC 2068 :-).
> > 
> > Peter.
> > 
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 13 Jun 2002 14:34:01 +1200 (NZST)

Carlisle Adams <[email-masked]> writes:

>I have no idea.  The authors that were doing that draft have let it expire and
>no one else has yet volunteered to take this on.

Given the problems with the cmp-t draft and the fact that it doesn't do
anything which isn't already done in RFC 2068 (and 2068 has the benefit of
extensive real-world implementation experience and research going into it), is
there any actual need for cmp-t?  In other words since 2068 is a better-
designed, very widely-implemented superset of cmp-t, why not just let cmp-t
lapse?

Peter.