Subject: RE: changes to CEM message structure

From: "Richard Bigelow" <[email-masked]>
Date: Wed, 3 Nov 2004 20:26:11 -0500

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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, November 02, 2004 12:07 PM
To: [email-masked]
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: <[email-masked]>
     [end-entity cert being exchanged]
    --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <[email-masked]>
     [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

---

From: "Kyle Meadors" <[email-masked]>
Date: Wed, 3 Nov 2004 19:48:45 -0600

Richard,

That is a good point. The multipart/related RFC indicates that the root
media type would be the "type" parameter. Since there is only one CEM
Request in the multipart, this would be implicit root without using the
start parameter. If it will reduce confusion, we could require the start
parameter. But like you said, I am not sure if the root designation and is
particularly important in this case since there will only be one CEM Request
element per message.

Kyle Meadors
DGI

-----Original Message-----
From: Richard Bigelow [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2004 7:26 PM
To: [email-masked]; Kyle Meadors (E-mail)
Subject: RE: changes to CEM message structure

Kyle,

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

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

Kyle Meadors
Program Manager
Drummond Group Inc.
615.384.5006

---

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

---