Dave, you use the words "recipient" and "MUA" in several places in your
dialogue below. I presume you mean the end-user when you say it.
That being true, that is where you and I diverge. To my understanding,
if you include "recipient" in the problem space then you are reinventing
an end-to-end secure email technology and I am completely opposed to it.
Other than that, I won't reply point by point in an attempt to keep this
at a charter discussion. I will refer you to my message on signature
semantics though.
Thanks,
Jim
On Tue, 5 Oct 2004, Dave Crocker wrote:
Date: Tue, 05 Oct 2004 14:31:57 -0700
From: Dave Crocker <dcrocker(_at_)mipassoc(_dot_)org>
Reply-To: Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com>
To: James M Galvin <galvin+ietf-mailsig(_at_)elistx(_dot_)com>,
Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com>
Cc: Andrew Newton <andy(_at_)hxr(_dot_)us>, IETF MAILSIG WG
<ietf-mailsig(_at_)imc(_dot_)org>
Subject: Re: Narrow the scope: no new email signature protocol
>> a) protect headers
> This is a common misunderstanding. In fact, S/MIME and PGP
> do protect headers perfectly and correctly, insofar as it is
> possible in both to protect a MIME object. You simply
> protect a message/rfc822 object, which can be scoped
> (profiled) by specifying which headers to include.
>
> 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.
And, yes, the embedded-object approach also does violence to the
installed base of MUAs.
> 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.
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.
>> 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?
Absent them, then there is a development and adoption phase to
go through, just like any other proposal.
>
> And the lookup can then be DNS or some other key lookup
> service.
but this requires a development and design phase, so what does
choosing s/mime or pgp buy us?
>> 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.
> However, an assertion that I made in one of my first messages
> in this thread (a point that Ned Freed also called out as
> true in his experience) is that the processing required at
> the MTA-level to deal with the embedded body part is exceeded
> by the processing required to deal with the security. And,
> frankly, the MTA is already dealing with the entire message
> so what's the real difference between a body part or a header?
impact on non-adopting recipients.
>> I am not understanding how "making the changes" differs from
>> a design and development effort.
>
> The first design effort that I believe needs to be done is
> the key management. The key management this effort needs
> does not exist in any other protocol I can think of in the
> IETF.
This goes back to the basic strategy of starting from scratch and
designing each component of the system, versus using existing
proposals and tuning them. The former is certain to take a very
long time, probably measured in years.
> The second bit of design effort is to decide on the actual
> service to be provided. The extremes as I see them are as
> follows.
well, we certainly need to have this stated explicitly.
> 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?
> 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.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker(_at_)(_dot_)(_dot_)(_dot_)
brandenburg.com