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,
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.
Hallam-Baker, Phillip wrote:
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]