The debate I hope to carry here is that domain keys should be a subset of
smime and not try to design yet another message format.
That way we can get end to end in the end or at least when relevant.
I would guess that you guys also have cases where end to end is not the best
approach.
Time to ditch the dogma. The real prolem with ideology is that it is usually
part way right, problem is that it isn't completely right.
-----Original Message-----
From: David P. Kemp [mailto:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Fri Jun 25 08:03:32 2004
To: Hallam-Baker, Phillip
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Anti-spam news article / S/MIME Gateways
Phill,
I'll look forward to the draft, to better understand what is needed
beyond user agent enhancements and "better discovery protocols".
Client A ---------> GW A -----------> GW B --------> Client B
\--------> GW C ---------> Client C
1. Assume no clients support S/MIME, A sends a message to B and C;
GW A needs to discover the gateways serving B and C and encrypt
to the appropriate GWs.
2. Assume only Client B supports S/MIME, GW A needs to discover
GW C and the fact that User B has a cert.
3. Assume only Clients A and B support S/MIME, Client A needs to
discover User B's cert and discover GW C's cert as a proxy for
email address of user C.
An in-band signalling mechanism can only work between signalling-
enabled nodes, which I assume means S/MIME-enabled nodes. What
kind of signalling is needed other than agreed mechanisms
for handling mixtures of "*(_at_)foo(_dot_)com" gateway certs,
alice(_at_)foo(_dot_)com
user certs, and Bob (no email address, multi-mail-server) user
certs. In other words, I don't see what in-band signalling
(contained in messages vs. certificates) you have in mind.
Of course we bone-heads want to ensure that when end-to-end
is available, a MITM can't exploit gateway features to bypass
it. But that just means that end-to-end must have priority,
not that it's end-to-end or nothing.
Dave
Hallam-Baker, Phillip wrote:
Trevor,
The CMS format is fine, 95% of the spec is fine.
The problem is that there is a 5% gap between what S/MIME delivers
and what is needed.
I think we can close the gap, the key is to throw away the bone
headed insistence that some people had concerning the end to end model or
nothing. We tried that for ten years, we ended up with nothing. IPSEC
makes
a lousy VPN protocol for the exact same reason, give me something that
really works through a NAT box without complaint any day.
What is needed is more than just better discovery protocols, or
logos in the certs. We need better client interfaces, we also need an in
band signalling mechanism so you know that when S/MIME enhancements are
being added that the channel can support them, including stripping them
out
if some appliance or client turns out not to support them.
[Draft to follow]
Phill