[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>

Micheal, I now understand what this list is about. I will make the point
that when you as a co chair and the chair of a list put a document into
the public domain, which has major illogical and misleading content then
be prepared for the comments. Particularly when you denegrate an
essential technology which is being deployed globally. If you think
document is of good quality, good reasoning and good engineering which
includes operational pragmatism , that is your view. Its not mine.

Theory is about religion, Engineering is about reality.


From: Michael C. Richardson
To: Alan Lloyd
Cc: spki@c2.org
Sent: 7/27/98 9:35:14 AM
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt> 

>>>>> "Alan" == Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> writes:
    Alan>  Let me explain something to this list which seems to be
totally missed.

    Alan> A certficate is a digital form of ones key, ones identity and
    Alan> privileges within a domain as defined by the key issuer of
    Alan> domain.

  That is an X.500-type definition.

  [I refrain from calling it an X.509v3-type definition since I know
X.509v3 has gotten over this as well.]

  SPKI rejects the X.500-type definition and says that a certificate is
something authorizes some verifier defined action. The exact text is
(from cert-req-01.txt)


   The term certificate traces back to the MIT bachelor's thesis of
   Loren M. Kohnfelder [KOHN].  Kohnfelder, in turn, was responding to a
   suggestion by Diffie and Hellman in their seminal paper [DH].  Diffie
   and Hellman noted that with true public key cryptography, one no
   longer needs a secure channel over which to transmit secret keys
   between communicants.  Instead, one can publish a modified telephone
   book -- one with public keys in place of telephone numbers.  Diffie
   and Hellman went on to propose that such a directory could be on-line
   and maintained by a trusted source.  One could then look up his or
   her desired communication partner in the directory, find that
   person's public key and open a secure channel to that person.
   Kohnfelder took that suggestion and noted that an on-line service has
   the disadvantage of being a performance bottleneck.  To replace it,
   he proposed creation of digitally signed directory entries which he
   called certificates.  In the time since 1978, the term certificate
   has frequently been assumed to mean a binding between name and key.

   The SPKI team directly addressed the issue of <name,key> bindings and
   realized that such certificates are of extremely limited use for
   trust management.  A keyholder's name is one attribute of the
   keyholder, but as can be seen in the list of needs in this document,
   a person's name is rarely of security interest.  A user of a
   certificate needs to know whether a given keyholder has been granted
   some specific authorization.

  If you don't accept this point, then SPKI isn't for you, end of

   :!mcr!:            |  Network and security consulting/contract
   Michael Richardson |         Firewalls, TCP/IP and Unix
 Personal: <A
ml">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A
	ON HUMILITY: To err is human, to moo bovine.