pem-dev
[Top] [All Lists]

Re: limitations of mime-pem transformation

1994-12-14 15:55:00

Ned,

I apologize for the unfortunate wording with respect to "validation".
I did not want to state that solving the general
signature/structure/semantics question was necessary in order to
proceed with the MIME-PEM baseline.  My intent was to begin discussion
of richer semantics that I believe (and expect to debate) are needed
for general object protection and which might be conveyed in a related
base construct.  As I stated, I hope this to be complementary to the
real, near-term needs of PEM deployment and infrastructure
flexibility; not a prerequisite.

Your previous message raised several points which I want to address
separately.

Dave

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.

I have no problem whatsoever with trying to define structurs to specify
signature intent. However, I have a MAJOR problem with tying this to the
"validation of the base protocol". It is a separate matter, and moreover one
that can only be done in a meaningful way once the base protocol is in place.

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 have already commented on this in my previous response.

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.

I am in complete agreement with the idea that this is complementary to the
core PEM discussion. However, I cannot reconcile your assement that this is
necessary to validate the base protocol with the idea that the two things
are complementary.

                              Ned

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