pem-dev
[Top] [All Lists]

Re: PEM vs WEB - Actually Common Security Encapsulation vs WEB

1994-12-13 15:55:00

Dave,

Date:    Tue, 13 Dec 94 12:52:14 PST
From:    Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
Subject: Re: PEM vs WEB - Actually Common Security Encapsulation vs WEB

1.  Web vs. PEM.

What a strange basis for a confrontation.  PEM does assert that it is for
messaging.  But messaging and the Web have both been moving towards use of
Mime.  (Reference to the various protocols other than HTTP/HTML as 'The
Web' is of course academically reasonable, but not helpful for these
protocol discussions.  The Web is HTTP/HTML in terms of special protocol
definition.  After that, it is a user-process integration of a collection
of independent, pre-existing protocols.  That's useful, not in the purview
of a protocol standards effort.)

Either we believe Mime is a reasonable, common wrapping technique, or we
don't.  It happens that I do, for most Web and messaging circumstances.  If
we do believe it's reasonable, then we should seek to define and deploy as
much commonality of mechanism as possible.  PEM, PGP, etc. are all oriented
towards object (rather than transport) security.  Again, I think that that
is just the right model, for most circumstances.

One of the areas I believe requires further discussion is the
distinction between general object protection and message protection.
There are certainly a large set of common security services and
requirements and it a common wrapping technique should be desirable
and reasonable.  If MIME, or any other candidate, is the choice for
that common wrapping technique, then it needs to be examined in the
context of requirements for general protected objects.  I think that a
messaging environment is somewhat constrained in terms of access (and
access control) and information handling.

Some areas which I believe warrant additional consideration are:

1) the ways in which information is accessed, the access control
policies to be enforced, and the resulting access
control/authorization/labeling information which should be associated
with an object.  Also, how that control information is bound to the
object, whether it is, itself, protected, etc.

2) The ability to identify and relate parts/objects, etc.  The ability
to unambiguously reference pieces of information (objects, signatures,
etc) is an important foundation in robustly supporting complex
signature processing in environments where reliance on nesting may
not apply.  For example serial vs. parallel signatures; signatures
sent separately from objects; annotations, etc.

3) The range of non-repudiation/signature scenarios required.  Related
to item 2, it does not seem that we have adequately explored the
spectrum of non-repudiation requirements (with or without third
party services) and considered whether the syntactic facilities we
have are sufficient.

Dave

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