Subject: Re: OpenPGP Minutes / Quick Summary

From: Thomas Roessler <[email-masked]>
Date: Sat, 5 Aug 2006 23:39:31 +0200

On 2006-07-12 18:16:45 -0400, Derek Atkins wrote:

> Thomas Roessler gave a history of the Multiple Signature
> Draft.  It's an extension to RFC1847 to allow the
> "signature" portion of the message to be a "multipart/mixed"
> and have a set of signatures on the signed data instead of
> just a single signature.  This signature set could be a
> combination of OpenPGP and e.g. S/MIME signatures.

As a status update, I've dug out the (quite short) draft from
that old backup; before re-submitting it, I'm waiting for my
co-authors from back then to give me new contact information
and to ok submitting with the new IETF IPR boilerplate.

Regards,
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 21 Aug 2006 19:14:52 +0200

From the minutes of the OpenPGP meeting in Montreal:

>> Thomas Roessler gave a history of the Multiple Signature Draft.
>> It's an extension to RFC1847 to allow the "signature" portion
>> of the message to be a "multipart/mixed" and have a set of
>> signatures on the signed data instead of just a single
>> signature.  This signature set could be a combination of
>> OpenPGP and e.g. S/MIME signatures.

On 2006-08-05 23:39:31 +0200, I wrote:

> co-authors from back then to give me new contact information and
> to ok submitting with the new IETF IPR boilerplate.

I haven't heard back from either Derek (whose contact information
I'd need), nor my co-authors from back then.

I'm tempted to consider my action item from Montreal done without
resurrecting this draft, and to suggest dropping this from the
charter -- unless there's a sudden surge of interest.

Regards,
-- 
Thomas Roessler   <[email-masked]>

---

From: "Derek Atkins <[email-masked]>" <[email-masked]>
Date: Mon, 21 Aug 2006 13:39:37 -0400

How about emailing the draft to this list without submitting it
to the I-D editor?  Let people read it on the list and we'll see
if there is interest in resurrecting it.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 21 Aug 2006 19:42:56 +0200

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

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

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 <[email-masked]>
     To: Raph Levien <[email-masked]>
     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.

---

From: Jon Callas <[email-masked]>
Date: Mon, 21 Aug 2006 11:37:52 -0700

> submitting them) was considered bad form -- but here we go, sans

It's not bad form when the working group chair suggests it.

Also, one of the main reasons people don't like them sent to the list  
is that they tend to be large. Yours is delightfully small.

Thanks, it's good to see this again.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Mon, 21 Aug 2006 20:59:43 +0200

On Mon, 21 Aug 2006 19:42, Thomas Roessler said:

Assuming that parallel signatures are used to give extra security in
case one of the protocols or algorithms has been broken, this indeed a
problem.  

A solution is easy: The protocols and algorithms used to make up the
signatures need to be hashed with the content.  For example by an
extra header line in the first part.  When verifying the signatures an
application can easily detect whether a signature has been removed and
present an appropriate warning (also considering the algorithms deemed
to be broken at the time of verification).

Obviously this requires that either all signatures are created at the
same time or forehand knowledge of the signatures to be added later is
required.

Shalom-Salam,

   Werner