[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim
Fenton
There's some ambiguity in the statement "can be used end to
end". One
way to read this is "is capable of being used end to end". Another
reading is "may work end-to-end [in some situations]". Some
people seem
to be interpreting the former as what we're trying to
accomplish, when
it's actually the latter.
Sure, any entity modifying a message SHOULD re-sign it. But
I don't see
any reason to explicitly exclude end to end use, if all the
intermediaries (and even re-originators, like mailing lists)
happen to
be "nice" to the message. Or is it that the "good enough"
solution you
have in mind explicitly excludes end to end use?
I think Jim is completely on target here. We are NOT trying to recreate
S/MIME here. But at the same time we are not attempting to create a little
cut out spec that can only do things that S/MIME cannot.
There are three differences in the new approach:
1) The authentication is for the benefit of ordinary users, not technical
specialists. That means no end user PKI interaction, no geeky 'web of trust'
nonsense and the majority of the keys are going to be domain level, not end
user level.
2) We are only doing authentication. I believe that one of the main reasons
that the email signature schemes we already have are inadequate is that the
priority was for encryption as the name Pretty Good PRIVACY demonstrates.
The idea seemed to be that signatures were just something that came along
for free with encryption.
3) The bogus end-to-end security doctrine is rejected. The best security
measures we have today are SSL and firewalls, both break the end-to-end
model. There are rare occasions in which end-to-end is the appropriate
security approach, it should never have become the governing doctrine for
security protocol architecture as it did. The time to write security
doctrines is after the Internet has been made secure until then they are
merely hypotheses that are subject to falsification.
Regardless of whether MASS is used to support 'end to end' message
encapsulation verification of the signature at intermediate stages is going
to be supported. The key infrastructure is going to be key centric and be
based on the use of some form of domain level key server, whether this is
through the DNS only or a combination of DNS and a separate key management
service such as XKMS the PKI is domain centric and NOT end-to-end.
I can provide a roadmap for how we can use MASS as a means to lower the
barriers to entry for traditional PKI technologies, but that is not the
immediate priority of this group.
Phase 1
Email signing at the domain level with support for per-user keying.
Two methods of key publication are supported. For the simplest cases
with a small number of keys the key values are simply published in the DNS.
Complex corner cases are supported by a separate key management service -
XKMS Locate. This means that a verification point has to support both key
distribution methods. This is not a major problem since XKMS Locate support
is no harder than the IIM key manager protocol, its just some extra angle
brackets.
Level 2
Third party accreditation
In order to provide real value as an anti-phishing technology we
need to get to a point where the end user expects to see authentication on
emails from their bank in a form that 95% of them can interpret immediately.
In my view this means making use of the X.509v3 logotypes extension and the
existing CA infrastructure that can perform the necessary back end
authentication.
Level 3
Encryption support
With XKMS in place it is now practical to add support for encryption
at either the domain or the per user level. I think that many of us now have
sufficiently complex email delivery situations that a combination is
probably required. A domain level encryption certificate for verisign.com
and an internal pki that decodes the blobs then re-encrypts them for
specific delivery devices. This can all be done using trusted hardware to
preserve auditability &ct.
This is the point at which the value of choosing XKMS becomes
apparent, XKMS already has a key registration protocol defined which
provides for complete lifecycle management of the keys.
Level 4
Intelligent Email Edge Servers
This is where the MASS based scheme finally meets up with the
traditional PKIX world, with SAML and the Semantic Web. This is the place
where the US Federal govt should be going. The bridge CA becomes a subset of
this security system.
Here the email security agent is responsible for making sure that
every email communication meets the necessary security requirements, as
dictated by policy and by knowledge of the other parties involved. For
example if Alice is a lawyer and Bob is a lawyer then it is probably the
case that the communication should be encrypted. If Bob does not provide a
published encryption key then maybe Alice gets a message back saying 'this
should probably be encrypted, continue without?'. Or as appropriate given
the circumstances.
Phill