On Tue, 5 Oct 2004, Dave Crocker wrote:
The problem is that MUAs do not deal with embedded
message/rfc822 inside a protected content. They never have
and probably won't in the forseeable future.
I think it is worse than that. What you are describing is
protection of some data in the contents. It does not constitute
protection of the message's headers.
Including entire message/rfc822 as content means all headers are duplicated
in the message. You can do it, but I only see few headers that are of such
importance that they need to be duplicated with signature and besides that
why bother duplicating them with new embededed types instead of just
adding them into signature itself.
And, yes, the embedded-object approach also does violence to the
installed base of MUAs.
Unfortunetly this is true. And things would have been easier if how MUAs
are supposed to diplay message to end-users was better standartized.
However, the community-of-users here is not end-users but
MTAs.
Although there is an expectation that MTAs will be the initial
implementation venue, the model for most/all of the proposals
permits MUA to MUA validation. This is an important point.
Well not quite correct. Some proposals permit MTA to MUA verification but
practicly none of the proposals are really covering signatures added by MUAs
(but its probably possible since if MTA can do it so can probably an MUA)
There is, also, the question of impact on non-implementing
recipient MTAs and MUAs. Embedding the protected object does
violence to the receiver, pretty much rendering them unable to
process the message normally, I think.
This depends on how object is embedded. For example multipart/mixed
messages are mostly displayed fine even if its more then one layer of
the multipart/mixed objects.
As far as using S/MIME encoding of mesages, I've tried it and did find
problems. Apparently some MUAs experience fatal errors if you're using
Multipart/signed and the signature itself is not S/MIME pcks7-signature
(mozilla quit entirely and outlook refused to display message). There are
also problems when both PGP and S/MIME signatures are included together.
Unknown data types however are mostly ignored by MUA (some will annoy user
and ask what to do with it) and even better with unknown multipart/xxxx
entities - apparently MUAs will not even bother reading them and so
non-supporting MUA might not even display that there are any unknown
attachments.
BTW - I've found all this out experimenting with about 10 different MUAs
and manually trying various designs of signatures. I've done several dozen
different experiments until I found what works and what does not.
b) use domain-scope identification
c) DNS-based key validation (or acquisition)
This is not a core S/MIME or PGP issue, per se, but rather a
key lookup issue. The profiles that exist for S/MIME and PGP
emphasize the use of the email addresses in the envelope for
key lookup purposes. It's a simple matter of using the local
domain or the domain from the recipient's address to do the
key lookup, depending on what security service you're trying
to implement.
Where is the specification for this and the established practice?
http://www.ietf.org/rfc/rfc3183.txt
http://www.ietf.org/rfc/rfc3850.txt (see PKIX certificate extension)
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-15.txt
(actually take a look at entire set of documents listed at
http://www.ietf.org/html.charters/pkix-charter.html)
Absent them, then there is a development and adoption phase to
go through, just like any other proposal.
Naturally, but that does not change the point that reusing somebody elses
work that is very similar to your is easier then reinventing the wheel
all together.
d) header-based attribute encoding
This confused me for a moment but I presume you mean ala
domain keys.
security/multipart places the security attribute information into
a special mime body part. some of the proposals before us now
place that information into headers. this has been justified as
reducing the impact on non-supporting recipients.
The other side of the coin is that you're using what were inteded as short
text-only trace lines in order to provide information about a lot larger
non-text security data profile. Remember - embedding non-ascii text in
headers is not an easy thing either...
impact on non-adopting recipients.
As I indicated before, the header is not the only way to make signature
invisible to non-supporting MUAs and I'll be quite happy to show that in
practice if you dont' believe me.
In the small we are talking about a signature that is valid
from an initiator to a responder, and then discarded by the
responder. It creates a new signature as an initiator for
the next responder.
i think that accurately represents the current proposals.
does anyone disagree?
Yes. I have problems with these "intiator" and "responder" terms..
And in my view signature should never be discarded (unless its special
case that email has been verified by MDA and now its going to high-latency
or high-traffic-cost MUA such on mobile phone client).
Now if email is replied to, then its ok to discard the old signature as
its entirely new email.
In the large we want to carry all these intermediate
signatures so that at any point along the path an MTA could
validate any other point.
I agree with above.
uhhh. i do not recall hearing that said generally, so i think
that expectation/requirement is, at least, likely to be controversial.
carrying history can be expensive.
In what way expensive? The extra bandwidth these signatures take?
I don't think its a big deal any more considering that ISP bandwidth
infrastructure has increased by 1000% and has no problems carrying all
the those large mpeg files from end-end (while at the same time the
amount of email traffic as percent of total has decreased because email
is now viewed as low-traffic protocol - well except for spam, of course :)
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/