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

[carl@xxxxxxxxx (Carl Hage)]

[See comment *** for some new thoughts on Delivery Service Notifications,
if you don't want to read all of this.]

>From chucks@actracorp.com  Tue Oct 29 15:40:40 1996
>Carl Hage wrote:
>> Here are some comments on the new draft:
>> ...
>> [I disagree with the calculation of signatures (MIC) in a receipt...]

>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.

The point I was trying to get at with the "layering" is that the
MIC returned in a receipt should not be dependent on the type of
the contents. The fact that the contents is S/MIME, PGP, EDI, or
anything else should be irrelevant, and independent of the receipt
generation. Likewise, third party notaries and/or forwarders (e.g.
the US Postal Services vaporware) should have a matching architecture.

> 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.

Not necessarily, since the top level receipt processing becomes
dependent on subsequent decoding of the message contents, and then
only works if there is a single content that can be readily identified.

>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.

No, the one way hash should be computed on the undecoded message contents
immediately following the RFC822 message headers, i.e. the base64 decoded
binary data, the quoted-printable text after the =XX "quotes" are removed,
or the plain text message following the blank line after the headers.
Lines following a terminating --separator-- are not included. This is the
MIME "Content".  The Content-MD5 is such a MIC, but RFC1864 is flawed
because it doesn't define the semantics for multipart or
non-content-encoded "contents".

Computing the receipt hash doesn't use any S/MIME or PGP attributes, it
would be a MD5, SHA, or some other one way hash.

The way this would work from a programming point of view is that the top
level UA would parse the RFC822 message headers, find the receipt request,
find the MIME headers, and the pass the MIME contents off for processing,
dependent on the MIME types and filters, etc. A return status from the
processing application would be used as a status in a receipt which is
then generated. The MD5/SHA is computed as the contents are passed to the
processing application. This works for any MIME type, including plain
text messages for display, and works even if no automated processing is
performed.

Actually, I think fixing the MIC algorithm say at MD5 would be more
useful than allowing multiple algorithms. Then, Content-MD5 is already
available.

>> 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.

I suggested adding the sentence, since it isn't clear and some people may
think that the RFC _does_ preclude such a case. The danger is software
developers who might think this and build a product that will fail.
Perhaps you can think of other wording to make it clear that the RFC
does not preclude this to be a configurable parameter.

>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?

I'm suggesting using the same double MIME wrap for signed, then encrypted
data, i.e. the same way PGP/MIME is used. This means the RFC822 MIME type
will be application/x-pkcs7-mime, ContentInfo=EnvelopedData if encrypted,
or multipart/signed if not encrypted. The ContentInfo=SignedAndEnvelopedData
would not be used and application/x-pkcs7-mime, ContentInfo=SignedData
would not occur in the RFC822 headers.

For all S/MIME signed data, the contents are always combined in a
multipart/signed MIME wrapper, where the second part is the
application/x-pkcs7-mime, ContentInfo=SignedData containing PKCS7 detached
data form of signature.

What I mean by exclusion in S/MIME is the SignedAndEnvelopedData as well as
non-detached form of signed data. (Non-detached, means the signed contents
are embedded inside the PKCS7 binary data rather than wrapped in a MIME
multipart.)

The reason for excluding SignedAndEnvelopedData, is so the message can
be decrypted, and then stored with a signature, and to simplify the processing
so only 1 of the 2 ways of wrapping are used. Maybe the restriction is
unreasonable, and all possible forms are supported with "caveat emptor".

>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.

This only works after decoding, and only works for one and only one
decoded content. It's better to use undecoded, complete content for
all possible cases as the source of the MIC.

>>    - 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.

[*** new related topic]
BTW, this brings to mind that there should be a deferred condition
explicitly defined. A message might be received, but the EDI processing
system is down, and the message cannot be processed. I would suggest
mentioning the use of a RFC1894 DSN in the Internet-EDI RFC, as the
appropriate means to handle deferred delivery from mail forwarders
(e.g. a VAN).

A signed DSN which also includes a content MIC would be an appropriate
"receipt" from a third party notary forwarder. I think it would be useful
to mention this case in the EDI RFC. It's similar to the MDN, but a
DSN type is used as the report MIME type rather than MDN.

What happens if the message is received and authenticated, but the
EDI processing system is down? Should an MDN or DSN be used? Should
the MDN be deferred until the EDI system is operational? Perhaps
an autoprocessed_deferred status would be helpful, to indicate that
the message was received as is scheduled for processing at a later
time. A IRS tax filing, for example might work this way as SOP.
[/***]

The receipt MDN should be independent of the application, so should not
contain application specific error codes. However, there is a distinction
between success/fail/warn, in that errors indicate a need for manual
intervention, and warning might need manual intervention unless explicitly
noted to be ignored.

For multipart messages (not covered by AS#1), there might be a use for
autoprocessed_partial_failed, indicating some parts failed, but some
processed successfully.

A textual error message (reason) header could be useful in an MDN. For
EDI use, certain conditions could have predefined values, which makes the
MDN independent of an application, yet can still carry a human/machine
readable application specific status.

The textual portion of the MDN should have full details on the errors.
The failure/warn would indicate to the originator's mailer than the
receipt should be viewed, rather than simply logged without notification.

Can you or others think of a list of error status conditions? This
list should probably be proposed in a separate email comment.

If an error occurs, should there be some mention of 997, etc.?

>> 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.

Returning the headers can be very helpful, particularly for tracking
delivery status, and in diagnosing problems. I think that the EDI RFC
should recommend that a third part be present with the received headers
included. As mentioned, this information is not included in the MIC
of the receipt.

>> I suggest adding another section (4.5?) describing the other function
>> of receipts, namely delivery assurance. ...
>
>This was originally planned for the AS#1, but we deferred it to a later
>effort.

You could at least include a few sentences to mention the fact that receipts
are used for delivery assurance and lack of a receipt can trigger automated
retransmission, without having to define the details. Or you could include
the paragraphs I just wrote with some editing. The only really important
thing to define is the significance of the uniqueness of Message-IDs.

If this is not defined, then incompatibilities could result where one
mailer retransmits with a new message-ID and another processes the
duplicate as a new message.  Of course, lost receipts would occur rarely
and hence the problem not detected.
--------------------------------------------------------------------------
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