"Brian G. Peterson" <brian(_at_)braverock(_dot_)com> writes:
Here's my issue with PGP/MIME (RFC 3156) The PGP/MIME standard defines
placing an email-specific Content-Type header inside the section covered by
the signature, making verification of binary content difficult outside of a
mail client. Further, almost all implementations generate a single signature
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.
One of the users of the GPG Plugin for Squirrelmail the I am the primary
implementor of is human rights workers (via the CryptoRights Foundation).
For evidentiary reasons in this implementation, it is critical that each
binary attachment (documents, pictures, whatever) have independently
verifiable signatures. The 'partitioned' method accomplishes this, by
encrypting/signing each part, so that each part is independently
decryptable/verifiable, even outside of an MUA. I think that independent
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
this is a bit out of scope for the current discussion of preference
notations).
That was a good summary of issues with PGP/MIME. I hadn't been fully
aware of these before, although now that you make them clear, I recall
several situations (think proxies) where this has been an issue.
If you are seriously proposing to make inline/partitioned a standard
scheme for PGP in e-mail, you should describe how it should be
implemented. I have experience with the inline style, and
non-deployed experience with the "partitioned"-style. The problems
that need to be addressed to make this a serious alternative is RFC
1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
in bodies and PGP headers), trailing white space interaction with
format=flowed, interaction with QP and '-' and '=' in the PGP armor.
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.
Or a separate document. I agree. I think the reason people don't
implement inline/partitioned is that there simply is no specification
for how to do it. And there are a number of complicated things to
solve to implement it. Whether to apply the non-ASCII processing in
MIME before or after the PGP layer is one open issue. If QP is
applied before PGP, it is also unclear how to deal with escaping of
'=' for QP in the PGP CRC24 field.
Regards,
Simon