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

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Carl Hage wrote:
> 
> Here are some comments on the new draft:
> 
> [I disagree with the calculation of signatures (MIC) in a receipt. I think
> this improper, and is an inappropriate nesting/combination of MIME
> wrappers.  The MIC calculation should be at the same level as the
> receipt-- not nested within MIME wrappers. The receipt process fails or
> changes when corresponding MIME contents are not present. Thus is a MUST
> CHANGE in my opinion.  See below.]
> 
> [There are some major errors with the S/MIME examples (doesn't conform
> to the S/MIME spec).]
> 
> 
Great comments. Yes the S/MIME portion needs re-working. This will be
completed some time this week. I will probably need to send multiple
messages to cover everything you have written. First off however, 
I'd like to discuss your proposal for MIC calculation over essentially
the outer MIME content, or message content, and to send back a signed
receipt calculated over this message content as well.

I don't disagree with this proposal, what I am not sure of is how 
straight forward the implementation would be using S/MIME. With
ContentType=SignedData, if the MIC is calculated over an inner
ContentInfo of type Data, with the data being the RFC 1767 EDI
Interchange, the implementation is fairly straight forward.

If you calculated the MIC over the 'message content' of a SignedData
ContentType then you would need to use the authenticatedAttributes
of SignerInfo, and essentially sign the DigestAlgorithmIdentifiers,
Version, and I assume the SignedData ContentType and all of the 
SignerInfo information as well.

I think this is overly complicated. Is there be a similar process
involved in using PGP/MIME?
    

 
>      2.3.2 Flexibility assumptions
>         -Use of receipt or not (signature required for "Signed Receipt")
> 
> I suggest adding:
> 
> A signed receipt may be returned for messages containing EDI data even
> though the original message does not include a receipt request.
> 
> [Some mailers munge the message headers, and might lose a receipt
> request. Thus a receipt would always be returned for TP-TP messages
> other than a receipt message. A receipt would not normally be used for
> 1-many message broadcasts, e.g. an RFQ.]
> ---

I think this action is up to the implementation, and this RFC does
not preclude this to be a configurable parameter.

> 
>      3.5.1 S/MIME
> 
> This is incorrect S/MIME:
>     PKCS #7 has a provision for "detached data", where, for example, the
>     SignedData in the ContentInfo contains only the signature information,
>     but not the actual data which is signed (which is transferred
>     separately). Application/x-pkcs7-mime explicitly disallows the use of
>     detached data and requires the data to be present within the
>     ContentInfo.  The "detached data" provision is, however, used by the
>     multipart/signed construct described in Section 6.
> 
> You are incorrectly mixing the two ways of transmitting signed data.  The
> first way, using Application/x-pkcs7-mime with ContentType = SignedData
> should be explicitly prohibited for use in EDI case 3.5.1 (as well as
> everything else in my opinion), since the MIME-EDI contents are binary
> encoded and cannot be read by non S/MIME systems. The RFC1847
> multipart/signed should be the only method allowed.
> 
> The correct syntax is to remove the outer layer application/x-pkcs7-mime
> wrapper from 3.5.1 S/MIME, so the RFC822 headers contain the
> Content-Type: multipart/signed header. (The Version header is wrong too.)

Carl are you suggesting we don't support the S/MIME SignedData
ContentInfo type? If we remove application/x-pkcs7-mime and 
replace the outer layer to multipart/signed, then we don't really
have S/MIME do we?
> 
> 
> ---
> 4. Receipts
> 
> Should the signature format (PGP or S/MIME) of the receipt be required to
> be the same as the original message, except by prior agreement?
>

Yes this is implicit and will be made more explicit in the document.
 
> ---
> 4.1   Introduction
> 
>      3). The sender's public key is then used to decrypt the received
>          message integrity check  (MIC or Message Digest) calculated by
>          the sender using a one-way hash function, and digitally signed
>          by the sender. The decryption of the MIC authenticates the
>          sender of the EDI Interchange to the receiving trading partner.
>                 ....
> 
> The wording of these paragraphs is obtuse, and may be confusing to
> many readers. I suggest rewording 3-5, e.g.
> 
>      3). The receiving trading partner authenticates signatures in a
>          message using the sender's public key. The authentication
>          algorithm performs the following:
>             a) The message integrity check  (MIC or Message Digest)
>                contained within the signature is decrypted using the
>                sender's public key for signatures.
>             b) A MIC on the signed contents (the MIME header and encoded
>                EDI object, as per RFC1767) in the message received is
>                calculated using  the same one-way hash function that the
>                sending trading partner used.
>             c) The MIC extracted from the signature is compared with the
>                MIC calculated from the message received.
> 
> ---

I'll change the wording to make it clearer.


> I disagree with the following:
>      6). The receiving trading partner then digitally signs the MIC that
>          was calculated on the received EDI Interchange and the RFC 1767
>          MIME content header information.
> 
> This is innappropriate nesting of MIME. The receipt is for a message,
> and the MIC should be the _message_ contents, not some decoded portion
> of the message, dependent on MIME headers. The signed MDNs should apply
> to *any* RFC822 message containing a "Disposition-notification-to"
> header, not just this MIME-EDI protocol.
> 

See the discussion above. Calculating the MIC on the inner message
contents does not make the MIC depenednt on MIME headers. I'm not
sure I understand what you mean here.
 
> 
> ---
>    - disposition-field - for EDI use:
>        * autoprocessed - when the received content(s) are
>          successfully processed
> 
> I suggest adding:
>        * autoprocessed_failed - when the received content(s) have been
>          processed but an error occurred
> 
> also:
>        * autoprocessed_warning - when the received content(s) have been
>          processed successfully, but problems were detected which
>          may require attention
> 
> In the case of errors or warnings, the first part of the report should
> contain an explaination.
> 
> ---

Do you think the error status' should be more specific than what you
are suggesting. I was thinking of making them more specific as to 
what the failure was.

> 
>      4.4.1  Large File Processing
> 
>      It is also recommended that very large EDI files not be sent via
>      SMTP and a file transfer protocol be used instead.
> 
> This paragraph should be deleted. There is no file transfer protocol
> defined for EDI.  *IF* you want to support such an alternative, then use
> an RFC2017 external URL.

OK I can delete this sentence.

> 
> 
> As specified by RFC 1892. Returning the original message is not
> necessary. This is an optional body part.

Yes the third body part of the mdn for EDI is optional, and it is
generally recommended that it not be sent.

> 
>
> I suggest adding another section (4.5?) describing the other function
> of receipts, namely delivery assurance. Besides the functions described
> in section 4.1, the sender should use a lack of receipt to detect lost
> messages. Following the successfull message transmission via SMTP or
> other protocol, if a receipt has not arrived within some period, the
> message may be resent. Typically, the timeout period would vary widely
> for different trading partners, depending on the type of network connection
> and hours of operation.
> 
> In the case of a retransmitted message, the same RFC822 Message-ID: header
> should be used. Messages with duplicate Message-ID values can be ignored.
> However, a duplicate message arriving long after a receipt has been
> transmitted probably indicates that the receipt has been lost, and the
> receipt should be resent with the same Message-ID as the original receipt.
> 
> Repeated failure to receive a receipt or repeated duplicate Message-IDs
> should be handled with manual intervention.
> 
> Other than retransmission of a possibly lost message, all Message-ID
> values should be unique. The contents of a retransmitted message with
> the same Message-ID shouldbe unaltered.

This was originally planned for the AS#1, but we deferred it to a later
effort.
>