On 1 Oct 2004, John Levine wrote:
The first is what the signature is intended to protect. S/MIME and
PGP are provide long-term verification. I can pick a message out of
an archive that's two years old and check the PGP or S/MIME signature.
That's sometimes useful, but it means that the signatures have to be
extremely resistant to all of the stuff that might happen to a message
in transit or storage, and have to be strong enough to resist an
attacker that's willing to leave a key cracker running in the
background for months.
To be more accurate to what John said, PGP and S/MIME offer not just
signing the message but encrypting it and encryption requires strong
cryptography, so that publicly viewed text can not be easily decrypted.
Signing does not require this all by itself as you already know the text.
STARTTLS protects a channel, but it's not end
to end and not per-message. I think the intention in MASS is to
verify a message during an end-to-end delivery process that typically
takes a few seconds, and at the outside takes a week,
Basicly it means while we can expect message to be verifiable during
maximun delivery timeframe (or double/triple normal 5-day delivery
timeframe), after that the signature verification is no longer important.
This basicly allows for fast rotation of keys to protect against possible
attacks against the system.
and (debatably)
doesn't have to survive all of the mangling that might happen to
messages as they pass through mailing lists and the like.
This I STRONGLY SGRONGLY disagree. The system MUST be able to work
within current email infrastructure and not break it. That means
the signature must survive emails and forwarders and all other common
email retransmision systems.
It's not intended to protect channels or messages in long-term storage.
In reality it kind of protects channel if SMTP Client added signature and
SMTP Server immediatly verified it.
The second is the level of signing granularity. S/MIME and PGP sign
at the individual mailbox level, STARTTLS signs at whatever level the
certificate names are, but the proposals for MASS sign at the domain
level.
The are several proposals that easily allow for mixing of both domain and
individual emailbox signatures, but based on these signatures having
automaticly added by MTAs.
The goal as I understand it to be able to assign message responsibility
to domains since they're a lot easier to trace than individuals.
Probably more correctly is that signature verification is assigned to MTAs
with domains and dns serving as tool (one of the possible tools).
The third is key distribution. S/MIME and PGP work OK once you have the
keys, but neither has a key distribution scheme that works in practice.
S/MIME requires central source for key authority. Once we can get passed
that with likes of MTA-Signature's Certificate-Verification-Service
attribute (which allows signature itself to include information about
who can verify by means of commmon dns or web setup), it becomes easily
possible to reuse most of its mechanisms.
PGP has implemented a working "web of trust system" which already includes
million of users (and some predicted this would never work on such a scale).
I really like to explore it further as one of Certificate-Verification-Service
mechanisms as this allows for future email reputation service.
STARTTLS has no key distribution scheme at all. A scheme
for MASS has to permit signing key retrieval that is fast and entirely
automated. DNS seems the most likely distribution scheme, but I could
imagine something using http.
I personally think we have to allow for both options and for upgrade mechanisms
to support future services without making those who use it incompatible with
previously defined mechanisms.
Are these requirements? I suppose so, but they all seem pretty
obvious in context.
I don't think we can list all of this in the charter. That is why I think
having a requirement document is more important even if it is fairly short.
And no - I do not see that we have yet reached a consensus on all the
requirements.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/