pem-dev
[Top] [All Lists]

Re: limitations of mime-pem transformation

1994-12-14 09:47:00

Steve,

Date:    Wed, 14 Dec 94 10:22:22 EST
From:    Steve Crocker <crocker(_at_)cybercash(_dot_)com>
Subject: Re: limitations of mime-pem transformation

Dave,

The general subject of multiple signatures in MIME-PEM has not been fleshed
out completely, but I can relay a couple of thoughts.

1. It ought to be possible to have multiple signatures within the signature
body without extra encapsulation.  The syntax needs to be examined to make
sure this is possible, but there's no reason, in principle, why the sender
cannot put more than one signature to the signature section.

2. The semantics of multiple signatures is not defined.  It might mean:

2a. Two people both approved and vouch for the document.

2b. One person signed with two forms of signature, e.g. a DSS and a RSA
signature, to facilitate acceptance by a wide range of recipients.

2c. Something yet different.

However, I think it is perfectly acceptable to leave the meaning of
multiple signatures up to the recipient.

I disagree with this statement.  I think a general solution for
signature handling of objects/messages must allow a user to
unambiguously assert the meaning of signatures applied to collections
of information and other signatures.  This is particularly 
important if mime-pem is to serve as a building block for protected
objects.

In light of Jim's comment on flexibility for multipart signature
and your comments above, I think it is useful to explore defining
(or exploring the ability to define) other unambiguous structures
which represent signature intent.  The ability to do so is, I
believe, an essential element in validating the base proposal.

The other architectural issue, which may more properly belong in the
MIME discussion forum, is the need/ability to uniquely identify
objects/parts/messages and to explicitly indicate such linkages in a
candidate alternative signature structure.

I think this topic is largely complementary to the core pem discussion
and may move to an object security discussion, but I believe the
utility of the basic approach can be enhanced if we all agree
on common, unambiguous ways to representy common semantics.


Steve

--------------------
Steve Crocker
CyberCash, Inc.                                  Work:  +1 703 620 1222
2086 Hunters Crest Way                           Fax:   +1 703 391 2651
Vienna, VA 22181                                  
crocker(_at_)cybercash(_dot_)com


Dave

<Prev in Thread] Current Thread [Next in Thread>