Subject: RE: CMP Discussion References

From: Carlisle Adams <[email-masked]>
Date: Fri, 7 Jun 2002 15:38:14 -0400

Hi Mikhail,

> ----------
> From: 	Mikhail Blinov[SMTP:[email-masked]]
> Sent: 	Friday, June 07, 2002 4:56 AM
> To: 	[email-masked]
> Subject: 	CMP Discussion References
> 
> 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.
 
Tim Polk and Bob Moskowitz have been putting together this document for the
purposes of submitting CMPv2 to the IESG for consideration as a Draft
Standard.  Every time I ask about this document, I hear that it's not
finished yet.

Tim:  any update?  CMPv2 has been ready to progress for a very long time
now...

> (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.
 
Very little discussion happened on the PKIX list.  It all happened on the
ca-talk list because that was the purpose for which that list was created.

> 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 don't know why Bob has not responded.

> I guess nobody is going to claim that the CMP Spec is sufficient for
> developing
> an interoperable CMP implementation. 
 
I'm not so sure that's true...  The interop testing uncovered a number of
things that needed to be clarified or added; CMPv2 incorporates all of this.
So, with respect to the messages that were tested (which did not include the
batch scenario you describe below, by the way, as this is not listed in the
mandatory-to-implement messages in the Appendix), I think it is reasonable
to assume that the CMPv2 spec is sufficient.

> 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 ?
 
I don't know what you mean by the "pkiReq TCP message".  If you are
referring to the TCP Management Protocol described in RFC 2510 Section 5.2,
then all that says is "pkiMsg", which is any PKIMessage.  Note that
NestedMessage is not something that is put inside a request message such as
ir or cr; a NestedMessage is the body of a PKIMessage.  Therefore, the
message from the RA to the CA is a pkiMsg TCP message, which is a PKIMessage
whose body is a NestedMessage.

Similarly, the response from the CA to the RA is a finalMsgRep TCP message,
which is a PKIMessage whose body is a NestedMessage containing all the ip or
cp messages.

> 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.
 
See my response above for how the CA answers.

Have I misunderstood what you're asking?

Carlisle.

---

From: "Mikhail Blinov" <[email-masked]>
Date: Mon, 10 Jun 2002 09:51:46 +0100

Hi Carlisle,

Thanks for the brief reply.

> referring to the TCP Management Protocol described in RFC 2510 Section
> 5.2, then all that says is "pkiMsg", which is any PKIMessage.  

I was looking at the CMPv2 Spec and the "Transport Protocols for CMP" 
<draft-ietf-pkix-cmp-transport-protocols-04.txt> document, which I assumed
was the recommended transport mapping for the CMPv2.
(The current PKIX Roadmap mentions this document as well.)
However, I just had a look again and have noticed that this document is
withdrawn from the official PKIX site. What's the story ?
The CMPv2 Spec does not address the transport issues.
So what is the standard mapping of the CMPv2 to TCP/IP at present?

Regards,
Michael Blinov