DGA

DGA

Software systems development and support

A Heretic's view of Certificates

Users/Developers If you would like further details, a visit from DGA to discuss this in greater detail or to enquire about DGA security consultancy services, please look at our Web site, www.DGA.co.uk/Cred or contact us

Abstract
This paper questions the assumption that X.509 Hierarchical Certificates are the best (only) way to organise Business to Business Trust for eCommerce.

It introduces the basic question which has formed the basis of Commercial Trust for around 200 years, and asks whether the X.509 model can answer it.

Assuming X.509 is not the only model, it looks at whether a different model can provide a better, alternative, answer.

It looks at the traditional basis of Business Trust, and presents an electronic model that more closely matches that traditional model.

1. The Heresy
There is an assumption that the only sensible way to engender business trust electronically is through a Public Key Infrastructure (PKI) based on Hierarchical X.509 Certificates. Unfortunately this technology does not address the underlying business questions upon which traditional trust models have been built. It leaves the decision as to which Certificates can be accepted to the end user with no common standards on which they can base their judgement.

I am not the first to question this assumption In a paper written by Carl Ellison and Bruce Schneier for the Computer Security Journal Volume XVI, Number 1, 2000 called "Ten Risks of PKI: What you are not being told about Public Key Infrastructure" - their ten risks were identified as:-

1. Whom do we trust, and for what?
2. Who is using my key?
3. How secure is the verifying computer?
4. Which John Robinson is he?
5. Is the Certification Authority (CA) an authority?
6. Is the user part of the security design?
7. Was it one CA or a CA plus a Registration Authority (RA)?
8. How did the CA identify the Certificate Holder?
9. How secure are the certificate practices?
10. Why are we using the CA process, anyway?

This paper can be found on Bruce Schneier's Web site at www.counterpane.com.

Although their questions are directed at individuals and are specific technology, and mine are directed at businesses , the questions nevertheless cover common concerns.

2. Traditional Business Trust
Traditional Business Trust is based on registration, traceability and legal assignment of responsibility. Although totally insecure in its delivery, much of the traceability is built around the information presented on headed note-paper, and consists of the formal identifiers for the organisation:-
1. Registered Name
2. Registration Number
3. Registered Address
4. Country of Registration (not normally listed, but implicit)
5. Type of organisation (not normally listed, but implicit)

Although headed note-paper is trivial to forge, the business community understands it and uses it as the starting point for tracing the relevant organisation.

At its simplest this trust is based on an insurance principle, in the answer to a very simple question:-
If this transaction goes wrong, whom do I sue?

There is also an assumption that this question can still be asked in several years' time and will still yield a useful answer.

The real question behind this presentation is whether the Hierarchical X.509 Certificate-based PKIs can answer this question, and thus engender the same or better trust than the traditional model.

3. What is our target market?
Before we can identify whether this model works, it would be idea to set the scene of the market that we are looking to satisfy. At the last count (the World Bank in 1998) there were estimated to be aproximately 120 million business organisations around the world. That is, businesses as we would recognise them and not including informal bartering. It does include parts of government and organisations such as Charities, partnerships and sole traders.

Not all of these are currently connected to the Internet, but it would not be sensible to construct a system that assumed that a significant proportion of them would never be connected. We need scalability to that order of businesses.

We are also constrained to take into account all those who get connected around the world, not just those in our localities. The Internet is global and the business trust model needs to be as well. It is often very difficult to find out exactly where an organisation is based when you find them on the Internet, and so producing a system with limited geographic coverage is likely to mislead.

One further point about the target audience is that business organisations are, in law, peers. Some are bigger than others, some are more influential than others but all are equal.

There is also a question about who it is that is actually doing the business. There are special cases where individuals are responsible for particular pieces of information, for example VAT returns. There are also cases where individual members of an organisation are really "trading" on their own behalf, such as Law Partnerships, but most of the time it is one business organisation which is trading with another, and the identification of the individuals involved is merely to aid the tracing of the audit trail.

4. What does an X.509 Certificate tell us?
At its simplest, an X.509 certificate ties together a name and a public key, and tells us who has confirmed the link. This name is typically an IT name of one form or another, and can be a compound object which could contain the business information noted above. Other attributes can also be included in the Certificate, and later versions of the X.509 standard are including logical business attributes such as buying and signature authority.

The certificate also tells the recipient when this was issued and, in the absence of any other notification, when this certificate expires. The other notification would either be a new certificate or a revocation.

The public key in the certificate can either be an encryption key, which we use in the knowledge that only the corresponding private key will be able to decrypt the message, or a signature key which we can use to validate a signature signed with the corresponding private key. In some systems the key can be both an encryption and a signature key, but this is frowned upon in cryptographic circles, and will be extremely dangerous if the Regulation of Investigatory Powers Bill which is currently going through the House of Commons becomes law in its present form. The assumption is that the named entity owns the private key that corresponds to this public key, and the assurance is the trust that you have in the certifier.

Typically such Certificates are organised in a hierarchy, so as an employee of an organisation I will have a certificate signed by my organisation, which has a certificate signed by some local agent of a global certificate provider, which in turn has a certificate signed by the global provider. All the certificates higher up in the tree will be present as collateral material in my certificate. Thus, two employees of the same organisation will only go up the tree as far as their organisation to validate the certificate, while those who use the same local agent will stop at its certificate, and the rest will go to the top of the tree. That would be fine if there was just one tree, but in practice there are several independent trees. Organisations such as the European Electronic Messaging Association (EEMA) have brought a forum of Certification Authorities together (ECAF) and it is encouraging cross-certification, so that each root CA holds certificates from other root CAs, and thus cross-tree trust can be derived.

An important part of this process is Revocation. This allows a certificate to be cancelled, but requires that each time you come to check a certificate you check the list of revocations. It is claimed that this is actually quite simple, but given the number of organisations in the world, if each issued one revocation per year they would be flowing around the network at a rate of about one per second all year around. Checking revocations works well in situations where there are a very few places, such as a client-server environment, when all the checking happens at the servers, but does not work well when there are many such places, such as peer environments.

Implicit in the assumption that the key and the name are properly connected is some notion of a Security Policy. There are many ways in which certificates could be handed out, from the totally open to the totally paranoid. Again however, the Certificate does not tell you anything much about how this was done. It is therefore necessary to find out the Policy of the issuing organisation so that you can judge the level of trust that you can place in it. There are attempts to produce model policies for organisations to implement, and organisations such as ECAF are working in this area. The biggest difficulty here is that it is left to the end users to decide whether a certificate can be trusted, and they have little or no information to go on in order to make that judgement.

Certificates are very easy to produce, anyone can produce them and lots of software packages exist to reduce this to a simple administrative process. The signature strength of what the US software industry likes to call "International" version of their systems has been restricted in the past, but recently the controls in this area have been relaxed and much more secure systems are now becoming available. Obviously, getting your certificate signed by someone else is difficult unless you match their criteria, but getting a user to accept a root certificate is made much easier by the user's ignorance as to the consequences of doing so. The normal route by which trusted roots are made available to end users is that their Browsers come with the root certificates built in.

5. Does the X.509 model allow the basic question to be answered?
In order for the X.509 model to answer this question the following conditions need to be met:-

1. All certificates issued by the trusted root certifiers and their agents would need to include all the formal business identifiers listed above in a standard form that all could understand or could be checked easily by software,
2. All client software would have to check all certificates for revocation each time the information guaranteed by the certificate was presented to the user,
3. All organisations would have to sign up to a limited list of Security Policies, which would have to be generally visible and comprehensible to end users and the relevant Security Policy would need to be identified in the Certificate,
4. Archives of old Certificates and Revocations, indexed by validity period, would need to be available and readily accessible, so that the Certificates valid at the time of a transaction could be retrieved at a later date,
5. The time at which a transaction occurred would need to be accurately recorded so that the relevant Certificates could be retrieved from the archive. This is relatively easy to do in the case of Web transactions, but is more difficult to do with eMail, as the transaction occurs - to follow the historical paper-based model - at the time that it first enters the receiving organisation, not at the time when it is put in someone's in-tray, and certainly not when they get around to reading it,
6. A properly managed audit trail of the transactions would need to be kept.

Some of these conditions cannot be met, such as the first, because there are already certificates in the field which do not meet this condition. Some are difficult to do, such as the second, because the certificate would need to be checked against the archive (4.) and none of the current protocols for Certificate and Revocation retrieval (such as LDAP) allows for retrieval of anything other than the current Certificate. Security Policies could be put in place but some organisations regard their policies as secret, which makes checking by outsiders impossible. Accurate time-stamps are available on the net but modifying software around the world to use them, and to do the checking at the correct time in the case of eMail, would be difficult to achieve and difficult to enforce given the current protocols; the audit trails have the same problem.

All of this being solved, in spite of the difficulties, there is still the further question of who it is that is signing documents, what that signature means in terms of an enforceable obligation and on whom it is enforceable. This comes back to the point that it is the organisations that are doing the business and should be taking the responsibility.

So the X.509 model does not appear to allow us to implement a system which answers this simple question, and from that we need to ask whether the question is wrong, or whether X.509 is a wonderful technical solution to a class of problems, but not a sufficient weapon to solve the Business to Business trust problem.

6. What is X.509 good for?
There are many circumstances in which an X.509 certificate is a very useful mechanism. These are almost all in those areas where there is a single (or limited number) of central points that need to check the value of a certificate.

The most obvious of these is for access control on a LAN or other such shared resource within an organisation. The termination lists can be maintained centrally, and the certificates issued locally, thus making it trivially easy to administer.

Another area where X.509 certificates are usable is for the distribution of public keys for encryption, provided that they are being checked against an independent signature key. So if the encryption key is signed and provided you have another means of ensuring that the signature key is valid, you can be confident that only the owner of the signature key will be able to read the encrypted material. Essentially this is what goes on under the covers between S/MIME systems when you need to find a public key for a new communications partner, and is also found in such systems as OpenPGP (old PGP worked rather differently).

Within a closed organisation (an island of certification) which is organised as a hierarchy - as most organisations are - certificates can also work well, even for signatures. The needs and rules for identification and trust within organisations are somewhat different, largely because of the controlling hierarchy.

7. An Alternative Model
Given that the X.509 model seems to have a number of significant problems in answering the basic question (and Ellison and Schneier's 10 questions) it is necessary to ask whether a system can be devised that does answer the question directly and in a way that is easy to administer and easy for the end users to use.


THE CREDENTIALS MODEL

a) eMail

In the Credentials model we start by focusing on the organisations. These have the necessary formal business identifiers (their Credentials), and are (generally) the parties to the transactions. The registration information needs to be collected and put into a single data object. Also in this data object are the public keys by which this organisation can be recognised. There are typically several of these:-

1. 1 (or 2) for each proxy server which will be used by the Credentials process,
2. The organisation's Certifier Key

The organisation then looks for a suitable Memorandum of Understanding (MoU) from a list on the Web, which it signs, making it responsible for transactions done in its name - assuming that all the signatures check out - as though they were paper transactions. The identifier of the relevant MoU is then added to the data object.

Credentials may also contain other free-form information such as trading names and addresses, web site addresses and phone numbers etc. They may also include "What" information (see below).

The Credentials and the MoU are then passed to a Credential Holder who validates all the information, as well as verifying that this organisation exists and that the Credentials are being handed over by an authorised representative of the organisation. The Credential Holder gives a copy of its own Credentials to the Client at this time. The exchange should be made by duly authorised representatives of the two organisations; the first time Credentials are exchanged, at least, this should be a physical exchange. If a suitable key is included in the original Credentials, and if it is not a key that has not been compromised, that key can be used to validate updated Credentials in the future, although due diligence on the part of the Holder should obtain independent confirmation that new Credentials are expected.

Once these Credentials are validated the Holder then makes them available to other Holders and to others of their own clients.

If one or more of the keys becomes compromised, then the Holder must place the Credentials on hold until new Credentials can be issued. Putting them into this state is important and time is of the essence. Credentials should also be updated on a regular basis, say once per year.

When you wish to communicate with a taget correspondent, its Credentials are then fetched - always through your own Holder - when they are needed - they are never cached, although the Certifier Key may be held by the receiving organisation so that it can be made available through an LDAP server for internal use until the next time the Credentials are fetched. As the Credentials are always current at the time they are used, and fetching them also generates a time-stamp from the Holder who can be relied upon to operate an accurate clock, revocation checking is not required.

Both Organisations at the ends of a transaction would fetch the other's Credentials for each transaction, so both have a current set. Each fetches from its own Holder.

The request and response fetching the Credentials are always signed; the Holder can thus check that the request comes from one of its own clients and the client can check that the response is genuine. In these signatures there are time-stamps which are used as the audit times of the transaction.

In the case of eMail, all the mail to use this system passes through a proxy server in each organisation (the addresses are included in the Credentials) and this proxy validates any contained Certificates for currency, and then signs the entire SMTP envelope. The mail is then passed to the corresponding proxy which validates the envelope signature, countersigns the envelope and passes the countersignature back to the caller. Both forward and reverse non-repudiation are now established, and accurate audit quality time-stamps have been included. The countersignature is passed back to the originator with the receiver's Credentials and the original mail, along with the envelope signature, the sender's Credentials and the receiving proxy's countersignature, is passed to the recipient (normally as extra MIME parts). All these components are then cut as an audit trail on some write-once medium (WORM drive or writeable CD-ROM) at each end. The Holder also logs the request and, if the information came from another Holder, the Credentials that were returned so that the validating Credentials can be retrieved later. In all cases the time-stamp is used as the key to these logs. This mechanism does not provide encryption, but does provide a trustable mechanism by which encryption keys encoded using X.509 can be exchanged. The user's eMail client and the eMail server are not affected, the latter is merely configured to use an eMail proxy for outgoing mail.

b) Web

For a Web transaction, SSL (type 3) is used to provide client-side and server-side authentication, and the Credentials are used to validate the certificates that are passed within the organisations using LDAP. As with the eMail system, the user's browser is not changed by this system, but is configured to pass external requests through a proxy which does all the fetching and processing of the Credentials. At the Web Server end a security Servlet can handle the relevant details, along with an LDAP server which fetches the Credentials. The proxy and the security Servlet can then handle the logging for the Audit Trail.


8. Does this model answer the question (and the 10 questions)?
As each organisation has an audit log which contains all the transactions (both eMail and Web) which were signed in its name or which it received as signed, along with all the Credentials that were used to identify the parties, and the time-stamps and the countersignature from the Holder, in conjunction with the Holder's audit trail, we would seem to have solved the problem. All the information held by each transacting party is externally verifiable by the information logged by the Holder. So provided the Holder has done its job we should have a trustable system, which can produce convincing evidence several years after the event.

As to Ellison and Schneier's 10 questions:-

1. Whom do we trust, and for what?
   We trust our Holder to do the Credential validation and withdrawal properly and to give us the correct Credentials when we ask. We also expect them to take due care in selecting which other Holders they trust on our behalf to provide Credentials. We then trust the trading partner to honour the MoU which they signed, and to which they can be held in law.
   
2. Who is using my key?
   The private keys held by the proxy machines can be held in secure encryption hardware. They can only be used from the proxy machine with which they are associated in your Credentials.
   
3. How secure is the verifying computer?
   There are several computers but the only ones you need to worry about are the ones under your central control.
   
4. Which John Robinson is he?
   In our case this is a two-part answer. In the case of the organisation, DGA is not the Directors Guild of America, nor the Distressed Gentle-folks Association, it is David Goodenough and Associates Limited, registered in England number 183 5822 etc. In the case of individuals within that organisation, I am David Goodenough according to DGA, which is all the trading party really needs to know.
   
5. Is the Certification Authority (CA an authority?
   The CA (Holder in our case) is regulated by contract, and is a tracable and regulated organisation which has the facilities to validate the organisation's identity.
   
6. Is the user part of the security design?
   Yes and no. The user is given very simple questions to ask: are there Credentials attached to this transaction, are they what I expect (from a business perspective not technically) and if I check the Credentials using a provided Java program against the well-known public keys of my organisation's proxies do they check out?
   
7. Was it one CA or a CA plus a Registration Authority (RA)?
   The checking is always done by your own Holder.
   
8. How did the CA identify the Certificate Holder?
   By checking their Credentials against registration documents and authorised signatories.
   
9. How secure are the certificate practices?
   In a sense this is not your concern, because of the MoU. It places responsibility with the organisation sending the transaction, and if they have sent you something that is wrong they still have to honour it.
   
10. Why are we using the CA process, anyway?
    We are not, in the sense that the question was asked.

9. What has this model achieved?
This model has achieved a trustable mechanism for identifying the parties to a transaction. This is, if you like, a "Who" service. Once you have identified the parties, then other services - "What" services - become practical. Such services as the positive identification of Lawyers, Chartered Accountants, Surveyors etc. and their regulatory bodies. Additionally, the Banks could offer Credit Checking services against such identities.

10. Summary
I hope I have convinced you that alternative models are possible, desirable and even necessary, given the limitations of the X.509 Hierarchical Certificate PKI model. I hope that I have also shown you an alternative that answers the business need, and, more importantly, is easy to implement and use. Currently it requires separate proxy machines but the functionality is all embeddable within an eMail Server or a more traditional Web Proxy, and the Servlet functionality could be provided by the Web Server.



Users/Developers If you would like further details, a visit from DGA to discuss this in greater detail or to enquire about DGA security consultancy services, please look at our Web site, www.DGA.co.uk/Cred or contact us


Copyright 2000 David Goodenough & Associates Ltd

Featured Solutions and Services from DGA

Contact webmaster@dga.co.uk with questions or problems with this service.
Copyright 1996-2008 David Goodenough & Associates Limited
Telephone +44 1252 560004