Hi Albrecht--
Sorry for the late followup -- this has now been raised on
openpgp(_at_)ietf(_dot_)org, so i'm moving the follow up there.
On Sun 2015-02-22 13:14:36 -0500, Albrecht Dreß wrote:
I am currently working on the implementation of your proposal for Balsa [1],
and would like to add a few comments.
I'm glad to hear this!
Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor:
PGP/MIME messages are the only reliably structured mail OpenPGP e-mail
messages anyway [0].
As your proposal is fully transparent, I think it could also be used
for RFC 2633 S/MIME (i.e. multipart/signed;
application/pkcs7-signature as well as for application/pkcs7-mime).
yep, this seems correct to me, but i don't know enough about the S/MIME
world to take the proposal there. Maybe we should find some S/MIME
folks to chime in on this.
The embedded header part (F, above) should be Content-Disposition:
inline, and should be subject to all the usual rules of parsing mail
message headers.
In your example, you added a "charset" parameter to the mime type.
IMHO, this contradicts the RFC 6522 statement that it shall have
neither required nor optional parameters. I think it's unneeded
anyway, as all headers shall be encoded as required by RFC 2047.
Applying the "usual" header parsing rules will of course decode them
properly.
yep, you're right about this.
The whole part /should/ be encoded quoted-printable, though, as
required by RFC 3156, sect. 3. The headers /should/ be 7-bit clean,
but you never know for sure...
I think this also makes sense.
This e-mail message contains a signed set of embedded headers in the
way i've proposed. How does it render in your unaware MUA? feel
free to send me a private report if you like.
What do you think about always adding a header,
e.g. "X-Protected-Headers", which includes a short info about the
purpose of that part (as in this example)? Otherwise, it might be
somewhat confusing if such a MUA displays the header twice. If we can
agree on a standard name, it also assists MUA's to detect the block.
Are you thinking of having this line in the embedded header or in the
external header? I'm not sure that this is useful to have in the
external header at all. In particular, it won't be cryptographically
authenticated, and it won't be encrypted. So an attacker could (for
example) strip out the external header and cause the MUA to ignore the
embedded part.
As for the embedded header, i'm not sure it's useful there either. it
seems like a bit of a chicken-and-egg problem.
signed_headers:
* Subject
* Date
* From
* To
* Cc
As including more headers doesn't cost much, I propose to also add the
following:
- Reply-To: and Disposition-Notification-To:. Rationale: an attacker might
tamper them as to provoke sending information to arbitrary recipients (at
least for inattentive users, or for MUA's sending MDN's automatically).
- References: and In-Reply-To:. Rationale: avoids breaking the threading
information by an attacker.
I agree about the ones you mention here. Mail-Followup-To also seems
relevant.
encrypted_headers:
* (Subject,"ENCRYPTED SUBJECT")
* (In-Reply-To,<omit>)
* (References,<omit>)
IMHO, the list of encrypted headers could be the same as above.
i think the list of encrypted headers might arguably be *all* of the
headers except for some dummy block that is generated per-message.
We'd also need to define what happens if more than one
text/rfc822-headers part shows up in a multipart message -- most
simply, we could say that we only process text/rfc822-headers if it
happens to be the first non-multipart part within the
multipart/signed or multipart/encrypted part.
I think this should read: "if the text/rfc822-headers part is
* the first part of a multipart/mixed, which in turn is the first part of the
top-level multipart/signed or application/pkcs7-mime, or
* the first part of the top-level decrypted multipart/mixed for unsigned, but
encrypted messages."
That seems more narrowly scoped, which is probably a good thing, but it
might be more brittle too; are there specific cases that you're trying
to carve out from my broader suggestion?
This prevents the receiving MUA from applying text/rfc822-headers from a
forwarded (attached) signed/encrypted message.
It would make sense, though, to verify if the headers of forwarded and
signed message/rfc822 parts against the (embedded) text/rfc822-headers
parts.
what kind of verification should an MUA do? Is there any reason for an
MUA to prefer the external headers where the embedded headers and
external headers differ?
For encrypted headers, we'd *assume* that they would differ, right,
otherwise, there's nothing to gain from stuffing them inside the
encrypted section.
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp