RE: changes to CEM message structure

Scott,

I was referring to the draft-ediint-certificate-exchange-00 which I
submitted last month. Russ Housley express some concerns this overlapped
with efforts in PKIX. Dale Moberg spoke with Russ about implementing the
pkcs7 certs-only type as the format for distributing the certificate.

Kyle Meadors
DGI

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Scott Hollenbeck
Sent: Wednesday, November 03, 2004 6:48 AM
To: 'Kyle Meadors'; [email protected]
Subject: RE: changes to CEM message structure


Kyle,

Which working group document is the proposal below referring to?  The only
document currently under consideration by the IESG is the AS2 document, and
I can't find any mention of a CEMRequest element in that document.

-Scott-

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


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

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