On Monday 17 January 2005 03:47 am, Werner Koch wrote:
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.
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
a lot of work that should be unnecessary.
A signature across all the MIME parts to verify the entire email structure,
plus separate detached signatures on each *attachment* (without the
unecessary Content-Type header that RFC 3156 unwisely requires) would allow
for simple signature verification of the signature on any attachment, using
any OpernPGP compliant tool, and requiring no MIME knowledge for the
verifier.
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
difficult. This is, in my opinion, a serious flaw in RFC 3156.
Partitioned is not much better, because it does, as you note, have UI
difficulties in presenting the information to the user, verifying signatures
on each individual part and across the whole. Partitioned implementations
currently have the advantage that the signatures on each attachment do not
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.
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.
If each attachment were required to have an independently verifiable
signature, then there would be no difficulty in doing so, and you wouldn't
need MIME tools and technical knowledge outside the MUA to verify the
detached signatures.
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.
Because they chose to, because it is the right thing to do. The RFC does not
require it, which was my point.
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.
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
separate signatures on attachments, would remove my complaint about RFC 3156.
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.
The only reason is allowing plugins for Outlook. I don't
expect that Cryptorights suggests the use of that MUA.
No, Cryptorights does not use Outlook internally, or recommend it to others
where security is an issue. However, many *recipients* of mail from human
rights workers will undoubtedly be using MS Outlook. Interoperability is in
everyone's advantage, as I'm sure you agree. Having the standard be clear on
what is required for interoperability makes it far more likely than in the
current state where the right thing to do is not the same as the minimum that
the standard requires.
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.
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,
and indicate whether they would be willing to comment on that proposal:
putting email preference data in the existing preferences packets on the key.
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.
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.
Regards,
- Brian