The invention of public key crypto promised a new era of convenient secure communications.
The mathematical properties of the public key were very surprising and very powerful.
The publicly known key for a person would suffice to encrypt mail for that person so that only he could read it, that is if he has kept his private key and kept it a secret.
Similarly anyone can verify signatures that people with public keys may have affixed to their writings, signatures that only the secret key can produce.
Anyone can generate secret keys and publish the corresponding public key to the world while the secret key lets them decode mail to them and sign what they choose.
Yet we hear from all sides that “PKI”, Public Key Infrastructure, is in great turmoil.
PKI is that great public data base from which you learn the public key of the person with whom you wish to communicate.
Organizing and protecting that data base seems to be as problematical as organizing and protecting people themselves.
Plans to provide this service have provoked controversy unfamiliar to those who design protocols.
I think that the main problems are these:
As you can see with questions like these, there may never be a consensus on how to manage public keys.
- What’s in a name?
- What is the nature of trust?
- How are communications paths established within organizations?
The idea of public keys is simple enough as introduced in the first two paragraphs.
Yet it seemed necessary to put a user friendly veneer over it to make it truly useful.
It is the nature of this veneer that has caused the controversy.
The Certificate Paradigm
An early idea following the public key invention is a certificate binding a public key PK to a person.
The certificate is signed with a public key that is hopefully already known.
Some institution can make a living producing such certificates.
Learning the public key of that institution then may supplant learning many public keys.
A signed document may then be accompanied with a certificate for the key with which it was signed.
A poorly guarded data base can hold public keys and its users can be confident that the public keys it gets there are valid, if the CA is trusted.
At first this idea sounded perfect.
What could go wrong with such an idea?
Much but not all of the work on PKI has ignored the problem of linking people to names.
They have largely said that that linkage is a separate problem best not confused with the technical problems of PKI.
Splitting problems into smaller pieces is a good technique.
Some think that that particular split is wrong however.
Another problem is who runs the public data base or bases?
Is someone responsible for keeping person x from submitting a data base entry claiming that company A’s public key is Px, thereby gaining access to confidential information intended for company A?
When we send messages to some particular person and no one else, we evidence some sort of trust in that person, but trust is far from a simple binary relationship.
It is fuzzy at best and most probably expressed partly in our genes.
Several PKI systems seem to provide function based on simplistic trust models.
I have seen none that comes close to matching my intuitions.
If I work for an enterprise E and deal in secrets of E then I will most likely willingly take instructions from E about
who is privy to those secrets.
In such cases I am introduced by my contacts in E to yet other contacts within E and instructed what information they are privy to.
Many employed by E will deal with agencies outside E and again trust those agencies as directed by E.
In such cases it is natural for E to provide a PKI as it is they who determine who my contacts will be concerning E’s secrets.
National governments largely follow such schemes at least in theory.
It is sometimes assumed, unconsciously I think, that the ultimate purpose of public keys is for legal recourse in case of default.
This model suggests that a public key certificate should include information that you might put on a subpoena or arrest warrant.
This is only one use.
Many public key uses do not require this.
It is sometimes assumed that a public key is to be bound to just a person.
It may instead be bound to a person’s role or to a role filled by different people at different times, or indeed to a role filled by a machine.
I may want to send tax information to my accountant under a different key than I would use to send a party invitation to the same
I see a certificate in the Netscape browser “Equifax Secure Certificate Authority”.
The text æUS” suggests that it is located in the United States.
AltaVista is ignorant of that name.
There is no street address of phone number listed.
The default is to trust software signed by keys in certificates rooted there.
Right off the bat here are two problems:
- A computer data base can only link public keys to names and not to people.
- The public directory may itself be compromised for nefarious ends.
See this for similar thoughts.