[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certificate proposal
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
"[email protected]", 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
- 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
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
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
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).