RE: changes to CEM message structure

["Richard Bigelow" <richard.bigelow@xxxxxxxxxx>]

Kyle,

Will the multipart have a start parameter?  RFC 2112 "The MIME Multipart/Related Content-type" says
3.2.  The Start Parameter

   The start parameter, if given, is the content-ID of the compound
   object's "root".  If not present the "root" is the first body part in
   the Multipart/Related entity.  The "root" is the element the
   applications processes first.

Normally, the root is the CEM request.  Making that explicit might avoid problems where parts are reordered or generated out of order.  For example, someone might generate the cert parts first and then the request, so the IDs are already generated when the request is built.  Of course, one could generate the IDs while building the request and then use them in the later cert parts, so either order works.  

If a profile is included, the root should still be the CEM Request.  The profile should be just another part with a distinguished type.  Receivers should be able to ignore this part.  (Logically, the profile should be the root, since the request is subsidiary to that.  But the format should be the same, so that profiles can be ignored.)

Perhaps you don't want to have a root.  Just process the request and certs-only parts and any profiles that are understood, and ignore the rest.  Order and root don't matter.  

Richard Bigelow
Inovis


-----Original Message-----
From: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]
Sent: Tuesday, November 02, 2004 12:07 PM
To: ietf-ediint@xxxxxxx
Subject: changes to CEM message structure



Per the CEM draft review by the IETF area directors, the draft editors were
informed the need to modify the format of the digital certificate
distribution to the PKCS#7 SMIME certs-only media type since this is a well
established standard.

Based on this, the draft editors would like to modify the CEM message
structure to something like this:

Content-Type:  Multpart/related; type=”ediint-cert-exchange+xml”; 
  boundary=foo
   --foo
   Content-Type: Ediint-cert-exchange+xml
     [CEMRequest XML]
   --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <end-entity123@xxxxxxxxxxx>
     [end-entity cert being exchanged]
    --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <ca-cert123@xxxxxxxxxxx>
     [CA cert to complete the trust chain on the end-entity]
    --foo--

The CEMRequest XML would be modified. The <ds:X509Data> element would be
replaced with a new element, say <Content-Id>, which would reference the
MIME Content-ID of the certificate in the multipart-related structure. No
other parts of the XML body would need to be altered.

The use of multipart/related is a natural choice since this was the future
direction of the profile exchange described in section 5 of the draft.

Does the list have comments on this suggestion? Are there other alternatives
we should consider? Unless there is reservations about this choice, the
draft editors will implement this multipart/related structure and resubmit
the updated draft both to the EDIINT list and the IETF area directors end of
next week.

Kyle Meadors
Program Manager
Drummond Group Inc.
615.384.5006


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004