[OASIS Issue Tracker] (EBXMLMSG-86) Confusion about Content-Type for compressed and encrypted payloads

[ https://issues.oasis-open.org/browse/EBXMLMSG-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60369#comment-60369 ] 

Pim van der Eijk commented on EBXMLMSG-86:
------------------------------------------



Agree.  Furthermore:

[WSSSWA], section 5.2.2 (4) states that xenc:EncryptedData/@MimeType must "/match the attachment MIME part Content-Type header before encryption/". 
Since encryption operates after compression, at this stage the content type is "application/gzip". So in my view xenc:EncryptedData/@MimeType should be set to "*application/gzip*".


> Confusion about Content-Type for compressed and encrypted payloads
> ------------------------------------------------------------------
>
>                 Key: EBXMLMSG-86
>                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-86
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: AS4 Profile
>            Reporter: Sander Fieten
>
> On line 262 (PDF version) of the AS4 profile it is stated that "The content type of the compressed attachment MUST be "application/gzip"."
> This suggests that for compressed payloads the Content-Type should always be "application/gzip".
> On lines 266-267 however it is also stated that  "When compression, signature and encryption are required, any attached payload(s) MUST be compressed prior to being signed and/or encrypted" 
> This implies that the rules of the WS-Security SwA profile must be applied after compression. As a result the Content-Type header must be changed to "application/octet-stream"
> In the AS4 profile this should be made clear. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)