Hi Albrecht--
On Sun 2015-03-22 11:56:42 -0500, Albrecht Dreß wrote:
Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor:
Are you thinking of having this line in the embedded header or in the
external header?
Only in the embedded, signed headers block.
[...]
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.
Hmmm, yes, thinking again about it, you're right. The only use of
that header would be informing the recipient of a message about the
purpose of this part if the MUA does not perform any further action
with it (see the attached screen shot as example).
Hm, if the goal is human-friendliness, then we probably want to think
about how to be even friendlier -- english text plus a URL to an
en_US-only webpage isn't very nice to the majority of the world either
:P
i think the list of encrypted headers might arguably be *all* of the
headers except for some dummy block that is generated per-message.
What do you mean with "some dummy block"?
the "dummy block" is the headers that get wrapped around the outside of
the message.
Alexey Melnikov just pointed me to this draft:
https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00
which has a similar mechanism (and is designed for S/MIME), and it
refers to the same idea as a "stub value"
https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00#section-3
BTW, the Message-Id header may also leak information if uses the
recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand
side). The 'dot-atom-text - "@" - dot-atom-text' format with random
data on both sides (which is also explicitly allowed) should be
preferred IMHO, as long as it is guaranteed to be unique.
good point!
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?
I think your definition would try to match the text/rfc822-headers
part to the message headers in the following weird case:
multipart/signed
+- multipart/mixed <-- message #1 does *not* contain protected headers
| +- text/pain
| +- message/rfc822 <-- forwarded message #2 *with* protected headers
| +- multipart/signed
| +- multipart/mixed
| | +- text/rfc822-headers <-- protected headers of forwarded
message #2
| | +- text/plain
| +- application/pgp-signature
+- application/pgp-signature
Here, text/rfc822-headers *is* the first non-multipart part within a
multipart/signed, but it doesn't belong to the (top-level) message #1,
so it's wrong to compare them. I think, my definition would catch
this case.
You're right. I think this distinction is useful.
PS i love the content type "text/pain" -- can we register that one officially,
please? ;)
Melnikov's draft proposes a content-type parameter "forwarded" to be
used on the message/rfc822 element, to distinguish these cases. I
haven't thought through the consequences of the way this his draft sets
it up, though -- it seems possible to misinterpret the lack of a header
from a non-compatible sender forwarding a message.
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp