On Sun, 16 Jan 2005 12:11:03 -0600, Brian G Peterson said:
across all parts, generating a signature for the entirety of the
email-specific MIME structure, and not signing individual attachments. I
believe that this is a serious flaw in RFC 3156.
That is not a flaw in rfc 3156 but in the implementations. The same UI
requirements hold true for that partitioned format.
Kmail for example allows to select the attachments to be signed. By
using forwarding and combining messages you are able to select
different signatures with any fully MIME aware MUA.
decryptable/verifiable, even outside of an MUA. I think that independent
Again, that is a matter of the tools and not of the protocol. In fact
it is not that hard to verify PGP/MIME with a simple script and the
usual mime tools. The real challenge is to present the signature
status in an appropriate way to the user.
verification of a signature on each part, and a signature across the whole,
are a feature that should be required of any email implementation (although
Kmail as well as Mutt allow exactly for this. Any MUA with proper
MIME and OpenPGP support will handle this.
Many MUA's have chosen to not support inline or partitioned methods of
Encrypting/Signing mail content. This seriously limits interoperability, and
I think that this needs to be addressed in RFC 2440bis (because that is what
is under discussion now) and in any future revision of RFC 3156.
There is only one MUA which causes all the problems and that one is
notriously known for its security flaws. MUAs not doing PGP?MIME do
this to be compatible to that one other MUA.
I do not believe that support for partitioned in the notation packet implies
RFC 1991 compatibility. We have decided that 2440bis will obsolete RFC 1991,
Please recall that 1991 is informational and not on the standard
track.
'partitioned' scheme is the only option currently available to implementors
who require independent verification of each part, as well as verification of
Wrong. The only reason is allowing plugins for Outlook. I don't
expect that Cryptorights suggests the use of that MUA.
I am not against these preferences but they should not in any way
endorse non-PGP/MIME. Keeping that off the standard and using agreed
on notation data is thus the better decision. For technical reasons
I'd like to see it done in the same way as the preferences but I fear
that this will lead to practically abolish PGP/MIME.
Salam-Shalom,
Werner