[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MASS BOF Agenda and Proposed charter
On Fri, 15 Jul 2005, Michael Thomas wrote:
You surely have not read META Signatures documents to consider it to be the
same as DKIM. There are several core ideas that they share but
META-Signatures also has several important core ideas that are not part
of the DKIM, so this has nothing to do with syntax and semantics at all.
It would probably be useful to really sit down and think about
what those core differences are, and really, really make certain
that they cannot be accommodated by DKIM.
As I showed in examples in the docs, META-Signatures can do 100% what
DK or IIM or DKIM can do, but it does not work the other way around.
The key features of META that are not in DKIM:
1. Separation of content hash creation from signature, as consequence
ability to include hash of specific content parts separately (and
signature can then survive if any one part is missing at the end
for example). This has number of other advantages such as being
able to verify the signature if content itself is not yet available.
2. Ability to include public key as part of signature data - allows to
for example verify the signature offline (but not authorize the
signer - however ways exist to do it offline as well).
3. Support for multiple authorization systems (including ability to
support both public key retrieval and fingerprint verification)
a. Also under above support for linking multiple schemes, i.e.
like X509 certificate or PGP keyserver link or link to S/MIME
or PGP signature in the email if its added by MUA
4. New in META 0.2 and above support for multiple public crypto components
(and consequently multiple pki data parts) for the same signature
5. New in META 0.2 and above is support for multiple identities that
can be verified (multiple identities by the same signature).
6. New in META 0.2 (which was proposed for DK originally but not used)
is optional support for revocation service
META can be looked at as mini x.509 designed to be as compact as possible
for use of header fields data block signing.
merging the spec, half of the problem was making certain that
the things we were concerned about could be adequately expressed
with the other spec or not. It took a fair amount of thinking on
our part to come to the conclusion that many features were in
fact isomorphic, just expressed in different ways.
Please be specific on what those feature so we could see if that is so.