[secdir] Secdir review of draft-meadors-multiple-attachments-ediint-10

[Magnus Nyström <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines how to carry multiple, related EDI documents in
MIME using the multipart/related content-type and how to calculate
message integrity codes over such related documents.

Section 2.3:

a) Reference to MIC computation in EDIINT compression should be to
Section 4, not Section 2 of RFC 5402.

b)  For clarity, may want to replace the text

  "When a digital signature is applied to the multipart/related
   envelope, the MIC is calculated on the entire multipart/related
   envelope, including the MIME header and all attached documents."

with:

  "When a digital signature is applied to the multipart/related
   envelope, the MIC is calculated on the entire multipart/related
   envelope, including the multipart/related MIME header and all
attached documents."

c) Similarly, (as the sender performs the MIC calculation before
encrypting) I would suggest replacing:

  "For an encrypted but unsigned and uncompressed message, the MIC is
   calculated on the decrypted multipart/related envelope, including
   header and all attached documents."

with:

  "For an encrypted but unsigned and uncompressed message, the MIC is
   calculated on the unencrypted multipart/related envelope, including
   the multipart/related header and all attached documents."

d) I don't understand: "or an unsigned and unencrypted message, the
MIC is calculated over
   the data inside the multipart/related boundaries prior to Content-
   Transfer-Encoding.  However, unsigned and unencrypted messages SHOULD
   not be sent due to lack of security.": Why do the MIC-calculation
on the internal data only? Why not use the same algorithm (i.e.
include the outermost multipart/related MIME header?). Also, should
not canonicalization be carried out in this case?

Section 3:

- May be useful to use micalg SHA-256 (I realize this is an example,
but generally we'd like to move in this direction and so examples
should encourage it)?

Section 4:

- May be worthwhile to reference to S/MIME (RFC 5751) for Security
considerations in general for signed multipart/related messages.

-- Magnus