Subject: Semantics of having multiple encrypted data packets

From: Andrea Halter <[email-masked]>
Date: Thu, 26 Nov 1998 15:14:38 +0100

To provide for random read/write semantics, we would like to chain
multiple Symmetrically Encrypted Data Packets, each of constant length.
In RFC 2440, this is not listed as one of the message formats.

Therefore, we suppose that our approach is not standards compliant. But
does any of you see a better way to support random access without
re-encrypting the whole message each time? Will other implementations be
able to understand this? Could we even tweak the standard into this
direction (ignoring that we're a few weeks late)?

cu
Andi, Marcel

---

From: [email-masked] (Lutz Donnerhacke)
Date: 26 Nov 1998 14:55:15 GMT

>direction (ignoring that we're a few weeks late)?

IMHO the standard does not forbit such a concatination but it's not
enshured, that every application will understand this. PGP2.6.3 is known to
stop after decrypting the first message.

---

From: Jon Callas <[email-masked]>
Date: Mon, 30 Nov 1998 12:20:04 -0800

At 03:14 PM 11/26/98 +0100, Andrea Halter wrote:
   To provide for random read/write semantics, we would like to chain
   multiple Symmetrically Encrypted Data Packets, each of constant length.
   In RFC 2440, this is not listed as one of the message formats.

Actually, your implementation could easily be 2440-compliant.

I agree 100% with what Lutz said, and I'll expand a little here.

It's permissable in an implementation of an IETF standard to go beyond what
the specification requires. This is how people "add value."

Suppose you make a 2440 implementation, and it handles a message with
multiple encrypted data packets. It's compliant. A 2440-compliant message
will decode correctly. What you've done is merely follow the first half of
the old dictum of "be generous in what you accept and stingy in what you
generate." I

The place to be careful in your implementation is the secont hald of that
dictum -- if you create an enhanced message, a strict 2440 application may
not decode it. It may stop after the first ED packet. (Or it might decode
it -- the other implementer may have quietly handled N ED packets
correctly, too.)

If what you're building is an application that internally makes objects
that are made up of multiple ED packets, and you know that your objects
won't be sent out into the wild like that, no one could possibly complain.

If you *are* sending them out in the wild, there are at least two things
you can do:

(1) have an "export" format that adds ESK packets as headers to each ED
packet. This increases the size, but makes sure a 2440-strict
implementation will decode the chunks. Of course, though, there's a
re-assembly problem, but I'll handwave that.

(2) Only send your "extended" messages to people you know will understand
them. A simple way to do this is to use a notation in the recipient's
self-sig as a way for that person to say they understand your bundled
messages. There may be other ways, and implicit ways for you to know that.

There are also other solutions, like decrypting the entire object and
re-encrypting it into a single ED packet for export. I'll also note that
all of these have security considerations and wave my hand.

The upshot is that there is nothing in the standard that says you can't go
off on a limb and make an application that understands 2440 and does a
whole lot more. Just don't get huffy if no one else does your enhancements
-- or does them in a slightly different way.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)