Fair questions. Here's my "clarifications."
There are observations that s/mime and pgp do not
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.
However, the community-of-users here is not end-users but MTAs.
Unattended MTAs at that. The community to be educated in doing this
properly is orders of magnitude smaller (in fact the vendors, not even
the users) so this should not be a significant burden.
By the way, I can say that with a perfectly straight face because I've
done exactly this over 10 years ago, and had it working in a production
environment. It was done with PEM back then but it would be a simple
core technology swap of PEM for either S/MIME or PGP to make it work
today. No, they don't use it today. This was just in front of VPNs, so
as soon as that was available the email "gateway" wasn't needed anymore.
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.
And the lookup can then be DNS or some other key lookup service.
The point here is that key lookup is a service to S/MIME or PGP. Swap
in the choice du jour.
d) header-based attribute encoding
This confused me for a moment but I presume you mean ala domain keys.
This is a fair distinction between using S/MIME or PGP versus anything
else. In MIME terms, both of those technologies create a set of
security parameters that are best transferred in a separate body part,
ala security multiparts. The comparison here is much like the one one
might make between HTML and XML.
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?
Also, you have to carry the same information. So what's the real
difference between cramming it all into a header versus putting it in a
body part. An issue to be concerned about is exceeding the practical
limit on the length of a header.
The response I am hearing is that there are no inherent
difficulties in making the changes to s/mime or pgp to cover
these.
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. Currently, what I believe
this groups needs is to have the keys stored in the DNS. This
application is perfect for this because it is a domain-based lookup,
which is exactly the lookup the DNS is designed for.
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.
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.
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. We
will want to be careful about creating an end-to-end services, since
that would then compete with S/MIME and PGP.
I certainly have my own opinions about solutions to both these issues,
but they are nonetheless worthy of detailed technical discussions. :-)
Jim