One of my principal objections to the current MIME-PEM
proposal is that it has the flavor of "there is a baisc capability to
do a wide range of things; we have defined one example; other examples
may come along 9or we may already have them in mind but we aren't
telling you) and we'll figure out what the semantics is when we get
there (or when we decide to tell you)." The idea that the semantics
of multiple signatures applied to an object is up to the recipient
stikes me as complete foolishness! The signer(s) should have a means
of expressing the sematics to verifiers in an unabmiguous fashion, so
that two different verifiers don't interpret the signatures
differently.
I find it nothing short of amazing that the person who wrote this and the
person who approvied the classic PEM specifications (RFC1421 in particular)
could be one and the same.
Let's stop for a moment and take a look at some of the services classic PEM
provides:
(1) Nesting. You can sign something more than once. You can also sign and
then encrypt/sign, or encrypt/sign and then sign, to as many levels as
you want. This is specifically detailed in RFC1421, and the only
limitation on this imposed by RFC1421 is that recognition of nested
classic PEM entities need not be "automatic" (section 4.4).
(2) Multiple secured objects presented parallel. A single message can contain
more than one secured object. Moreover, different objects in the same
message can be secured in different ways (section 4.1.2.1).
(3) Multiple signatures. While no explicit multiple signature mechanism is
provided, the ability to have multiple secured objects in parallel can
easily be used to effect multiple signatures, simply by repeating the
same object with different signatures on each copy.
The semantics of these uses of classic PEM are not discussed in the
published RFCs, as far as I can tell.
Now let's take a look at MIME/PEM. One of the major changes introduced by
MIME/PEM is that things can only be secured at structural message boundaries --
you either sign atomic parts or structured collections of atomic parts. We did
have one proposal to enhance MIME/PEM to allow for signing of unstructured
collections of parts, but nobody thus far has suggested that signatures could
be applied to sections of parts or anything along the lines of what classic PEM
allows.
As such, MIME/PEM actually *restricts* the services classic PEM provides and
forces them to operate along existing structural boundaries, boundaries where
various sorts of semantic information can be included, and in fact various
sorts of semantics information have already been defined as part of the MIME
work. MIME/PEM is in fact more structured, better defined, less flexible, and
hence a much less sematically ambiguous facility than classic PEM.
It is hard to overstate the importance of this. For one thing, a signifcant
portion of the difficulty in implementing classic PEM arises from its almost
complete lack of structural alignment with existing message encapsulation
schemes. (RFC1421 talks a bit about RFC934, but RFC934 is not a standard scheme
and is only used in practice for message digest services.)
When implementing classic PEM in real-world email, you have to account for all
sorts of possible usage scenarios:
(1) You can't really treat separate security objects within the same message
as truly separate parts, since the semantics of multiple objects in the
same message are undefined and hence arbitary. They may be "connected" to
each other somehow. This is a non-issue for MIME/PEM, in that MIME
provides the necessary semantics through its various subtypes of multipart.
However, it isn't clear which of the MIME multipart semantic schems you
should associate with classic PEM, assuming that there's even one that fits!
(2) Similarly, classic PEM's nesting model effectively provides essentially
the same services as MIME/PEM does but without proper labelling to what
what's going on.
For example, you can implement MIME/PEM's "sign then encrypt" model by
signing with your own key and then nesting this signed object inside of a
signed-and-encypted object where the encryption is done with the
recipient's key and the signature is done with a previously published
anonymous certificate whose private key has also been published. But in the
case of MIME/PEM the labels clearly tell you what's going on, whereas in
classic PEM case you don't have any labelling to tell you, and the
wiggling done to perform this particular operation (one I suspect will be
very popular indeed) within the confines of the framework of the standard
isn't at all obvious to the software.
(3) Mixtures of classic PEM with other mesage encapsulation formats leads to
truly horrific problems. For example, a MIME-unaware PEM timestamper
will end up putting its signatures of multipart MIME messages into the
multipart preamble area. But a MIME-aware one (that follows, say,
Jeff Schiller's proposal for PEM integration into MIME) would place the
signature one level down.
The net result is that classic PEM ends up getting used at multiple,
overlapping levels within MIME messages. Dealing with this is incredibly
nasty at a syntactic level, to say nothing of the semantic problems it
causes.
And this is just for MIME messages. I'll leave the extension of this
examination to non-MIME encapsulation formats like RFC1154 as an
exercise for the reader -- frankly, I get kind of sick when I'm forced
to contemplate this stuff.
(4) Given the need to provide for multiple signatures at the same level,
the facilities to accomodate this in the classic PEM scheme are very
complex, especially if you decide that you want to implement partial
overlaps. By contrast, MIME/PEM provides such a simple facility when the
two signatures apply to exactly the same thing that it should
effectively discourage people from exploring the use of partial
overlaps between signed documents. (The semantics of partially overlapping
signatures are so subtle and complex that I doubt that they could ever
be successfully conveyed to the average user.)
These factors contribute significantly to the complexity and difficulty of
implementing classic PEM in real-world email systems. And please don't tell me
that I'm stretching classic PEM beyond its design goals here -- much of this is
not only discussed but explicitly condoned in RFC1421.
Now, it is undeniably true that the MIME/PEM specifications are lacking in
discussion of the semantics of very elaborate uses of these sorts of services.
But given the fact that classic PEM has even more of these issues to deal with
and addressed none of them, I don't see how this can be construed as a
legitimate reason for blocking MIME/PEM's advancement to the same status that
classic PEM currently enjoys. If this really is so important that we must
address it now the Working Group should take immediate steps to strip proposed
standard status from RFC1421-RFC1424 until this can be fixed there as well.
Ned