Skip to main content

Compressed Data within an Internet Electronic Data Interchange (EDI) Message
RFC 5402

Yes

(Lisa Dusseault)

No Objection

(Jari Arkko)
(Mark Townsley)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 12 and is now closed.

(Lisa Dusseault; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection (2008-06-16)
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.

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection (2008-06-13)
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.

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()