On Mon, 17 Jan 2005 08:07:59 -0600, Brian G Peterson said:
Your examples serve to show the flaw in the RFC. Because the RFC does not
specify that each attachment should be signed as a digital file with a
detached signature to allow external verification, the user is required to do
PGP/MIME describes a MIME content type and trhat's it. It does not
give guidelines on how users should write or sign mail; that is a
policy decision and not in the scope of a MIME.
RFC 3156 does not forbid this kind of behaviour, but it does not require it
either, so most implementations have chosen to supply one signature across
all the MIME parts, making verification outside of an email systems extremely
In most cases there is no need to separate signatures. They only make
sense if you either receive and forward a signed attachment with a new
mail or you want to save the attackment independent of the mail.
That is an organizational issue and a technical one.
require a MIME compliant MUA/program/script to verify. They are
independently verifiable once detached from the MUA. I just want that
independent verification standardized in MIME implementations as well.
You need a pretty complicated tool to very the signature but don't
want to throw in a couple of lines for a tool for proper MIME parsing?
That is strange. Go to any vendor or hacker and ask for an
appropriate tool; its easy build.
Inserting a MIME-specific Content-Header inside the boundaries of the
signature is a *problem* for independent verification. Removal of the
unneeded Content-Header and MIME junk from attachments, and requiring
It is not a problem but a MIME requirement. Without the
content-header you have no way to identify the used charset. Without
this infotrmation you are not able to display a document correctly -
it might even convey the wrong message: There are similar character
sets using the same encoding for the national currency symbol. It
makes a lot of difference whether to talk about British Pound or USD.
It sometimes happens that you need to compile a message from different
sources where those message are not all in utf-8. Indicating the
characterset is thus a requirement; you might not even be able to
recode all character set if you didn't install it or there are no 1-1
conversions possible. And recoding would break the signature.
Some MUA implementors (KMail, Mutt, the GPG Plugin for Squirrelmail) do this
already, because it is the right thing to do. I just want to see the
standard (a future revision of RFC 3156) support and require that.
Huh? You mean they don't send a content-type if it defaults to
us-ascii? Well, this is possible but in the majority of the world's
languages this does not work.
It looks as though the PGP Corp folks have chosen to implement it not using
the standard preferences model. Perhaps Hal or Jon could comment on this,
Which is the Right Thing to do; unless it is defined by the standard
they may only use the namespace reserved for private use.
that this will lead to practically abolish PGP/MIME.
I don't think that is the case. I too would prefer to use PGP MIME with
minor
improvements on the standard to guide MUA implementors to do the right thing.
MIME and PGP/MIME are a reality and both are good and usable standards;
used in all modern IETF protocols - not only for mail. Its a bit
strange to hear comments against the use of MIME only from people
using almost only English and ASCII for there communication. The
world is not anymore plain 7 bit; these times have fortunately gone. I
am not the only one glad to see that there are no more printouts like
"foo_t fooÄ3Ü = ä 'ß', 1ö2, 'Ön' ü;" as common in the pre MIME days.
Shalom-Salam,
Werner