J. David MacDonald | 12 Dec 18:36 1999
Picon

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

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>
(Continue reading)

J. David MacDonald | 12 Dec 21:19 1999
Picon

Re: LAST CALL for the REQ and the AS1 document.

Rik,

Could you give me the date when AS1 was submitted for RFC status.
Also, how long does it take to go through the process (ie. when do we have
something that says:
Category: Standards Track    on the specification).

Dave MacDonald

----- Original Message -----
From: "Rik Drummond" <drummond <at> onramp.net>
To: <ietf-ediint <at> imc.org>
Sent: Friday, October 15, 1999 12:31 PM
Subject: LAST CALL for the REQ and the AS1 document.

> These two have been untouched for over a year and now have been
implemented
> by over 11 companies. So they must have clarity and readability. Terry
> Harding has updated them to reflect the new version of s/mime coming out
of
> the IETF. I want to get them to RFC status shortly after the IETF meeting
in
> Washington DC. Please read them one more time and make sure we are
> correct..... Thanks Rik
>
>
>
>

(Continue reading)

Carl Hage | 13 Dec 21:21 1999

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

From:           	"J. David MacDonald" <david.macdonald <at> sympatico.ca>
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.

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

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.
(Continue reading)

Rik Drummond | 17 Dec 17:07 1999
Picon

EDIINT AS1 conformance testing

We will start the next round of ediint as1 conformance testing sponsored by commercenet in late january. If you are interested, and this is your first time please contact me in early january for more information.  I expect we will have from 15-20 vendors involved this time.  additionally, i unofficially believe commercenet will sponsor a test on as2 in the april time frame.
 
cylone has volunteered to offer a testing platform for new comers to initially test against... so those who have previously passed the test will not be overly involved until -- my guess in april.
 
have a happy holiday season.... Best regards, rik

Gmane