Vs Combined Method? E+S from RFC 3156 6.2

[Bernhard Reiter]

Hello,
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?
Bernhard

Some public statements of Werner that I did find:
        http://marc.info/?l=gnupg-devel&m=100167296722730&w=2
        List:       gnupg-devel
        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 
other?
        > I.E. Sign & Encrypt over Encrypt & Sign.

        http://marc.info/?l=gnupg-users&m=110572664810100&w=2
        List:       gnupg-users
        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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20080429/89d2294b/attachment.pgp>