From: danisch@ira.uka.de (Hadmut Danisch)
Date: Wed, 11 Oct 95 12:49:24 PDT
To: cypherpunks@toad.com
Subject: Re: Certificate proposal
Message-ID: <9510111948.AA00815@elysion.eiss.ira.uka.de>
MIME-Version: 1.0
Content-Type: text/plain


I was busy in the last days and didn't keep track of the certificate
discussion. I just read most of the discussion all at once. 

- There was some discussion about the bindings between the key and the
  real world attributes of the key owner.

  Under normal circumstances communication never happens without an
  originator. If the originator uses some kind of security feature, he
  normally doesn't do it just for fun. He uses it as a tool to give
  the communication certain properties.

  Authenticity and confidentiality don't make sense without knowing
  anything about the key owners. There is no use in having a signature
  as long as you don't know anything about the signator. And there is
  no use in encrypting messages as long as you don't know anything
  about the receiver. 

  A digital signature is only the way to say who wrote the
  message. "Knowing the author" is the sense of the signature, not just
  having the signature. "Knowing" means know enough attributes about
  him. Same with encryption.

  Knowledge of the author may, of course, be quite bizarre, as well as
  the author itself. But security is always in context of some
  knowledge about the other side. 

  It doesn't make much sense to communicate with a
  "smith@somewhere.edu", because this is not enough information to get
  sufficient knowledge of the key owner. There are a lot of people
  named smith being able to legally have this address. And it doesn't
  make sense to communicate with Bob, "Bob" or ISP+Bob, as long as the
  name Bob is not sufficient to provide enough information.

  I need to be able to get any knowledge about the key owner that
  could be a reason to be interested in communicating with him. I
  do not want to talk with bob because he is one of many Bobs. I want
  to talk with him because he is the Bob with phone number 123, red
  hair and living in XY street. 

  Therefore, a certificate must be able to provide any information
  that could be required for the decision whether the key owner will
  be accepted as a communication partner.

  Obviously, the informations depend on the nature of the key owner
  (human, machine, committee etc.)

- Under normal circumstances communication has an originator and
  in most cases an addressee. If you can talk to an addressee, you usually
  have some kind of address to locate him. But perhaps you don't have
  more than the address, not even a public key. Thus the address to
  communicate should also be good to locate the public key of the
  addressee (or the keys of all key owners listening on that address).

  Therefore, the communication address should be enough to locate a
  key server and to retrieve the key (or a small number of possible
  keys) for that address. After retrieving the keys, the originator of
  communication can decide whether there is a key sufficiently
  identifying his communication partner.

  Consequently, the key certificate should contain the communication
  address of the owner. It is helpfull if the address is unique.

  For a human this may be the email address. For a machine it may be
  the DNS host name or the internet adress. For a service (WWW-site)
  or an organization it may be the email address.

  The communication address must allow to locate the key server. The
  only existing infrastructure allowing this in internet is the
  DNS. If you have an email address, hostname or IP address, you can
  find the appropriate DNS server. The server should be able to help
  you. Best way to do this is to provide the address of a key
  retrieval system (similar to the MX record).

  Use the communication address of the key owner as a searchable index
  for the key.

  Inventing a MD5 hash sum as key index is useless and doesn't make
  sense in my eyes. It just creates the problem of knowing the index
  and typo errors.

- A MITM between two communication partners can be avoided by
  apropriate protocols as long as there is a sufficient key management
  structure.

- A MITM between a key owner and the certification authority is a
  problem, but a solvable one.

  I don't like the separation of creating the key and attaching
  attributes. The MITM can attack between. There is always the
  problem of managing all attached attributes. When the first
  attribute is attached to the key, the key doesn't have any other
  attributes. This make it vulnerable.

  It is better to combine the key and its attributes _before_ creation of the
  key. If the attributes are not attached, but an essential part of
  the key, there is no hole for the MITM. If key and certification are
  two things, there is the problem of bringing them
  together. Self-certified keys don't have this problem. (RFC 1824)

- There is also question whether the key attributes can be trusted to
  describe the real key owner well enough. This implies that someone
  must check the attributes and participate in attaching the attribute
  or creating the self-certified key. PGP uses key signatures to do
  so, but there is not much information attached, just
  name/e-mail-address. 

  As said before there might be interest in describing the key owner
  in other ways. The authority signing the key must be able to check
  the description of the key owner. An unorganized web of trust (trust
  in what? signator knows key owner?) isn't suitable. One reason is
  that there is much too much overhead in finding a path of trust in
  the web and storing or retrieving the keys while searching for the
  path.

  There must be a systematic, hierarchical organization of authorities
  which check the key attributes. (We call them SKIA : Secure Key
  Issuing Authority, see RFC 1824).



So I would suggest the following:

We create a hierarchy of SKIAs able to check certain
attributes. E.g. hostnames and IP addresses might be checked by the
same authorities which allow to use them. 

Key attributes are a composition of the communication addresses of the
key owner and his natural attributes a communication partner might be
interested in while identifying the peer. 

Key owner and SKIA create a combination of key and attributes.

The key owner deposits his key on all key servers responsible for his
comm. addresses.

If you communicate with someone known at least by his communication
address (otherwise you couldn't communicate), you can easily retrieve
all possible public keys of all key owners able to use this
address. Now you can decide and choose the key with appropriate
attributes (bank account number or whatever).

Any comments?

Hadmut