I'm surprised I can make a statement like "perhaps this group should not
be chartered" and get no reaction. So let me try a different approach
in this thread.
I agree with everything John Levine said. I would add that when you
don't explicitly have requirements it is important to have a clear
problem statement so that the goal is well understood.
What I don't get - and perhaps it's just me in which case I would
appreciate being educated - is how the problem stated in the charter of
this group (adding signatures to email) is a different problem than has
already been solved 5 times over for email?
Perhaps it's just me again, but I don't find the distinguishing
characteristics listed in the charter compelling. Not to oversimplify,
but:
> Existing standardized mechanisms, for attaching a digital signature
> to an email message, are designed for different use than is required
> in this application. These distinctive requirements and
> characteristics may include:
>
> - Automated signing of outgoing messages by any SMTP-initiating
> entity.
> - Minimal computational and transactional overhead for high-volume
> email servers.
> - Anonymity when when desired by the sender
> - Short term protection for purposes of transit
> - DNS-based key-related queries
> - Facilitating offline validation
>
> The working group will review and revise this list, in order to
> provide a clear statement of the engineering constraints and
> freedoms that apply to this work.
In the case of automated signing of messages, any SMTP client could
easily be enhanced to apply an existing secure email standard to every
outgoing message. I built one of these back circa 1990, when the email
standard of the day was Privacy Enhanced Mail (PEM). We did it at the
application later as proof of concept, as part of the MTA, but in
principle it could easily have been pushed down into the SMTP client.
Keeping overhead down for high-volume email servers is problematic. As
soon as you add cryptography to a protocol it dominates the performance
characteristics. It's not clear to me what solution is going to
improve that. At high volume the usual solution is to add hardware
(CPUs, networking, encryption hardware) and I don't see that changing.
One potential area of overhead worth considering is the choice of where
the security parameters go and how they are represented. One could
argue that using S/MIME or PGP is weighty in the same way that using
HTML instead of text is weighty, but does anyone have any data on
whether the "weight" is in the cryptography or the message processing?
Putting the parameters in the SMTP transaction itself is probably a win.
Anonymity and short-term protection is all about choosing the identity
and the key sizes. You could apply the same requirements developed here
to any secure email protocol to achieve the goal. This is probably a
distinguishing goal.
Using the DNS to store the key could be used by any protocol. S/MIME
and PGP might need some tweaking (a profile) to get just the right
behavior for the lookup, but that's not much different than doing
something new.
And clearly both S/MIME and PGP support offline validation. If there's
data from the SMTP transaction that's need then an MTA will have to
account for that, but I don't see that as a significant issue.
So what am I missing?
Jim