Download Firefox: WindowsMac OS X
logo       
Google Custom Search
    AddThis Social Bookmark Button

RE: changes to CEM message structure: msg#00001

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:kyle@xxxxxxxxxxxxxxxxx] 
> Sent: Tuesday, November 02, 2004 3: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




<Prev in Thread] Current Thread [Next in Thread>