message/signed would be also be a multipart type ("boundary" defined in
the usual mime way) the first part would be a message the rest of the
parts would be signatures. This would facilitate multiple signers on a
single message.
I must admit that this is a new functionality. But note that PEM itself
does not support this functionality and perhaps it should be expanded
to, independently of MIME.
You can actually do this with the mechanisms provided by the current I-D. The
first person creates the message and applies MIC-ONLY PEM to it. The result is
a multipart/pem. The second person reads it, approves of it (either with or
without comment). He then creates a new message, containing the signed original
as a subpart, and MIC-ONLY PEMs that. Presto -- two signatures. This can be
repeated as often as necessary.
Of course it is important in this scenario that each added signature covers the
previous one, lest someone pry the message apart and attach your MIC-ONLY
PEM'ed approval part to some other separately authenticated original (perhaps
an old message sent previously that you didn't approve!).
Alternately, references to Content-Ids and/or Message-Ids can be used to
produce a secure cross reference between parts. This eliminates the need to
wrap the MIC-ONLY applications of PEM around each other if you're careful to
make sure that it isn't possible for someone to just generate another message
with the same Message-ID or Content-ID. In other words, the price you pay for
separating the contents and using cross-references is the need to be able to
verify all the signatures concurrently. If people are serious about doing this
sort of thing we'll probably need to write an informational document on how to
do it.
If we pursue this much further we'll have to make the transition to another
area -- what I like to call Electronic Routing and Authorization. In brief,
this is the notion of taking a document and routing it to a defined set of
individuals who then "sign off" on it. Once a document completes its defined
routing circuit it is handed off to some final destination (and usually a copy
is returned to the originator). Software that does this stuff also has to be
capable of dealing with both serial (everyone gets it in order), parallel
(everyone gets it simultaneously), and mixed routing, automatic retries, dead
address skipping, failovers, vote tallying and a bunch of other stuff. The ugly
part is that some extensions (the sign-off stuff) are a virtual necessity at
the user agent level.
Needless to say, PEM can potentially help make ERA systems work a lot better,
since it provides the authentication services that constitute a necessary part
of such services.
Currently there are a couple of products on the market that provide this type
of service (I acted as consultant to a company that built one of them; they now
use some of our products to provide the infrastructure for running their ERA
server). Their idea of authentication, however, is a sick joke compared to PEM.
But despite my own misgivings about how secure these services really are,
reports I've heard from MIS managers have been amazingly positive. I vividly
recall listening to a talk about the deployment of ERA services in a bank for
handling loan approvals, where the time taken to get everyone signed off on a
loan application was cut in half and the resultant increase in income to the
bank (because it was able to approve loan applications much more quickly than
competing institutions) was subsequently measured in the 10s of millions of
pounds. (Regrettably, this was someone else's product.)
ERA services are very very exciting stuff, and I'd love to see some IETF
activity in this area -- there is a total lack of standardization that makes it
practically impossible to build interoperable ERA software. If this is the
right group for it, let's go for it! If not, maybe we should consider pursuing
this elsewhere.
Ned