At 1:25 AM -0700 4/22/1999, Adam Back said:
Jon Callas writes:
> The consensus that I've seen is against overloading message integrity on
> signature packets.
I disagree. Perhaps you weren't reading.
Nope. The consensus that I've seen since late last year is for a new data
packet that has a standard encryption mode, be it CFB or CBC, and a hash in
it. What I see *now* is that you want to revise that consensus.
I've seen arguments as follows:
(1) The MIC-signature can ride on existing signature processing. However,
it raises the question of how to handle it and public-key signatures too.
The issue of wanting both MIC-sigs and PK-sigs and how they interact in a
single message needs to be looked at, especially if we care about backwards
compatibility.
It's also allegedly easier to implement this way. I find Tom's report of
how easy it is significant. It would be nice if we had someone implement
both methods so they can be compared.
(By the bye, it is not a goal of this working group to make it easier to
tack features on to 2.X, especially now that there are two other
implementations out there that can be relatively freely modified -- Tom's
and Werner's. One of the OpenPGP principles is to encourage but not require
compatibility with 2.X.)
(2) There's a desire to deprecate PGP-CFB mode over time, and use either
standard CFB or CBC mode. This requires a new data packet anyway, so why
not kill two birds with one stone?
(3) A MIC-signature computes a hash over the plaintext. The integrated
packet computes it over the actual encrypted content, which is likely to be
compressed data, and may also include a real signature. This has the
advantage of providing an integrity check on the signature and compression
when they're available, as well as the meta-data (mode, filename, etc.) of
the literal packet.
This is important in the case where a message has been damaged, and you'd
like to know it is damaged before you go to the trouble of calculating the
signature. It also lets you detect attacks where someone damages a
signature packet, or changes unhashed data in it. These are all reasons for
MICing data, do we want to lose this property?
There's a compromise solution here, which is to make a separate packet type
for MICing -- I forget who suggested this -- but if you're going to hash
the whole packet, not just its contents, then you lose the
ease-of-implementation benefit.
> I confess that personally, I also question the wisdom of separating
> them. Especially if it requires a shared key.
What shared key? PRZ proposed SHA1 not a keyed MAC.
You suggested a shared public key. Sorry, I find that a kluge. If we're
willing to live with a MIC-signature that has only a hash in it, that's
fine. But using a universal public key makes me wince.
I'd like to see discussion of the points I laid out above. When I look at
them, it seems to me that the integrated packet is the best solution. Feel
free to change my mind on it.
Jon