Vs Combined Method? E+S from RFC 3156 6.2

[Bernhard Reiter]

Am Mittwoch, 16. Juli 2008 23:08:41 schrieb Bernhard Reiter:
> I am coming back to the discussion,
> because I do not see the resolution.

Again.
Let me add that having this arguments available
would be more and more important, because in the last month alone I've got 
email claimed to be from the following email application that are using the 
combined method (and text mode), which again I assume Werner dislikes:

1.
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
X-Enigmail-Version: 0.95.7

2.
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux)

3.
User-Agent: Mutt/1.5.18 (2008-05-17)

Werner, what do you think? Even a strong recommendation from your side
that someone could link to might help those implementors.

Bernhard

> According to RFC 3156 6.2 it makes sense to always use the combined
> method for encryption and signature as there is a requirement
> for all compliant application to support this method.
> Still I am looking for arguments why this is not a good idea.
>
> On Monday 19 May 2008 16:55, Marcus Brinkmann wrote:
> > At Thu, 15 May 2008 14:16:09 +0200, Bernhard Reiter wrote:
> > > On Thursday 15 May 2008 13:20, Marcus Brinkmann wrote:
> > > > At Tue, 29 Apr 2008 14:14:45 +0200,
> > > >
> > > > Bernhard Reiter wrote:
> > > > > Given the enhanced compatibility, why not do combined method
> > > > > whenever you can, just getting the compatibility advantage?
> > > >
> > > > Compatibility with what?
> > >
> > > The RFC from August 2001 says "to increase compatibility
> > > with non-MIME implementations of OpenPGP".
> >
> > I was hoping for some specific applications that are in use today.
>
> Even if there is a tiny small number even on older machines,
> this would be no reason to not use the combined method as
> all the other applications also need to support it.
>
> Also this would be an open question what the RFC writers had in mind
> when they made this statement. Is there a good way to find out about this?=
>
> > > Sure, so you are basically saying: The argument from 2001 is obsolete.
> >
> > I am not saying that, I am just suggesting that, after evaluation, it
> > might be such a case, depending on how important compatibility is in
> > the real world.
> >
> > > On the other hand, to ease the implementation, shouldn't we then push
> > > for the removal of the combined method requirement?
> > > At least make it mandadory in new implementation to not create
> > > new combined method emails?
> >
> > I think that, if this is such a case, then that would be a sensible
> > next step.
>
> This makes your argument depend on the outcome of the analysis.
> Given that Werner does not recommend the combined method,
> he must have a view on the result already.
>
> > > > So, the question is, are there significant MUAs that support only
> > > > combined mode?
> > >
> > > As for non-MIME MUAs, I think Outlook is significant.
> > > (Being one of the developers of Gpg4win, you know that until recently
> > > it could not do MIME OpenPGP. And that Outlook itself it not fully
> > > MIME compliant, e.g. it does not display the text part of a
> > > multipart/signed email, though it MUST according to MIME standards.)
> >
> > Oh well, that may be a millstone around our neck for the time being.
> >
> > > There will be others out there as well, e.g. on older unix machines
> > > which did not update software very often.
> >
> > Not really what you are looking for, but: Somehow I question the
> > wisdom of relying on security software on such systems...
>
> Security is orthogonal to software modernisation: you might run a very old
> unix-like system which is fully supported and thus fine security wise,
> but still only has old software.
>
> Bernhard


-- 
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: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL: </pipermail/attachments/20081215/ba80c97f/attachment.bin>