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