Re: OpenPGP Minutes / Quick Summary

Thomas Roessler <> Mon, 21 August 2006 18:16 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GFEKH-0001B4-1u for; Mon, 21 Aug 2006 14:16:41 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GFEKD-000305-GT for; Mon, 21 Aug 2006 14:16:41 -0400
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k7LHh2tF061054; Mon, 21 Aug 2006 10:43:02 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k7LHh2mH061053; Mon, 21 Aug 2006 10:43:02 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id k7LHh0Id061029 for <>; Mon, 21 Aug 2006 10:43:00 -0700 (MST) (envelope-from
Received: from ( []) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by (Postfix) with ESMTP id 611F81936FA; Mon, 21 Aug 2006 19:42:59 +0200 (CEST)
Received: from roessler by with local (Exim 4.62) (envelope-from <>) id 1GFDnc-0007TP-Ph; Mon, 21 Aug 2006 19:42:56 +0200
Date: Mon, 21 Aug 2006 19:42:56 +0200
From: Thomas Roessler <>
Subject: Re: OpenPGP Minutes / Quick Summary
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.13 (2006-08-16)
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f

On 2006-08-21 13:39:37 -0400, Derek Atkins <> 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   <>

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

2.2.  Example message

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

     Content-Type: text/plain

     Hi Raph,

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


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

     Content-Type: multipart/mixed; boundary=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).

     -----END PGP SIGNATURE-----

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


     [signature material removed]


     Content-Type: application/pgp-signature

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

     -----END PGP SIGNATURE-----



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