I was going to reply to a few messages but in the spirit of keeping this
to a charter discussion, it seemed to me that the question of the
semantics of the signature is at the core of what this working group
proposes to accomplish.
The proposed charter currently says this:
The MASS working group will specify an Internet mail mechanism for
transit-time use, to cryptographically authentic the author or
sender of a message and its content; the working group will
determine which is used. The working group will determine which
portions of the Internet mail protocols to modify.
The primary issue that I am raising is the conflict betweeen the phrases
"transit-time use" and "authenticate the author or sender".
If the goal is to authenticate the original author or sender, normally
called the originator of the message, then I remain completely opposed
to this working group. To me that goal is "reinventing" secure email
(PGP, S/MIME, whatever) and, speaking personally of course, I have not
seen any compelling reason for doing so.
On the other hand, if the goal is best represented by the phrase
"transit-time", I may be in favor of this working. For the purposes of
being clear about what I believe can and should be done, let me describe
a somewhat contrived example.
Alice is an MTA with a message M that Alice controls. How Alice
came to control M is confidential to Alice. Perhaps an MUA
submitted M to Alice. Perhaps another MTA relayed M to Alice. In
either case, the initiating side of the connection that gave Alice
control may or may not have been authenticated. There is no way to
know without explicitly asking Alice through some out-of-band means.
Alice is willing to take responsibility for controlling M.
Alice needs to relay M to another MTA, let's call it Bob.
Alice creates a signature to include with M asserting
a. she currently controls M
b. she can be contacted if there are issues with the M
The signature is created with a public-private key pair that belongs
to the domain in which Alice controls M. Note that Alice may have
responsibility for many domains so the choice of domain is
important. Especially important is the fact that this signature has
nothing to do with the content or origin of M. (Well, not quite,
since the signature may be applied to a hash of the content and/or
some amount of the envelope information and/or some amount of the
headers, but that's a detail for the purposes of this discussion.)
Alice contacts Bob, sends M and the signature. These will be
packaged together according to the technology used to create the
signature.
Bob validates the signature. Assuming it validates Bob now knows
for certain the immediately preceding MTA that controlled M.
Bob can now do whatever else Bob wants to do to confirm that M is
suitable for delivery. Perhaps Bob has a policy that says all
messages from Alice can be passed on without further delay. Perhaps
Bob does not really know Alice, in which case Bob will perform
additional checks on M. Perhaps Bob will perform additional checks
on Alice.
If Bob approves of M then Bob continues its delivery. Details of M,
the signature, and the validation are logged. The same message that
Alice delivered to Bob (M but without Alice's signature) is
delivered.
If Bob disapproves of M, Bob knows where to go to complain. Bob
could even decide that all future messages from Alice are to be
discarded.
This example explains what I meant by "in the small" in a prior message.
Certainly layers can be wrapped on this up to and including an
end-to-end signature. Whether or not such layers are important or
useful deserves discussion in this working group. Stopping just short
of an end-to-end signature is what I meant by "in the large".
The critical phrase above is that the signature asserts the identity of
the prior hop that controlled the message. Nothing more, nothing less.
It is a "domain-based" identity. In particular, it does not
authenticate the sender or author.
This means that if "layering" is not a requirement, then TLS/SSL is a
solution. The deployed TLS/SSL base focuses on authenticating the
server but it certainly supports authenticating the client.
S/MIME and PGP are both perfectly capable of being a *PART* of a
solution to this problem. They are not a complete solution because the
standard "profile" for both presume they are operating in an end-to-end
context, which forces certain assumptions about the identity in use.
Further, they both operate with "certificates", which forces certain
assumptions regarding key distribution.
It is these latter two points that this group needs to decide. What
identity do we want to be asserted? And second, given an identity, how
are we going to retrieve and distribute the public key it uses.
We also need to decide what we want the identity assertion to mean.
I've proposed above that it means only that the MTA "controls" the
message. Simple, short, and to the point.
We can sign anything we want. The working group needs to come to
consensus on what it wants to sign.
A secure email technology requires two inputs: a blob and a public key.
It produces two outputs: a blob (the same in a signature case, encrypted
in the confidentiality case) and set of security information.
Both S/MIME and PGP actually support more than one means of conveying
that information: security multiparts and something unique to itself.
Do we need another means of conveying the security information?
My point is, if you want to create a signature for or encrypt a blob, we
have several technologies to choose from, at least of two popular ones
are specific to email, the application context for this working group.
Our focus needs to be on using one of them.
On the other hand, perhaps my "contrived" example is way off base, in
which I need a little bit of education.
Jim