[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]