Subject: "Signed, then Encrypted" on Sending but only "Signed" on MDN

From: "J. David MacDonald" <[email-masked]>
Date: Sun, 12 Dec 1999 12:36:50 -0500

draft-ietf-ediint-req-08.txt

I need some clarification on one or two points of the EDI-INT specification.
As per 3.8.3. below, the specification seems to be to suggest "signed, then
encrypted". when sending
As per 4.7.2  below, the specification seems to suggest "sign the MDN"

I'm confused about the phrase in 3.8.3: The signatories in an S/MIME "signed
   and enveloped" content type can be distinguished, which in certain
   EDI and electronic commerce situations is not acceptable.

Isn't that also true of the Signed MDN?

Can anyone comment on exactly what the exposure is if the signatory info is
not obscured.
Can anyone comment on why there is no "Signed, then Encrypted" option for
the MDN, since as per 4.7.2 the signatory information is not obscured on the
signed MDN.

<snip>
3.8.3 Issues

   The S/MIME specification allows "signed and enveloped" and
   "signed" to be distinguished. The signatories in an S/MIME "signed
   and enveloped" content type can be distinguished, which in certain
   EDI and electronic commerce situations is not acceptable. However,
   the S/MIME v3 Message Specification [8], does address this
   concern by specifying that "signed and enveloped" not be used, and
   a two step sign and then encrypt process be used instead.
<snip>

<snip>
4.7.2  Recommendations

   1). The sender should specify that a receipt or signed receipt be
       returned in response to the sent message. The way to request
       that a receipt or message disposition notification be returned
       by the recipient is specified in RFC 2298 [5]. The way to
       request that a signed receipt be returned by the recipient is
       specified in draft-ietf-ediint-as1-10.txt [10].
<snip>

Regards,
Dave MacDonald

---

From: "Carl Hage" <[email-masked]>
Date: Mon, 13 Dec 1999 12:21:42 -0800

From:           	"J. David MacDonald" <[email-masked]>
Date sent:      	Sun, 12 Dec 1999 12:36:50 -0500

> I need some clarification on one or two points of the EDI-INT
> specification. As per 3.8.3. below, the specification seems to be to
> suggest "signed, then encrypted". when sending As per 4.7.2  below, the
> specification seems to suggest "sign the MDN"

When using encryption, normally the message containing the EDI data 
would be encrypted but the MDN would not. This allows an email 
processing software layer to function outside (independent of) the EDI 
inner layers, providing assured delivery.

Exposure of the MDN facilitates proper tracking of a message delivery 
across the less-secure set of message gateways.

>    and enveloped" content type can be distinguished, which in certain EDI
>    and electronic commerce situations is not acceptable.

There are 2 ways of implementing S/MIME (PKCS) signatures-- one 
where signed data is imbedded within the binary signature (enveloped) 
and one where the signed data is external to the signature data. The 
second method is required, otherwise the content is obscured.

> Can anyone comment on exactly what the exposure is if the signatory info
> is not obscured. Can anyone comment on why there is no "Signed, then
> Encrypted" option for the MDN, since as per 4.7.2 the signatory
> information is not obscured on the signed MDN.

The ID of the signer of the MDN is exposed, and the disposition status 
is exposed. This is about the same as a package delivery, where the 
content of a package is hidden, but the signer of a receipt is visible to 
the truck driver, etc. One difference is that the receipt contains a MIC 
code, that allows the content of the package to be uniquely identified 
without revealing the content.

There's no rule that says the signer-ID of the MDN must be the same 
as the signer-ID of a transaction, but I can't think of a realistic reason 
to do so.

---

If you really need to keep the FBI wiretaps of your DSL line from 
detecting transactions from certain Columbian agri-businesses, your 
best bet is to use EDIINT to a VAN, who can forward the message 
secretly. Otherwise the To: From: headers expose about as much 
information as in an MDN.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086