The idea that the semantics of multiple signatures applied to an object
is up to the recipient stikes me as complete foolishness!
If you can explain how to unamiguously denote the semantics of any signature,
digital or not, I'm all ears. My current understanding, which includes a
certain degree of background in semantics, semiotics and discourse modelling,
leads me to believe that this is impossible to achieve, and that the semantics
of any communication depends on the context in which that communication
occurs.
To a large degree, in fact, it depends on the contents of the article being
signed (just as does a paper document, wherein multiple signatures may denote
any number of different sets of semantics depending on the context and
contents).
Amanda Walker
InterCon Systems Corporation
I was trying to stay current, but I took a couple of days to enjoy the holidays
and missed throwing a pie or two myself during this food fight.:-) I sympathize
with Steve Kent's problem of trying to catch up the last several weeks all at
once.
I have to swallow hard, but I tend to agree with Amanda. A couple of comments:
1. Although PKCS (as I recall) includes some rudimentary notion of trying to
explain what is meant by a signature, i.e., why the object was signed, PEM does
not. It also doesn't include a timestamp (trusted or otherwise), an
identification of the machine that was used to apply the signature, or a number
of other potentially useful facts that could have been included within the
signature block with no additional overhead. That's unfortuantely, IMHO, but
probably not fatal.
2. Both X9 and X12 have worked on trying to supply computer readable codes that
would attempt to explicate the meaning or intent of a signature. I haven't
reviewed them in depth or recently, but I strongly suspect that they may
satisfy one particular subgroup's interest (e.g., banking) and completely fail
another (e.g., secure distribution of trusted software.)
3. When I looked at this problem several years ago, in the early DMS days, we
tried to differentiate between signatures that said: "This is just a first
draft," or "I concur with the attached," or "I nonconcur with the attached," or
"I don't really like this, but I don't have the time or interest to outline my
objections more completely." We gave up trying to enumerate all those reasons
("meanings") for a signature, and suggested that a buck slip or attachment be
provided, where those thoughts would be spelled out in English.
4. The situation becomes much worse with respect to sound files, JPEG images,
etc., unless some kind of an overarching attachment is provided to explain what
is going on. (The sound file or JPEG image, etc., need not be separately
signed, in this case, but there may be some merit in signing an object as close
as possible to its representation in digital form, from the standpoint of
limiting the amount of code that must be trusted in both the orginator';s and
recipient's processors.)
5. It was certainly my understanding of classic PEM that it did in fact allow
multiple users to sign a given object, with or perhaps without some additional
explanatory material. Otherwise, implementation of true nonrepudiation would be
very difficult, for there would be no way for a trusted third party to either
confirm that a user's certificate was valid as of the time a document was first
presented, or to independently provide a trusted postmark (loosely and
inaccurately called notarization.)
We would all like to have a perfectly unambiguous way of specifying these
things, both syntactically and semantically, but this would seem to be a _very_
long way away, and we'd better use a natural language until that time. In the
meantime, the PEM/MIME spec does appear to provide a substantially richer set
of tooks to use to describe the relationship between and among labelled
objects, up to and including the creation of new types of documents, and this
would appear to be a substantial advance.
(Momentary non sequitur -- would/does MIME support the notion of a hypertext
document, where the relationship between the parts doesn't change, but the
contents of one of the parts might? One of the problems that I have with some
of the existing products on the market (I won't slander anyone by name) is that
they digitally sign the variable fields of a standard form, but don't protect
against changes to the form itself. A MIME document could potentially include a
standard form (signed by its creator), the signed variables fields document,
and a signed enclosure form which binds them all together. Is this
possible/supported within the current PEM/MIME spec?)
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM