pem-dev
[Top] [All Lists]

(PGP vs. (PEM vs. PEM-MIME)) vs. WEB

1994-12-14 05:47:00

Ali Bahreman wrote:

What both PEM and PGP users need is a good user interface.  If e-mail
is the application of choice to add security to, then integrate PEM
or PGP to all mailers, but until you do that, I don't think you will
get a serious sized user base....

I  think this is an important point, the main reason why PEM
(and  also PGP) are not so widely used. I hope that examples
bellow will not turn out as over-simplified ones.


Case  #1:
Suppose  we have a GM car and a Toyota car. Would you  as  a
user  mind if Toyota uses one (redundant) chip more for  its
air-bag   system   than  GM?  As  long   as   both   provide
functionality,   required   by   state   and   international
regulations,  you won' t care. It is Toyota'  s  problem  if
their air-bag system costs them more... Similarly, when  you
buy  a  ticket  from air-company, you don'  t  care  if  the
aircraft  you' ll fly is a Boeing or AirBus.  All  that  you
care of is your seat, friendly on-board service, etc., which
all represent your "user agent" in this case.

So  I  think  that a real problem of PEM is  a  lack  of  an
appropriate user agent and other supporting tools that would
basically  do  the  following (let's assume  use  of  X.500,
although it might be any other data-base system):

*     With a click on button a certificate of another  party
would be retrieved.
*     With a click on another button this certificate  would
be checked (could be CA-Browser :-)).
*     With  a click on a third button, a signature could  be
produced and a reply sent out.

In  this  case, the user will not care if there  is  a  very
complex  X.500  system  and a complex  CA-structure  in  the
background. As long as all these systems work in  line  with
certain  standards  and  state  regulations  (which  can  be
checked, if required), everything is OK.


Case #2:
Let'  s move now from users' point of view to the public-key
infrastructure implementation. Regarding technical  aspects,
it  is almost the same whether public-key infrastructure  is
hierarchical or "flat". But if you provide a CA service  and
your  service  vitally  depends on another  party  that  has
nothing to do with certification matters, it is pretty tough
job  (this  is  the case in PEM CA-model used  within  X.500
because  of  mixing  certification  hierarchy  with   naming
hierarchy). Next, having an opportunity to be IPRA and  thus
having a monopoly is quite interesting if you are the  lucky
one who operates it and makes money with this job. But it is
not  very  pleasant fact for the rest 99.999...% of Internet
community.


Conclusion.
It  is  not a technical problem that PEM (and also PGP)  are
not  widely  used (read as "used for commercial  purposes").
Both  problems have common root and this is *the  nature  of
human reasoning*. As I am a technician, I would say that the
reasons for the problems may fall in the area of psychology,
management of human resources, etc.


Solution:
I would suggest to:

*    relax current PEM CA-hierarchy model to the minimum;
*    define additional supporting systems to support  users
when using secure services so they can just  push buttons on
their user-agents.

Again and again I am thinking of a genius idea of DNS, where
name space is completely separated from IP numbers, and both
are  separated from physical address space. This all remains
hidden  to  users  and this is what we should  achieve  with
public-key infrastructure.

I  wish you a successful work and sorry if I have taken  too
much of your time.


Best regards,
Denis
************************************************************* ************
* Denis Trcek                                       O O      * *         *
* "Jozef Stefan" Institute                        O O         * *        *
* Jamova 39, 61 111 Ljubljana, SLOVENIA           O   O        * *       *
* e-mail: denis(_dot_)trcek(_at_)e5(_dot_)ijs(_dot_)si 
denis(_dot_)trcek(_at_)ijs(_dot_)si  O           * *      *
* Tel.:+386 61 1259 199, Fax:+386 61 1261 029, +386 61 273 677   * *     *
******************************************************************* ******

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