Re: OpenPGP Minutes / Quick Summary

[Thomas Roessler <[e-mail]>]

On 2006-08-21 13:39:37 -0400, Derek Atkins <[e-mail]> wrote:

> How about emailing the draft to this list without submitting it
> to the I-D editor?  

I always thought that sending I-Ds to lists (as opposed to
submitting them) was considered bad form -- but here we go, sans
boiler-plate material.

-- 
Thomas Roessler   <[e-mail]>





1.  Introduction

   Various digital signature services for electronic mail rely on the
   framework defined in RFC 1847.  These signature services do not
   address the issue of parallel signatures on the same content.

   Instead of specifying parallel signature formats for individual
   signature services such as OpenPGP, the present document defines a
   "multipart/mixed" protocol for the "multipart/signed" body type
   introduced in RFC 1847.  The "multipart/mixed" protocol permits users
   to bundle parallel signatures for the same content into one
   "multipart/signed" body part.  It is independent of the protocols
   used to form the individual digital signatures.

1.1.  Compliance

   In order for an implementation to be compliant with this
   specification, is it absolutely necessary for it to obey all items
   labeled as MUST or REQUIRED.

2.  The "multipart/mixed" protocol

2.1.  Specification

   Digitally signed messages conforming to this document are denoted by
   the "multipart/signed" content type, defined in RFC 1847, with a
   "protocol" parameter which MUST have a value of "multipart/mixed".
   (MUST be quoted).

   The "micalg" parameter MUST contain a comma-separated list of hash-
   symbols.  These hash-symbols identify the message integrity check
   (MIC) algorithm(s) used to generate the subsequent signature(s).
   Hash-symbols MUST NOT occur more than once in this list.

   The multipart/signed body MUST consist of exactly two parts.  The
   first part contains the signed data in MIME canonical format,
   including a set of appropriate content headers describing the data.

   The second part MUST be of type "multipart/mixed".  Each sub-part
   represents an individual digital signature which has been formed
   according to RFC 1847 and the specification of the signature protocol
   used.

2.2.  Example message

     From: Dave Del Torto <[e-mail]>
     To: Raph Levien <[e-mail]>
     Mime-Version: 1.0
     Content-Type: multipart/signed; protocol="multipart/mixed";
        boundary=0000_031; micalg="pgp-sha1, rsa-md5, pgp-md5"

     --0000_031
     Content-Type: text/plain

     Hi Raph,

     Here's some text with parallel (multiple) digital signatures
     in various formats.

        dave

     ______________________________________________________________________
     "All email luxuriantly hand-crafted using only the finest ASCII text."

     --0000_031
     Content-Type: multipart/mixed; boundary=0000_032

     --0000_032
     Content-Type: application/pgp-signature

     -----BEGIN PGP SIGNATURE-----
     Version: PGP for Personal Privacy 5.0
     Comment: Hash computed using SHA-1 micalg (FIPS 180-1).

     iQCVAwUBM0It9qHBOF9KrwDlAQFBaQQAisIzQUgyknT2v729b7MImcUc3ROdRBh6
     nwMyAfdewQYCDxqdDWvnD1UWoUjwjA1JNA6qhTXBxs8yPtZdDZaguOG2zWawyat9
     Jib556AuSx10psREDC3vNsaJ99MV8SKFF92H53l9w/YhVOA0aMZeNfLE0jJVypkY
     /so4/7DHhqQ=
     =/wlj
     -----END PGP SIGNATURE-----

     --0000_032
     Content-Type: application/x-pkcs7-signature
     Content-Transfer-Encoding: base64
     Comment: Hash computed using S/MIME MD5 micalg.

     MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEH


     [signature material removed]


     +kNIWIbxNiNje1wlzIhaGjrGrOnvYc8+tFn2LgAAAAAAAAAA

     --0000_032
     Content-Type: application/pgp-signature

     -----BEGIN PGP SIGNATURE-----
     Version: PGP 2.6.2
     Comment: Hash computed using MD5 micalg.

     iQCVAwUBM0Iu16HBOF9KrwDlAQGaiQP9EU1YXgMSoNxDAqSmo7UoCE52DuYCfxm7
     x8RfRr9+Xz3nPFytSYM2TIWGMeKi1fVr5PhfjdrKvOh9sCq97h6zndZVpGA9x62k
     mPVn/QY3fz1eOdyJbYvW4ba7WQll5OoA6cqmEb9tWwh4ra4yE8hZMnLS9a0uPpuB
     5dpiTTAE/gY=
     =hD3D
     -----END PGP SIGNATURE-----

     --0000_032--

     --0000_031--

3.  Security Considerations

   Use of this protocol has the same security considerations as RFC 1847
   and the individual digital signature protocols used. It is not known
   to either increase or decrease the security of messages using it.

   Users should be aware of the fact that each individual signature can
   be broken out and used to create a valid "multipart/signed" body
   according to the underlying protocol and RFC 1847.

4.  Acknowledgements

   We thank Jim Galvin, Sandy Murphy, Steve Crocker, and Ned Freed for
   their pioneering work on security using MIME multiparts, on which the
   refinement specified in this document is based.

   This draft document relies on the work of the IETF's OpenPGP Working
   Group.