Vs Combined Method? E+S from RFC 3156 6.2
bernhard at intevation.de
Tue Apr 29 14:14:45 CEST 2008
in this email I am trying to collect arguments against the
combined method for encryption and signature as outlined in
section 6.2 of RFC 3156.
The other method describe there is
6.1 RFC 1847 Encapsulation
and means doing a signature first and then encrypt the result,
aka the MIME method.
I know that Werner advises against the combined method,
now I am looking for the arguments.
Werner puts forward that it would be possible to strip the encryption layer
with the MIME method.
The RFC suggest that this can be done also with the combined method.
I take it that it is easier to implement with the MIME method
as there is no rewriting involved.
Counting one argument for the MIME method.
The RFC puts forward that the combined method saves computing time
and is more compatible with older implementation.
The computing time is almost neglectable in my view,
but the compatibility is a countable argument for the combined method.
The RFC only states that the MIME method is "most useful for standard MIME-
compliant message forwarding." I take it this hold for all cases where there
is a MIME structure inside the encryption, which means many emails today where
there is an attachment or an multipart/alternative. Otherwise the
compatibility advantages with non-MIME (email) applications would be gone.
It is clear that all implementations have to be able to cope with combined
emails as readers anyway, this also means being able to strip the encryption
layer. Taken you want to implement this stripping functionality you will
have to do it for both methods as users would not really understand why it
does not work in some cases.
Given the enhanced compatibility, why not do combined method whenever you can,
just getting the compatibility advantage? Looks like this is what email
applications should use as default so far.
What arguments am I missing?
Some public statements of Werner that I did find:
Subject: Re: gpgme 0.3.3 questions
From: Werner Koch <wk () gnupg ! org>
Date: 2001-09-28 9:56:14
> - Currently there is no way to perform encrypt+sign operations!!!
> gpgme_signers_add() cannot be used for gpgme_op_encrypt().
I know but this is a minor problem compared to the fact that it is not
possible to decrypt and check the signature. I don't know what
application you have currently in mind, my primary target are MUAs and
tehre is is better not to use the combined method but first sign, pack
this into a MIEM object and the encrypt this MIME object again. The
big advantage is that you can remove the encryption layer and still
keep the signature.
On Fri, Jan 14, 2005 at 03:55:05PM +0000, Shaun Lipscombe wrote:
> Is there any particular reason why one must be done before the
> I.E. Sign & Encrypt over Encrypt & Sign.
Subject: Re: Encrypt & Sign
From: Werner Koch <wk () gnupg ! org>
Date: 2005-01-14 18:11:13
Message-ID: 877jmfvq2m.fsf () wheatstone ! g10code ! de
On Fri, 14 Jan 2005 11:25:59 -0500, David Shaw said:
> signer. There is no particular reason why one is better than the
> other, but generally people like the identity protection aspect of
There is one reason: If you store texts in the clear you still can
keep the signature intact. If you encrypt and sign then this won't be
possible. To implement that you should - for practical reasons - not
use the combined method of gpg but the standard PGP/MIME method of
encrypting an PGP/MIME signed message.
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Gnupg-devel