MIME Security with PGP (RFC2015)

MIME Security with PGP (RFC2015)

[Shenghuo ZHU]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

I wrote rfc2015.el, which is supposed to fill the gap between Gnus 5.8
and mailcrypt.  Because it is not finished, I just put it in contrib
directory.

To initialize it, say
 (require 'rfc2015)
 (rfc2015-setup)

Of course, you should also initialize mailcrypt.

To sign something, say

<#part type="text/plain" disposition=inline postprocess=pgp-sign>
The text to sign.
<#/part>

To encrypt something, say

<#part type="image/jpeg" filename="to-encrypt.jpg" postprocess=pgp-encrypt>
<#/part>

TODO:
1. Verify message.
2. Automatically snarf the recipient's email address when encrypting.

Shenghuo

PS: This message is signed.  My public key is at
http://www.cs.rochester.edu/u/zsh/zsh.asc.  Unfortunately, it can not
be verified in Gnus right now. :-(

[-- Attachment #2: Type: application/pgp-signature, Size: 272 bytes --]

Re: MIME Security with PGP (RFC2015)

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> I wrote rfc2015.el, which is supposed to fill the gap between Gnus 5.8
> and mailcrypt.  Because it is not finished, I just put it in contrib
> directory.

A few months ago, Lars suggested to keep MIME-PGP support separate
because of crypto export regulation issues.

> To sign something, say
> 
> <#part type="text/plain" disposition=inline postprocess=pgp-sign>
> The text to sign.
> <#/part>

My package uses a somewhat different approach:

<#multipart type=signed>
This is a signed multipart.
<#part type="text/plain" filename="~/some-file" disposition=attachment description="signed attachment">
<#/multipart>

This is achieved by hooking into "mml-generate-multipart-alist".
To be honest, I think "mml-generate-mime-preprocess-function" and
"mml-generate-mime-postprocess-function" are unnecessary.  At least
you can't use them to generate RFC 2015 messages.  There are special
requirements regarding quoted-printable encoding of parts inside
"multipart/signed" or "multipart/encrypted", and I don't think you can
set the appropriate variable ("mm-use-ultra-safe-encoding") during
MML-to-MIME translation using your hooks.

My code is available at:

        http://cert.uni-stuttgart.de/people/fw/gpg-mime.el

At the moment, it's very alpha, and it's likely that it doesn't
work. :-/ Of course, it only does the easy part, i.e. creating
"multipart/signed" and "multipart/encrypted", not the other way round.

It requires some packages found in the same directory.  At the moment,
it is GnuPG-specific, but you should be able to use other (Open)PGP
implementations if you customize the settings in gpg.el.  Mailcrypt
wasn't used because of some security problems and the unwillingness
of the maintainer to respond to suggestions regarding detached
signatures.

Now to the hard part, signature verification and decryption.  For
verification, I think we need a hook into "mm-dissect-multipart",
which verifies the signature (at this place, all the necessary
information is still present) and generates a suitable MML handle.
After that, the part can be displayed using a user-defined display
function (by specifying it in "gnus-mime-multipart-functions").

Decryption should only occur if explicitly requested by the user.  No
hook into "mm-dissect-multipart" is required for it; we can decrypt
and call "mm-dissect-buffer" on the plaintext on user request.

(Maybe we should continue this discussion on the gnus-rfc2015 list?
I've subscribed you.)

[-- Attachment #2: Type: application/pgp-signature, Size: 524 bytes --]

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> I wrote rfc2015.el, which is supposed to fill the gap between Gnus 5.8
> and mailcrypt.  Because it is not finished, I just put it in contrib
> directory.

Are there fundamental technical problems to why it isn't finished?

I've successfully sent S/MIME signed mail with Gnus (and several
manual steps) using postprocess=smime-sign.

Before actually implementing this, it would be nice to hear what the
reasons was for not finishing PGP/MIME.

Hm. For fun I tried to S/MIME sign this mail.  I don't really expect
it to interoperate with MS Outlook/Netscape at the first try, but
you'd never know...

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1794 bytes --]

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

Simon Josefsson <simon@josefsson.org> writes:

> Hm. For fun I tried to S/MIME sign this mail.  I don't really expect
> it to interoperate with MS Outlook/Netscape at the first try, but
> you'd never know...

FWIW, it did.  Neither Outlook nor Messenger exploded, they even
though the signature was OK.

Re: MIME Security with PGP (RFC2015)

[Shenghuo ZHU]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Simon Josefsson <simon@josefsson.org> writes:

> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > I wrote rfc2015.el, which is supposed to fill the gap between Gnus 5.8
> > and mailcrypt.  Because it is not finished, I just put it in contrib
> > directory.
> 
> Are there fundamental technical problems to why it isn't finished?
> 
> I've successfully sent S/MIME signed mail with Gnus (and several
> manual steps) using postprocess=smime-sign.
> 
> Before actually implementing this, it would be nice to hear what the
> reasons was for not finishing PGP/MIME.

Signing or decrypting work fine. But the technical problems and
non-technical reasons are:

1. Unable to do verifying, because mm-dissect-buffer does not keep the
header info (micalg value and the header of the signed text).

2. Have to input recipient's email address more than once when
encrypting.  It could be solved by adding email address into the tag
somehow.

3. mm-use-ultra-safe-encoding should be set, though gnupgp or
mailcrypt may handle the leading "From".

4. Florian Weimer is also working on a similar project. (see the
attached message I sent to gnus-rfc2015 mailing list).

5. Lars worries about crypto export regulation issues.

6. I am busy recently :-(.

If we implemented both protocols, I think we should rename it to
rfc1847.el instead of rfc2015.el.

Shenghuo


[-- Attachment #2: Type: message/rfc822, Size: 5026 bytes --]

From: Shenghuo ZHU <zsh@cs.rochester.edu>
To: gnus-rfc2015@mercury.rus.uni-stuttgart.de
Subject: Re: MIME Security with PGP (RFC2015)
Date: 02 Jun 2000 02:25:33 -0400
Message-ID: <2nvgzsy4yq.fsf@tiger.jia.vnet>

>>>>> "Florian" == Florian Weimer <fw@deneb.cygnus.argh.org> writes:

Florian> Shenghuo ZHU <zsh@cs.rochester.edu> writes:

>> I wrote rfc2015.el, which is supposed to fill the gap between Gnus
>> 5.8 and mailcrypt.  Because it is not finished, I just put it in
>> contrib directory.

Florian> A few months ago, Lars suggested to keep MIME-PGP support
Florian> separate because of crypto export regulation issues.

I think the implementation of RFC 2015 is not related to crypto export
regulation issues, because we are not implementing PGP itself.  In my
opinion, RFC 2015 is more related to MIME than to the PGP algorithm.
Therefore, it should be integrated with Gnus.  The current
implementations largely depend on mml.el. I worry about the
consistency issue, if the support and Gnus are maintained separately.

Moreover, RFC 1847 provides a general document for security MIME.
Gnus should be extended to support protocols other than PGP, if the
sign, encrypt, verify and decrypt functions are provided.

>> To sign something, say
>> 
>> <!#part type="text/plain" disposition=inline postprocess=pgp-sign>
>> The text to sign.
>> <!#/part>

Florian> My package uses a somewhat different approach:

Florian> <!#multipart type=signed>
Florian> This is a signed multipart.
Florian> <!#part type="text/plain" filename="~/some-file" disposition=attachment description="signed attachment">
Florian> <!#/multipart>

Do we really need so many tags here?

Florian> This is achieved by hooking into
Florian> "mml-generate-multipart-alist".  To be honest, I think
Florian> "mml-generate-mime-preprocess-function" and
Florian> "mml-generate-mime-postprocess-function" are unnecessary.  At
Florian> least you can't use them to generate RFC 2015 messages.
Florian> There are special requirements regarding quoted-printable
Florian> encoding of parts inside "multipart/signed" or
Florian> "multipart/encrypted", and I don't think you can set the
Florian> appropriate variable ("mm-use-ultra-safe-encoding") during
Florian> MML-to-MIME translation using your hooks.

I missed this part, but gpg fixes the leading "From" in non-detached
sign.  Anyway, mm-use-ultra-safe-encoding can be introduced somehow.

Florian> My code is available at:

Florian>         http://cert.uni-stuttgart.de/people/fw/gpg-mime.el

Florian> At the moment, it's very alpha, and it's likely that it
Florian> doesn't work. :-/ Of course, it only does the easy part,
Florian> i.e. creating "multipart/signed" and "multipart/encrypted",
Florian> not the other way round.

Florian> It requires some packages found in the same directory.  At
Florian> the moment, it is GnuPG-specific, but you should be able to
Florian> use other (Open)PGP implementations if you customize the
Florian> settings in gpg.el.  Mailcrypt wasn't used because of some
Florian> security problems and the unwillingness of the maintainer to
Florian> respond to suggestions regarding detached signatures.

I hope the implementation can be easily extended for other RFC1847-
compliant protocols.  Therefore, we should not expect too much from
the backend's support.

Florian> Now to the hard part, signature verification and decryption.
Florian> For verification, I think we need a hook into
Florian> "mm-dissect-multipart", which verifies the signature (at this
Florian> place, all the necessary information is still present) and
Florian> generates a suitable MML handle.  After that, the part can be
Florian> displayed using a user-defined display function (by
Florian> specifying it in "gnus-mime-multipart-functions").

Maybe this is a good idea.

The other way is that we can modify Gnus so that mime handles keep all
the necessary information.  The messages are verified before
displayed.  The user could customize "mm-automatic-display" to verify
messages automatically or explicitly.

Florian> Decryption should only occur if explicitly requested by the
Florian> user.  No hook into "mm-dissect-multipart" is required for
Florian> it; we can decrypt and call "mm-dissect-buffer" on the
Florian> plaintext on user request.

That is exactly what I did in my implementation.

Florian> (Maybe we should continue this discussion on the gnus-rfc2015
Florian> list?  I've subscribed you.)

Thank you.

Shenghuo

Re: MIME Security with PGP (RFC2015)

[Kai Großjohann]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> 5. Lars worries about crypto export regulation issues.

Won't these be moot anyway come September?

kai
-- 
I like BOTH kinds of music.

Re: MIME Security with PGP (RFC2015)

[Bruce Stephens]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > 5. Lars worries about crypto export regulation issues.
> 
> Won't these be moot anyway come September?

Probably not.

Re: MIME Security with PGP (RFC2015)

[Florian Weimer]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> > 5. Lars worries about crypto export regulation issues.
> 
> Won't these be moot anyway come September?

Do you mean the RSA patent issues?  They aren't directly related to
the ITAR regulations, and we certainly do not want to implement RSA in
Lisp. ;)

Re: MIME Security with PGP (RFC2015)

[Kai Großjohann]

Florian Weimer <fw@deneb.enyo.de> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > > 5. Lars worries about crypto export regulation issues.
> > 
> > Won't these be moot anyway come September?
> 
> Do you mean the RSA patent issues?

Oops.  Maybe I got confused, here.  Hm.  Yeah, I guess it's just the
RSA patent, and the crypto export regulations don't change in
September.

Thanks for setting me straight.

kai
-- 
I like BOTH kinds of music.

Re: MIME Security with PGP (RFC2015)

[Florian Weimer]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> 5. Lars worries about crypto export regulation issues.

I think the FSF has investigated the new situation and it's now
possible to export free (in the sense of GPLed) crypto software from
the US with hardly any restrictions.

> 6. I am busy recently :-(.

Me too. :-(

Re: MIME Security with PGP (RFC2015)

[Stainless Steel Rat]

* Florian Weimer <fw@deneb.enyo.de>  on Thu, 29 Jun 2000
| I think the FSF has investigated the new situation and it's now
| possible to export free (in the sense of GPLed) crypto software from
| the US with hardly any restrictions.

Not entirely, but yes, ITAR is effectively dead as far as crypto goes.
-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> If we implemented both protocols, I think we should rename it to
> rfc1847.el instead of rfc2015.el.

Yes.  I'm writing rfc1847.el now, with S/MIME support.
(PGP/MIME should be easy given yours and Florians work.)

I think I'm going to take a different approach than you and Florian.
Instead of adding MML tags that say that a part should be
signed/encrypted when sending it, I'm adding commands for "sign this
MML part" and "encrypt this MML part" that does the signing
immediately.

So if you are editing a MML article like

<$multipart type=mixed>
<$part>
Hi there
<$part>
Hi again
<$/multipart>

and call the "sign part" function on the <$multipart> tag and select
S/MIME signing, you'd end up with

<$multipart type=signed>
<$multipart type=mixed>
<$part>
Hi there
<$part>
Hi again
<$/multipart>
<$part type=application/x-pkcs7-signature buffer=*signature* raw=t>
<$/multipart>

or possibly

<$multipart type=signed>
<$part type=multipart/mixed buffer=*whatever* raw=t>
<$part type=application/x-pkcs7-signature buffer=*signature* raw=t>
<$/multipart>

in the buffer.

I would like this better than encrypt-when-send, with it I would
always have the feeling that I never knew what was sent.

What do you think?

Re: MIME Security with PGP (RFC2015)

[Raja R Harinath]

Simon Josefsson <simon@josefsson.org> writes:
> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > If we implemented both protocols, I think we should rename it to
> > rfc1847.el instead of rfc2015.el.
> 
> Yes.  I'm writing rfc1847.el now, with S/MIME support.
> (PGP/MIME should be easy given yours and Florians work.)
> 
> I think I'm going to take a different approach than you and Florian.
> Instead of adding MML tags that say that a part should be
> signed/encrypted when sending it, I'm adding commands for "sign this
> MML part" and "encrypt this MML part" that does the signing
> immediately.
[snip] 
> I would like this better than encrypt-when-send, with it I would
> always have the feeling that I never knew what was sent.

How do you ensure that if the signature still matches?  I could create
a part, sign it, edit it some more, and forget to request a recompute
the signature.  Will it flag an error when the message is attempted to
be sent?  What does the user have to do to fix the error?

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

Raja R Harinath <harinath@cs.umn.edu> writes:

> How do you ensure that if the signature still matches?  I could create
> a part, sign it, edit it some more, and forget to request a recompute
> the signature.

Yes.  I put a little faith in Gnus users not to do that. :-)

>  Will it flag an error when the message is attempted to be sent?

Ideally Gnus should warn the user if she try to modify signed
contents, and remove the multipart/signed stuff.

Re: MIME Security with PGP (RFC2015)

[Shenghuo ZHU]

Simon Josefsson <simon@josefsson.org> writes:


[...]

> I would like this better than encrypt-when-send, with it I would
> always have the feeling that I never knew what was sent.

You can always know what is going to be sent by mm-preview 
(C-u M-m P).

> What do you think?

There are some technical difficulties in your approach:

1) In your first illustration, the parts have to be encoded more than
once.  Gnus can not guarantee that two encoded results are same,
because mml-computer-boundary may return different results.

2) In your second illustration, some users would rather see the
content of the multipart/mixed part instead of the tags.  Besides, you
may miss micalg and protocol parameters in the multipart/signed head.

Shenghuo

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> > What do you think?
> 
> There are some technical difficulties in your approach:
> 
> 1) In your first illustration, the parts have to be encoded more than
> once.  Gnus can not guarantee that two encoded results are same,
> because mml-computer-boundary may return different results.

Right.  Ouch.

> 2) In your second illustration, some users would rather see the
> content of the multipart/mixed part instead of the tags.  Besides, you
> may miss micalg and protocol parameters in the multipart/signed head.

Yes.  I think I've changed my mind about that approach too, it isn't
very good.

I'll use the `postprocess' framework for now (but I think we should
rename it, `sign=smime' or whatever looks nicer).

Re: MIME Security with PGP (RFC2015)

[Florian Weimer]

Simon Josefsson <simon@josefsson.org> writes:

> I'll use the `postprocess' framework for now (but I think we should
> rename it, `sign=smime' or whatever looks nicer).

Could you consider the old interface for this kind of work (i.e.
"mml-generate-multipart-alist"), too?

Re: MIME Security with PGP (RFC2015)

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

> > I'll use the `postprocess' framework for now (but I think we should
> > rename it, `sign=smime' or whatever looks nicer).
> 
> Could you consider the old interface for this kind of work (i.e.
> "mml-generate-multipart-alist"), too?

Yes, I think that interface is more "proper", even though just adding
"sign=smime" to a part is short and nice (it also happens to be easier
to implement, since OpenSSL generate it's own multipart/signed MIME
part).  Anyway, I guess most people don't write the mml tags manually
anyway.