Re: AS#1 draft-ietf-ediint-as1-01.txt comments

[carl@xxxxxxxxx (Carl Hage)]

Chuck Shih (chucks@actracorp.com) wrote:
: I think I understand what you are getting at. Lets throw it out to
: the list and ask the question as to what people prefer:

[In simpler terms, should:

 1) the receipt contain a signature of a portion of the original message?
or
 2) the receipt be signed?

    (The portion proposed for (1) is the EDI interchange + Content-Type:
    Application/<EDI standard> headers. Note this does not include (i.e.
    countersign) the sender's signature or any other parts of the
    message.
    
    Methodology (1) fails for general use when the original message
    doesn't include a single signed piece of data, e.g. if the message had
    multiparts or attachments. Methodology (2) works for receipts of any
    message, and includes non-repudiation of the receipt.)
    
]

: 1). Sending a mdn back with a signed MIC in the MDN extension field.
:     The MIC that is signed in the MDN is what the receiver calculated
:     on the received RFC1767 and EDI Interchange. The MDN is packaged
:     as a multipart/report as specified in the fajman draft. This is
:     currently what is specified in the EDIINT Draft.

No, that's not what the draft says. (It's presumably an error.)

When I read the EDIINT Draft, I assumed method (2), though it wasn't
illustrated.

Here is the blurb:
<<<<<<<<<<<<<<<<<

   - extension field - the following extension field will be added in
     order to support signed-receipts for RFC 1767 specified content
     types and multi-part specified content types which includes RFC
     1767 content types. The extension field is sent only when the
     received contents are successfully processed.

   - extension field = "X-"  "Received-MIC"  ":"  MIC 

MIC or message integrity check, is defined as the result of a one-way
hash function applied to the received EDI Interchange and RFC 1767 MIME
content type information, or the multi-part MIME content containing
RFC 1767 MIME EDI content information. The MIC is also referred to as a
MD5 or message digest. The MIC that is returned in this message
disposition notification extension field is signed with the receiving
trading partner's private key.

>>>>>>>>>>>>>>>>>

The draft says this is a MIC not a signature. (The draft is presumably
wrong because there is no signature and no non-repudiation.) I assume this
is not the intent, which you describe in case (1) above.

[Note: Here is a good reason not use use the word MIC at all when you mean
signature. Signature algorithms sign _data_, so to avoid confusion use
either mic(data) or signature(data), but not signature(mic).]

If you were to use (1) above, i.e. signing part of the original message
vs signing the receipt, then you should change the name to indicate that
the extension is a signature, e.g.

   - extension field = "X-"  "Received-Data-Signature"  ":"  signature
or
   - extension field = "X-"  "Signed-Data-Signature"  ":"  signature

You probably need to use a PEM/MOSS style signature representation, which
is much more complex than a MIC or MD5. You would need to clearly define
how PGP would be used as well.

It is also important to use a term that denotes that the signature is not
over the message content, but rather the signature is data extracted from a
portion of the original message. (In this case the data is the same as
what the sender signed.)

-------

There is another problem with the use of the term MIC above. The PEM/MOSS
RFCs use MIC, which is an extensible representation of a MIC which
includes the binary data as well as the identifier of the algorithm. If
the intent is not to allow multiple MIC functions (I advocate a single
function), then the term MD5 should be used, not MIC.

If the intent is to use the MIC embedded within the sender's (PGP or
S/MIME) signature, there may be a problem defining that. The MIC used
depends on the coded contents of the algorithm specific binary signature
data. Programs like PGP don't output the internal MIC, so custom software
is needed. The internal MIC value is not useful as an integrity check,
since the algorithm isn't included. I think it is simpler to just use a
fixed MIC algorithm, e.g. MD5 which is used in several other RFCs.

In other words, use
   - extension field = "X-"  "Received-MD5"  ":"  MD5_value
or use a more descriptive name, one of:
   - extension field = "X-"  "Received-Content-MD5"  ":"  MD5_value
   - extension field = "X-"  "Signed-Data-MD5"  ":"  MD5_value

(I think the last option is counterproductive, since it is a MIC on
a portion of the message rather than the complete message content.)
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086