Subject: RE: other comments on AS2 draft

From: "Alberti Antoine" <[email-masked]>
Date: Fri, 23 Jan 2004 10:56:22 +0100

I think section '4.2 Structure of an Internet EDI MIME message' could be enhanced with a little bit of text. Considering S/MIME, it is not obvious that a signature is done using a mutipart/signed with a sign-only part (which is a secondary choice in this RFC). Neither is it obvious whether it is encapsulated in an EnvelopedData to be enciphered or encapsulates an EnvelopedData that is then signed.
What if a product uses a usual S/MIME v3 encapsulation, that is MIME(EnvelopedData(MIME(SignedData(MIME(CompressedData(MIME)))))), and adds the AS.2 fields if the outermost MIME header?
This would remove any ambiguity at very low cost, so it seems interesting.
Regards.

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Kyle Meadors
> Envoyé : jeudi 22 janvier 2004 22:57
> À : [email-masked]
> Objet : other comments on AS2 draft
> 
> 
> 
> Do we have any additional comments on the draft?
> 
> Kyle Meadors
> Drummond Group Inc.
>

---

From: "Kyle Meadors" <[email-masked]>
Date: Fri, 23 Jan 2004 05:35:34 -0600

Alberti,

Exactly what comments do you feel should be added? Something like this: 

A signed payload is contained within two parts of multipart structure. The
first part is the document itself and the second part the pkcs-7 signature.
Encryption, when present, always occurs after applying the signature.

The hierarchy structure is 4.2 is similar to that found in the AS1 RFC 3335,
which this draft is based off. In fact section 4.0 is nearly identical to
4.0 in RFC 3335.

Kyle Meadors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alberti Antoine
Sent: Friday, January 23, 2004 3:56 AM
To: Kyle Meadors
Cc: [email-masked]
Subject: RE: other comments on AS2 draft

I think section '4.2 Structure of an Internet EDI MIME message' could be
enhanced with a little bit of text. Considering S/MIME, it is not obvious
that a signature is done using a mutipart/signed with a sign-only part
(which is a secondary choice in this RFC). Neither is it obvious whether it
is encapsulated in an EnvelopedData to be enciphered or encapsulates an
EnvelopedData that is then signed.
What if a product uses a usual S/MIME v3 encapsulation, that is
MIME(EnvelopedData(MIME(SignedData(MIME(CompressedData(MIME)))))), and adds
the AS.2 fields if the outermost MIME header?
This would remove any ambiguity at very low cost, so it seems interesting.
Regards.

> Do we have any additional comments on the draft?

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 1/19/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 1/19/2004