Subject: Need your feedback re: AS2 using PGP

From: Dick Brooks <[email-masked]>
Date: Tue, 10 Aug 1999 11:01:03 -0500 (CDT)

I've been working on some examples for the AS2 spec, which I hope to have
ready next week. In my attempt to construct a PGP example I came across an
interesting situation. RFC 2015 (PGP/MIME) specifies that PGP encrypted files
should be enveloped in the following way:

	multipart/encrypted boundary=foo; protocol="application/pgp-encrypted"
		application/pgp-encrypted
		   "Version: 1"
		application/octet-stream

		   [encrypted payload]

Note that the actual pgp-encrypted payload is associated with a MIME
type of application/octet-stream and the payload associated with the MIME type 
application/pgp-encrypted contains unencrypted "clear text" "control data" 
ONLY.  This layering is a bit confusing when compared to the way S/MIME 
enveloping works. (NOTE TO AS1 AUTHORS, the layering described in EDIINT AS1 
section 4.2.x for application/pgp-encrypted is inconsistent with RFC 2015.)

For example, the enveloping of an an object using S/MIME Version 2 
(packaged for e-mail transport using the RSA S/MIME-C libraries) appears as:

  Content-Type:application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
  Content-Transfer-Encoding:base64
  Content-Disposition:attachment;filename=smime.p7m

	[encrypted payload]

NOTE: the encrypted payload is associated with the application/pkcs7-mime 
content-type.

For the purposes of AS2, I would like to propose a slight modification to the 
enveloping of PGP encrypted objects by replacing the "Version: 1", as specified by RFC 2015, with the actual encrypted object and removing the enveloping for 
application/octet-stream all together. This enveloping is consistent with the 
way S/MIME currently works.

Here is an example of an AS2 compliant HTTP POST reflecting the proposed 
changes.  This example was created using an off-the-shelf Netscape 
Communicator Browser:

POST /cgi-bin/oracle/dispatch HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.5 [en] (Win95; I)
Host: localhost:2600
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: multipart/form-data; boundary=---------------------------12164286314927
Content-Length: 1033

-----------------------------12164286314927
Content-Disposition: form-data; name="from"

900100001
-----------------------------12164286314927
Content-Disposition: form-data; name="to"

800200002
-----------------------------12164286314927
Content-Disposition: form-data; name="input-format"

x12
-----------------------------12164286314927
Content-Disposition: form-data; name="input-data"; filename="C:\GISBLite\as2testtextfiletxt.asc"
Content-Type: application/pgp-encrypted

-----------------------------12164286314927--

Dick Brooks                            [email-masked]
Tel. 205-250-8053		       Birmingham, Alabama
Group 8760 LLC                         WWW URL:  http://www.8760.com/
SECURE ELECTRONIC COMMERCE SOLUTIONS FOR HEALTHCARE AND NATURAL GAS INDUSTRIES

---

From: "Terry Harding" <[email-masked]>
Date: Tue, 10 Aug 1999 13:20:28 -0700

>  (NOTE TO AS1 AUTHORS, the layering described in EDIINT AS1

Dick, thank you for pointing out this issue. I will have a look at RFC 2015
and adjust AS1 accordingly.

--
Terry Harding
Security Group - Interoperability/Standards Compliance
Cyclone Software

---

From: "Terry Harding" <[email-masked]>
Date: Tue, 10 Aug 1999 22:46:46 -0700

Dick,

Again, thank you for pointing out the layering error in the PGP examples in
sections 4.2.3 and 4.2.4. The original layout and the proposed changes are
outlined below.

> section 4.2.x for application/pgp-encrypted is inconsistent with RFC
2015.)

Current AS1:
 4.2.3 Encryption, no signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version 1"
                  -RFC1767 (application/EDIxxxx) (encrypted)

 4.2.4 Encryption, signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version 1"
                  -RFC1767 (application/EDIxxxx) (encrypted)
                  -RFC2015 (application/pgp-signature) (encrypted)

Proposed Changes:
 4.2.3 Encryption, no signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version: 1"
              -RFC2015 (application/octet-stream)
                  -RFC1767 (application/EDIxxxx) (encrypted)

 4.2.4 Encryption, signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version: 1"
              -RFC2015 (application/octet-stream)
                  -RFC1847 (multipart/signed)(encrypted)
                      -RFC1767 (application/EDIxxxx)(encrypted)
                      -RFC2015 (application/pgp-signature)(encrypted)

>I came across an
> enveloping works.
I agree, compared to S/MIME the layering defined in RFC2015 is confusing.
If we make the proposed change, we would no longer be compliant with
RFC 2015, which would make implementations of EDIINT non-compliant
with any toolkit or third party product which supports RFC 2015.

One of the side benefits of being compliant with the referenced RFCs is
being
able to interop with other products which also support the referenced RFCs.
Example: Using a S/MIME compliant email application to send or receive
signed
or encrypted data from an EDIINT compliant application.

> enveloping of PGP encrypted objects by replacing the "Version: 1", as
specified by RFC 2015, with
> the actual encrypted object and removing the enveloping for

AS2 is not a stand alone specification, but an extension to AS1.  Your
proposed changes
to the packaging format would have to be made in AS1, which would be
reflected in AS2.

It is this authors opinion to remain compliant with all referenced RFCs,
within AS1 and AS2.

Comments are welcome from the members of this list on all issues discussed
in this email
and future emails.