Compressed Data within an Internet Electronic Data Interchange (EDI) Message
RFC 5402
Note: This ballot was opened for revision 12 and is now closed.
(Lisa Dusseault) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Pasi Eronen) No Objection
Comment (2008-06-13 for -)
No email
send info
send info
Section 7, the sentence "is free of any intellectual property restrictions" seems to be taking a position regarding the validity and scope of IPRs -- please remove. The MIME entity example in Section 2 isn't actually a well-formed XML document (a well-formed XML document contains at least one element). Is the base64-encoded example in Section 2 actually valid? (I tried base64-decoding and parsing the DER, but the DER parsing failed around byte 50 -- I might be doing something wrong, though.). Section 7, "The worst case scenerio is an expansion of 5 bytes per 32K byte block." This expansion is for the DEFLATE algorithm; it doesn't include the overhead from ZLIB header or RFC 3274 structures (which for small documents, could be much more). Section 8: > [..] except for the fact that compressing data before encryption > can enhance the security by reducing redundancy of the file. The > lower the redundancy of the plaintext being encrypted, the more > difficult the cryptanalysis, see reference[CRYPTANALYSIS]. I'm not sure if all security experts would agree on this (if the encryption algorithm is good, compression won't enhance it -- and if it's horribly broken, it's not clear that compression would enhance anything, either), and the cited reference [CRYPTANALYSIS] doesn't seem to claim anything like this. I'd suggest just removing this text.
(Russ Housley) No Objection
(Chris Newman) No Objection
Comment (2008-06-16 for -)
No email
send info
send info
This inherits some fairly serious security considerations. Specifically, it uses RFC 3274, a standards track document that creates another back-channel to transport phishing and virus messages past common-use spam and virus filter technology.