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

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Carl Hage wrote:
> 
> 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?
> 
>

Carl this is it in simpler terms. You have convinced me to go with
the second method. Again I would like other list members to weigh
in with their opinion. If we don't get a lot of discussion I
will change the specification to incorporate the MDN (multipart/report)
in a multipart/signed, and have the mdn signed.

 
> 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 you should sign the calculated MIC with the receiver's
private key -see above. This is the signature on the received MIC. But
you are correct, we can make the draft clearer, so folks know that the
MIC calculated over the RFC1767 and EDI Interchange needs to be
signed, and in the example it is clearly named a signature.
  
> 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