[fwd] Re: PGP/MIME implementors: text mode vs. binary mode? (from: firstname.lastname@example.org)
roessler at does-not-exist.org
Thu Feb 15 09:11:03 CET 2001
On 2001-02-14 18:58:11 -0600, JP Sugarbroad wrote:
> On Wed, Feb 14, 2001 at 11:18:27PM +0100, Thomas Roessler wrote:
> > More precisely, PGP/MIME helps to address several ugly problems you
> > normally have with detached signatures:
> > - PGP/MIME includes MIME headers with the signature, thereby
> > indicating how the signed data should be interpreted. This can be
> > crucial - remember all these nice "is valid in N+1 formats" files?
> > (For instance, you could do interesting things with XPMs.)
> That's the point. It's a TRANSFER encoding. It is 100% valid to
> change it on the fly if necessary. If PGP/MIME signatures were
> pre-CTE, said change would not invalidate the signature.
What's your point here? Do you really say that MIME headers
shouldn't be included, because it's a valid transformation to change
a body part's content-type?
>> - PGP/MIME signed messages can be read by MIME-aware, but
>> PGP-unaware clients, with the same results as far as the
>> signed data are concerned. I have yet to see any other
>> signature scheme which has this property.
> So could a standard which was identical to PGP/MIME except that
> the signature is calculated on pre-CTE data.
In this case, you'd have to come up with some other well-defined
encapsulation which permits you to include meta-information with the
signed material, thereby protecting it. This does, in particular,
mean that sender and recipient would have to apply this
transformation to the data, and that this transformation would have
to be well-defined down to a single bit. (You couldn't even use
PGP's packet format, since you can represent the same data in
different ways there.) Now, why shouldn't MIME be taken for this?
Just so some people can play around with others'
content-transfer-encodings in transfer, which is a bad idea in any
Thomas Roessler <roessler at does-not-exist.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 475 bytes
Desc: not available
Url : /pipermail/attachments/20010215/cba239c7/attachment.bin
More information about the Gnupg-devel