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