Vs Combined Method? E+S from RFC 3156 6.2
Bernhard Reiter
bernhard at intevation.de
Tue Dec 16 09:33:03 CET 2008
Am Montag, 15. Dezember 2008 17:53:06 schrieb Werner Koch:
> >> It is merely that I suggest to use the standard method as per rfc3156.
> >
> > The combined method _is_ a standard method of rfc3156
> > as it lists both methods. Where do you read out a preference of any of
> > them?
>
> RFC 3156 has to say this in section 6.2:
>
> [...] This method is allowed
> in order to reduce processing overhead and increase compatibility
> with non-MIME implementations of OpenPGP. [...]
>
> and a few lines later:
>
> It is explicitly allowed for an agent to decrypt a combined message
> and rewrite it as a multipart/signed object using the signature data
> embedded in the encrypted version.
>
> To me this is clearly a preference towards the standard (non-combined)
> method.
This is a weak perference (unfortunately) if it is one at all.
To "allow" the combined method and to allow to rewrite it might be interpreted
that the other one is prefered. If the RFC writers would have thought about a
preference they should have written something like
The method from 6.1 SHOULD be used.
or that it is RECOMMENDED.
The fact that they did not will make most people believe that there is no
preference. This might be an oversight of the RFC writers then.
So I still believe that having the arguments _why_ the combined method
SHOULD not be prefered would be helpful to convince implementors.
--
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: 206 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081216/6c544704/attachment-0001.pgp>
More information about the Gnupg-devel
mailing list