Roger Clarke's Web-Site
© Xamax Consultancy Pty Ltd, 1995-2017
|Identity Matters||Other Topics||Waltzing Matilda||What's New|
Principal, Xamax Consultancy Pty Ltd, Canberra
Visiting Fellow, Department of Computer Science, Australian National University
Review Draft of 22 December 2001
© Xamax Consultancy Pty Ltd, 2001
This document is at http://www.anu.edu.au/people/Roger.Clarke/EC/PKIReinv.html
Building on a richer conception of authentication than has been used to date, a statement of requirements is expressed for public key infrastructure (PKI) to support e-business. Inadequacies inherent in conventional PKI are underlined, providing important reasons for its continued low take-up rates. Alternative approaches to electronic authentication are evaluated against the requirements.
Since Diffie and Helman's 1976 paper, digital signatures based on public key cryptography have been perceived to be a vital building-block of the new economy. Public key infrastructures (PKI) have been devised, based on a number of assumptions about e-business needs, and utilising a certificate standard called X.509. Conventional PKI have made very slow progress, however, and have been criticised for a wide variety of reasons. For consolidations of the criticisms, see Davis 1996, Ellison & Schneier (2000b), Clarke (2001b) and Winn 2001.
Those papers had an essentially negative purpose: to criticise a seriously flawed technology. The purpose of the present paper is to make a more positive contribution. The intention is to articulate a set of requirements for a form of PKI that will actually enable e-business. The focus throughout this paper is on digital signatures. PKI for other purposes, such as message encryption, is not considered.
A companion paper presents a model of entities and identities that provides a new and significantly different appreciation of the notion of authentication (Clarke 2001e). The present paper commences by summarising that model. It then applies the model, by declaring a set of requirements of infrastructure to support effective applications of digital signature technologies to e-business. These embody the real needs of business, but also reflect the public desire for private space and for procedures no more inconvenient and intrusive than is actually justified by circumstances.
Conventional PKI based on X.509 certificates are evaluated against these requirements, and shown to embody flaws that greatly constrain their applicability. A range of alternative approaches is briefly reviewed, and suggestions made as to how they may be used in order to deliver applications of public key schemes that reflect the real needs of e-business while protecting interests important to the people and organisations involved.
A companion paper, Clarke (2001e), argues that the concept of authentication used in applying public key cryptography to e-business has been seriously deficient. That paper develops a model of the relevant domain whose intention is to provide the appropriate degree of precision and subtlety. This section briefly summarises that model, in order to establish the foundation for a re-conception of PKI.
Authentication is the process whereby a degree of confidence in an assertion is established. In e-business discussions since the mid-1990s, it has been commonly used as though it referred only to assertions of the form 'the person who originated this message is the person who uses a particular identifier'. See, for example, Schneier (1996, pp.52-56) and the On-Line Dictionary of Computing (entry dated March 2001).
The common usage of the term 'authentication' is deficient because it conflates several forms of assertion that should be distinguished. In addition to assertions about a particular human being, the following kinds of assertions are relevant to e-business;
The following sub-sections examine these various forms of assertion, and propose terms that are usefully descriptive of them. Most of the concepts were introduced in a series of papers by the author over the last decade (including Clarke 1994a, 1994b, 1995, 1996b and 1999d). The concepts and the model underlying them are examined in greater detail in the companion paper, Clarke (2001e).
The term 'entity' encompasses all manner of real-world things, including objects, animals, people, and 'legal persons' such as corporations, trusts, superannuation funds, and incorporated associations. A data-item or data-items used in an information system to distinguish one instance of an entity from other similar instances is often referred to as an 'identifier'. This is not sensible, because it confuses the concepts of 'entity' and 'identity'. In this paper, the term 'entifier' is used to refer to data used as a signifier of an entity. For humans, for example, this would be likely to be a biometric.
In e-business, several different kinds of entities are relevant, and have substantially different characteristics. The following three categories accordingly need to be distinguished:
An entity does not necessarily present using an entifier. It may perform many roles, and the relationship of each of these roles back to the particular entity may or may not be apparent. The term 'identity' refers to a particular presentation of an entity. An 'identifier' is data concerning an identity, that is sufficient to distinguish it from other instances of its particular class, and that is used as a signifier for it.
In e-business, each of the three kinds of entities may exhibit identities. The following three categories accordingly need to be distinguished:
There are many circumstances in which a message-recipient may not be able to readily discern whether an identifier belongs to a human, an organisation or an artefact. For example, an email-address (leaving aside the question of its authenticity), may be as readily machine-generated as human-generated.
A further, very important notion is that of an identifier where the entity underlying the identity is not known, i.e. the user of that identifier either cannot be established (anonymity), or could be but has not been (pseudonymity). This notion, most commonly referred to as a 'nym', is addressed in detail in Clarke (1994a), Clarke (1999d) and Smith & Clarke (1999). The concept nym is a special case of the concept identifier.
Nyms are commonly used by many different parties in both business and e-business. Organisations use them to differentiate business enterprises operated by the same legal entity, and to project particular images to their prospective customers. Employees of organisations use them to avoid disclosing their commonly-used personal identities. Consumers use them to avoid the consolidation of a profile by marketers, and to avoid the correlation by government agencies of enquiries that they make to an agency, with that agency's holdings of personal data about them.
In the remainder of this paper, where a statement applies to either or both of an entifier and an identifier, the term '(id)entifier' will be used, as will the term '(id)entity' where either or both of an entity or an identity is being referred to. In general, statements in this paper that use the term (id)entity also encompass nyms.
There are many e-business contexts in which an assertion is made that relates to the value being conveyed by the message, and where the entity or identity associated with the payment is of secondary or no importance.
Such assertions are of the form 'the contents of this message have a particular value to the recipient'. For example, funds have been transferred from the sender's account to an account nominated by the receiver; or the message contains the electronic equivalent of a coin of a particular value in a particular currency.
The assertion may include some statement about the (id)entity that sent the message, but this is not intrinsically necessary. Hence two sub-categories can be identified:
Many assertions relate to something about an (id)entity. In some contexts it is important to know the (id)entifier of the (id)entity that the assertion relates to; but in many other contexts this information is of secondary or no importance.
Such assertions are of the form 'the (id)entity that originated this message has a particular attribute'. For example, the person issued with that loginid is a registered medical practitioner, or the person requesting that web-page is over the age of 18. It is once again important that two sub-categories be recognised:
Two cases of attribute authentication are sufficiently important to e-business to warrant special treatment.
The first of these is agency authentication. In this case, the assertion is of the form 'the (id)entity that originated this message is an agent for another (id)entity'. For example, the person issued with a particular loginid has power of attorney over the affairs of a specific person; or that person is entitled to issue purchase orders on behalf of a particular corporation up to a particular value. For each principal-agent relationship, several sub-categories need to be distinguished:
Frequently, chains of principal-agency relationships exist. Commonly, an individual will represent an organisation that in turn represents another organisation, e.g. an employee of a customs agency that is acting on behalf of an importer. The authentication of an agent requires inspection and testing of the evidence for the complete series of delegations. In conventional business practice, such inspections and testing are seldom performed, and in most cases they would be impracticable anyway. Society and business have always depended on a great deal of trust. Contrary to the frequently expressed opinions to the contrary, and despite the increased risks inherent in cyberspace, it appears likely that e-business will as well.
A second important special case of attribute authentication is location authentication. The assertion is of the form 'the (id)entity that originated this message did so from, or in respect of, a particular location, within some tolerance range' (Denning & MacDoran 1996). This would most likely involve location and tracking technologies such as the triangulation of cell-phone signals or the use of global positioning systems (GPS). See Clarke (2001d).
Location authentication has application in a variety of contexts, including:
Once again, two sub-categories exist:
This model of authentication for e-business distinguishes 15 kinds of assertions. Of those, the authentication of precisely 1 (identity authentication for humans) has to date attracted most of the attention of the purveyors of public key technologies.
The purpose of this paper is to apply the above new model of authentication for e-business to the evaluation of existing PKI, and the design of new ones. At the outset, it is important to state clearly what public key technologies actually do, what they might do provided that certain conditions are fulfilled, and the limitations on what they can do.
Fundamentally, public key (or asymmetric) technologies (hereafter 'PKT') enable a message to be encrypted with one key, and de-crypted with another. Secret-key (or symmetric) technologies, on the other hand, use a single key that both parties must possess, and that key therefore has to be communicated from whomever creates it to whomever needs it, and therefore has to be exposed to the risk of interception. With public key technologies, one of the key-pair can be kept securely by one party, and never exposed to the risk of interception by a third party.
Digital signatures are an important application of public key technologies. A private key is used by a message-sender to encrypt a string known to both the sender and the recipient (most usefully, a hash of the message that is being transmitted). The corresponding public key is used by the message-recipient to de-crypt the signature, to that the result can be compared with the expected value. Many tutorial treatments are available, e.g Clarke (1996a) and RSA (2001).
All that PKT does is to provide to a message-recipient the assurance that the digital signature was generated by an artefact that had access to a particular private key. This is potentially useful; but it is very limited and specific.
It is common for proponents of PKT to leap to the conclusion that it also provides assurance about the (id)entity of the artefact. If it did, then it would correspond to what was referred to in the previous section as '(id)entity authentication for artefacts'. This is only 2 of the 15 kinds of assertion that it was identified above as being relevant to e-business; but in many circumstances that would be quite valuable.
For several reasons, however, authentication of artefact (id)entity is not reliable unless a range of risks are satisfactorily addressed. They include the following:
If bare-bones PKT is to be applied to authenticating assertions regarding artefacts such as web-servers, smart-cards and software agents, then risk management strategies need to be developed and implemented in order to address such vulnerabilities. It is notable, however, that conventional PKI tends to assume that some of these fundamental problems are addressed by someone else, rather than actually providing the means of addressing them.
Particularly problematical are measures to ensure that the public key is provided in the first instance by, and only by, the entity to whose origination of messages it is intended to testify. This is a classic 'bootstrapping' problem, because the very reason that the authentication mechanism is being created is that no satisfactory authentication mechanism currently exists; and therefore the new authentication mechanism is as flawed as the one that was used in the first instance. This was referred to in Clarke (1994b) as 'the entry-point paradox'.
The (id)entities of network-connected artefacts are 2 of the 15 kinds of things that need to be authenticated. PKT cannot, in itself, authenticate assertions that relate to entities that are outside the networked world. This includes humans, organisations, attributes of entities of all kinds, and most forms of value. For PKT to be of any use in relation to these other kinds of assertion important to e-business, additional measures are necessary. The term 'public key infrastructure' (PKI), when used in its most generic sense, is an appropriate term for such a collection of measures.
Each different kind of assertion demands a separate analysis. An indication of what is involved is provided by a brief consideration of the authentication of just 1 of the other 13: human identities, such as userids.
The key-pair needs to be associated with some real-world identity. (The term commonly used in the computer security literature is 'binding' of the key to an identity; but this implies a much tighter form of association than is actually feasible, and is therefore avoided in this paper).
A mainstream mechanism is to establish a loginid-password pair, and enable the signing mechanism if a user keys both of them successfully within three attempts. It seems remarkable that the combination of one security measure comprising about 6 readily-memorisable characters (disclosed through the same number of readily-observable keystrokes), together with a (say) 1024-bit string that very few people could memorise, should be treated as though it was as secure as the long string rather than the short one. But that is, in effect, what is conventionally done.
Less weak authentication mechanisms are feasible, and have been proposed, and in some circumstances even implemented. Passwords may be extended to passphrases, which are not difficult for the real user to remember, but are more difficult for a would-be imposter to capture. One-time passwords may be applied, such that knowledge of the previous password is of no assistance to the would-be imposter (unless they also gain access to the source of the series of passwords, so that they can work out which one should be used next). People may be refused permission to use an identifier unless they submit to a registration process, provide tokens (such as documents and 'id cards') that evidence their association with the identifier in question, and answer questions that test whether they are the person to whom the tokens relate.
Strong authentication mechanisms are feasible as well, depending on physical measures (biometrics) of the person or their behaviour. This represents entity authentication. One-time entity authentication is insufficient, however, because, for strong authentication, a measure of the individual needs to be checked against a reference measure on each occasion that they seek to use powers available to that entity. This requires the installation of secure biometrics-measuring devices at every point where a person may present, together with the secure availability of the reference measure against which the new biometric is to be tested.
If public key technologies are to fulfil their promise of contributing to e-business, the requirements of a PKI need to be defined. The first sub-section defines PKI. The next draws on the insights of the model outlined above in order to establish requirements of PKI from an e-business perspective. The third sub-section complements that by stating public policy needs in relation to PKI. The definition is then expanded by describing the elements necessary to deliver a comprehensive PKI. The final sub-section draws attention to the need for applications of PKI to be appropriate to the context of use.
An effective PKI must be far more than a set of physical and computing measures for handling keys, because it needs to establish and maintain relationships between those keys and real-world entities and actions. Moreover, because each of the 15 kinds of assertion-authentication is distinctive in its nature, separate risk analyses are needed, and a wide variety of system features is needed in order to address the various needs.
The term 'PKI' is used in this paper to refer to the comprehensive set of measures needed to enable public key technologies to support the authentication of assertions. As will be discussed later, most references use the term in a far narrower sense. There are signs of the broader notion becoming more mainstream, however, e.g. a not-yet-official IETF document defines PKI as "the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography ... A failure in any one of [many security] areas can cause the entire system security to fail" (Arsenault & Turner 1999-2001).
A necessary feature of a PKI is that the recipient of a message must have access to the public key of the sender. The original conception in Diffie & Hellman (1976) was that public keys would be stored in the equivalent of a telephone directory. Kohnfelder (1978) argued that this would generate a great deal of traffic and contention. He suggested instead a digitally signed directory entry which he called a 'certificate'. That term over-stated the original function that Kohnfelder had in mind for the 'signed directory entries'. It was adopted, however; and during the following decade, the functions such certificates were supposed to perform was expanded beyond merely conveying the public key, to include the provision of some kind of assurance about the entity that used the corresponding private key.
The following two sub-sections define requirements of a PKI. The fourth sub-section then extends the definition provided here, by stating the elements needed within a PKI to address those requirements.
In section 2 above, a model of authentication for e-business was outlined. Applying that model, the requirements of PKI from the business perspective can be defined as follows:
Some commentators assert the absolute primacy of free enterprise. This paper adopts the following alternative views:
Clearly there is a public policy requirement for controls over criminal activities. This has been much-discussed in the aftermath of the terrorist assault on Manhattan in September 2001. Unfortunately, the discussions have been hysterical rather than deliberative. Most commentators have overlooked the fact that most of the terrorists appear to have been using well-established identities, and legally in the country and in the aircraft. Authentication became an issue only at the stages when they entered the cockpit, and when they took over the aircraft controls.
There is also a public policy requirement for controls over miscreants. By this is meant firstly people who commit minor crimes and misdemeanours, and secondly those whose behaviour breaches civil and commercial rights of other people and of corporations (e.g. by attempting to pay using other people's credit card details).
Both of these public policy requirements tend to support the implementation of PKI designed to support relatively strong authentication of devices and human entities. There are many other public policy requirements, however, that run emphatically in the opposite direction.
(Id)entity authentication imposes significant inconveniences on people and organisations, in terms of the effort and costs involved. For example, registration may require the acquisition of documents, the notarisation of documents, physical travel, queuing and re-visits; and RAs' operations and operating hours are in many cases far better attuned to their own cost-minimisation needs than to the needs of the subject population. This affects consumers and small business enterprises when they deal with bigger business enterprises; and citizens, small business and big business when they comply with government agency dictates.
Authentication schemes raise equity issues, because they can impose heavily on some categories of people, such as those who have difficulties of understanding (e.g. due to lingual, literacy or comprehension inadequacies); difficulties of compliance (e.g. because they have no right thumb, or have fingerprints that are not sufficiently clearly defined to provide a reliable reading); or difficulties of ambiguity (such as possessing a very common name, or having an identifier that has been the subject of identity theft). In addition, authentication schemes can come into conflict with religious and philosophical values, cultural traditions, and life-styles lived by some groups, particularly aboriginal peoples, but also Romany and the homeless.
Some people's safety and/or state of mind are greatly threatened by the increasing intensity of data-trails, because discovery of their location is likely to be followed by the infliction of harm, or the imposition of pressure likely to repress the person's behaviour. There is a vital need for persons-at-risk to be able to use multiple nyms, in order to avoid detection, and to do so in many different aspects of life, including many which involve government agencies, such as health, taxation, licensing and electoral registration. See Clarke (1999d). Examples of persons-at-risk include:
Many PKI designs involve substantial privacy-intrusiveness. The privacy implications of PKI were examined in Greenleaf & Clarke (1997). Risks arising in relation to private keys are apparent enough, and include issues relating to key-generation, storage, backup, access, revocation and even escrow. Public keys also involve considerable threats, however: directories and logs of public keys, of uses of certificate-ids and of accesses to revocation lists generate a comprehensive dossier of a person's electronic activities. Moreover, revocation processes represent an opportunity for an authority to cancel a person's cyber-identity.
Of even greater concern to many people are the consequential impacts on privacy. One example is the attempts by governments and corporations alike to deny anonymity and pseudonymity, and enforce identification as a condition of many transactions that have been hitherto anonymous (such as small purchases and the vast majority of travel). Another is the pressure from authoritarians for a single identifier per person, and coerced carriage of an identifying token. These anti-utopian dreams are increasingly featuring biometrics, often stored in central databases. Contrary to the conventional wisdom, this would significantly increase the risk of masquerade (Hill 2001), and of identity theft and framing, and significantly increase the harm arising from identity theft.
Requirements of a privacy-sensitive PKI are expressed in Clarke (1998) and Clarke (2000). Desirable privacy properties of certificates are defined in Brands (2000, pp. 24-26).
Most schemes demand substantial quantities of personal data, and in many cases this results in yet more storage of that data. There can also be impacts on the privacy of personal behaviour, and on the privacy of personal communications. because of the sense of being under continual, and even continuous, observation. Some proposals extend the intrusiveness into the privacy of the person, by requiring the provision of biometrics.
Broader than mere personal privacy is the problem of dataveillance (Clarke 1988). PKI tends to create a climate in which everyone is subject to being exposed, rightly or wrongly, as having performed particular acts that may cause embarrassment, or result in the person being regarded negatively by some proportion of the population.
The explosion in cheap surveillance results in enhanced power by organisations over individuals. Grave dangers arise where every person has a belief that some powerful authority 'knows all about them'. It is well-established that surveillance has a 'chilling effect' on people's behaviour. The kinds of behaviour that are subject to deterrence cover a wide range, including not only criminal and anti-social behaviours, but also the formation of opinions, political expression, and hence representative democracy, creative endeavours in the arts, and innovation in industry and business.
These contra-indicators for authoritarian schemes link back to the business requirement of public acceptability. Concerns seem likely to be particularly marked in the case of politically-active individuals, and independently-minded business people such as sole traders, and small and medium-sized, owner-managed corporations. If these concerns were perceived to outweigh the benefits (such as law and order, and the appropriate sharing of the costs of public services), then authentication schemes could be rejected by the public. If so, government agencies might choose to utilise legal authority to impose unpopular requirements; but businesses risk harm to their relationships with their customers if they decided to force the issue.
In order to satisfy the requirements expressed in the preceding two sub-sections, a PKI needs to comprise all of the following elements. Checklists for each are provided in Appendix 1:
Public key technology is a mathematical artifice that can be usefully applied to a range of security problems, but only within a network. For PKT to be useful in authenticating assertions contained within messages, key-pairs need to be pre-authenticated as being associated with something in the real world. Gerck (1997) refers to this as 'extrinsic certification', and the organisation that performs it is conventionally referred to as a registration authority (RA).
Two alternative approaches can be adopted. Pre-authentication of the association between the key-pair and something in the real world may be defined to be:
If the PKI is defined to support the pre-authentication of the association between a key-pair and a real-world (id)entity, then a substantial further set of elements is necessary, to define the standards, processes, services and warranties of the RA.
There are many different forms of e-business, including consumer Internet commerce (Clarke 1999b), B2B dealings (Clarke 2001b), e-publishing (Clarke 1997), and electronic services delivery (Clarke 1999c). These encompass high-value, low-value and no-monetary-value e-commerce, and both established relationships and casual interactions and transactions.
Section 2 above identified many different kinds of assertions that are appropriate to authenticate in those highly varied circumstances. Moreover, PKI are not merely inter-organisational or multi-organisational systems. They are extra-organisational systems extending over public networks (Clarke 1992), and involve individuals and unincorporated enterprises, as well as corporate entities.
Because of this enormous diversity of contexts, generic authentication schemes are not appropriate. Instead, the trade-offs inherent in designs need to be situation-specific, need to reflect all of the factors operating in that particular context, and hence need to be based on risk assessments and customised risk management strategies.
Factors that need much more attention than they have received from designers to date include the following:
In addition, designers need to broaden their focus beyond the business sponsor, and recognise the interests of all stakeholders. This implies that, in various circumstances, they need to:
This paper has gone to considerable lengths to use the term 'PKI' in a generic manner. Further, it has sought to establish requirements for PKI based firstly on a new model of authentication that relates to the needs of e-business, and secondly on public policy factors.
This section applies the generic requirements as a means of evaluating the effectiveness of conventional PKI. The analysis is made difficult by the inter-weaving between certificate formats and other aspects of PKI. The first sub-section addresses X.509, and the second the broader questions of X.509-based PKI.
Many warnings have been issued over the last five years that things are seriously amiss with conventional PKI, e.g. Davis (1996), Greenleaf & Clarke (1997), Gerck (1997-2000). But it is only during the last year or so that catalogues of the fundamental deficiencies have been widely disseminated. See Ellison & Schneier (2000a, 2000b), Schneier (2000), Winn (2001), Clarke (2001c). Those sources are reflected in the following sections.
The X.509 standard defines the format for a digital certificate. This is intended as a credential evidencing a CA's assurance that a particular (id)entity is associated with the private key that matches the public key contained in the certificate. The successive versions are v1 (1988), v2 (1993) and v3 (1996).
X.509 was originally intended to be one element within a comprehensive framework for a global directory service for people and organisations, generically referred to as X.500. X.509's role was "to tie a public key to some node or sub-directory of that structure. ... The Subject of such a certificate was a path name indicating a node in the X.500 database - a so-called 'Distinguished Name'. The distinguished name took the place of a person's name and the certificate was called an 'identity certificate', assumed to bind an identity to a public key" (Ellison 1997). X.500 was over-ambitious, and little-implemented, although a 'lightweight' version of a key part of X.500, called LDAP, has been applied in a more constrained manner.
When developers set out to implement public key schemes independently of X.500, X.509 was a ready-made certificate specification. In short, X.509 was the hammer that came to hand when the nail was discovered.
Several other certificate-formats exist, which, unlike X.509, were designed for the specific purpose. PKCS#6 is a specification for a super-set of X.509. PGP uses its own certificate-format. SPKI/SDSI provides a certificate-format. So do Brandsian Private Credentials. A comparison among several certificate-types is in Ellison (2000b). X.509 certificates, however, are used in the vast majority of products on offer.
The X.509 standard extends beyond merely defining a certificate format. In particular, it defines a means of handling revocation, and declares that there is a need for information about how pre-authentication of the association of the key-pair with a real-world (id)entity is performed. The following specific inadequacies inherent in the X.509 specification are now examined:
The standard provides a wide range of choices, and products that apply the X.509v3 certificate format vary considerably in the particular certificate formats they support. As a result, a 'profile' needs to be defined for use in each particular application, and a great deal of technical difficulty arises in achieving inter-operability among X.509-based schemes (Gutmann 2000).
X.509 certificates include a data-item referred to as the `distinguished name' (DN) of the `subject'. This data-item was intended to use values assigned within name-spaces managed by the originator of the X.500 series of standards, the International Telcommunication Union (ITU). It appears that there are no such name-spaces, and hence such uses as are made of that data-item may be non-conformant with the specification.
On the other hand, "in theory you don't have to use ... the subject name if you don't want to; there is a subjectAltName extension which allows use of email addresses or URL's. ... but this will break a lot of implementations. ... The subject and issuer alternative names are used to specify all the things which aren't suitable for a DN, which for most purposes means practically everything of any use on the Internet ... This includes email addresses, URL's for web pages, server addresses, and other odds and ends like X.400 and EDI addresses. There's also a facility to include your postal address, physical address, phone, fax and pager numbers ..." (Gutmann 2000).
X.509v3 certificates permit an agent of an organisation to protect their personal identity through the use of one or more role-titles. It is arguable, however, that they actually preclude an individual (referred to as a 'residential person') from using a title or a pseudonym. Moreover, some implementations may preclude a residential person from possessing multiple personal key-pairs, even though the same person is permitted to possess multiple key-pairs for organisations that they represent. Another concern is that distinguished names are required to be unambiguous; so that either the second and subsequent 'John Smiths' need to use a qualifier (such as '#2'), or every name needs to be qualified in some manner that effectively achieves uniqueness (e.g. commonly-used name together with date of birth and a location indicator). The situation is unclear, however, because some relevant aspects are not specified in the standard, but rather delegated to the implementor and/or to the policies and practices of the CA and RA.
On the one hand, "The goal of a cert is to identify the holder of the corresponding private key, in a fashion meaningful to relying parties" (attributed to Stephen Kent by Gutmann 2000). On the other, it is feasible to use an X.509 certificate to evidence an association between a public key and an artefact such as a device, a port on a device, a web-server, an email-account or a web-page.
Hence it appears that the X.509v3 standard supports authentication of artefact (id)entities, but is primarily intended to support authentication of human identities. It would appear that the purpose of an X.509 certificate is to associate a public key with some (id)entity, and hence to preclude anonymity. It might conceivably support pseudonymity, but only if the policies, procedures and practices within RAs and CAs are designed to do so, and if technical, organisational and legal protections exist for the records of those organisations that relate the name in the certificate to the (id)entity of the 'subject'.
One (among many) reasons for the failure of the X.500 directory standards to attract support was the perception that any global index is seriously threatening to privacy and freedoms. Because X.509 has its origins as the certificate-component of X.500, it is no surprise that it has such privacy-unfriendliness embedded within it.
Attributes of the (id)entity could be communicated within the primary certificate. If that were done, however, every recorded attribute would be exposed to everyone who received the certificate, which would breach public trust (not to mention data privacy laws in the many economically advanced countries that have them).
X.509v3 provides for a degree of extensibility to the base certificate. In particular, it enables a parent (id)entity certificate to have any number of child attribute certificates. This has the advantage that the person's credentials do not all have to be visible to everyone that needs access to one of them, e.g. a medical practitioner, in communicating their capacity to prescribe medicine, need not disclose their own gender, marital status, professional and club memberships, health conditions, etc.
But the attributes are inherently linked to, and dependent on, the primary certificate, which in turn bears the individual's (id)entifier. Indeed, the IETF's definition of 'attribute certificate' expressly precludes the possibility of attribute authentication without (id)entity (RFC282 2000), and thereby fails against the requirements identified earlier in this paper.
The analysis of public policy requirements in section 4.3 above drew attention to the need to avoid the use of public keys and certificates as a basis for the consolidation of personal data, and the tracking of individuals.
Brands identifies serious problems with X.509 digital certificates and PKI: "each digital certificate can be traced uniquely to the person to whom it has been issued (or the device in which it has been incorporated), and can be followed around instantaneously and automatically as it moves through the system. Even digital certificates that do not specify the identity of their holder can be traced in a trivial manner ... On the basis of these unique serial numbers, which will travel along whenever an individual engages in a communication or a transaction, organisations and even individuals can compile detailed personal dossiers" (Brands 2000, p. vii-viii. See also pp. 16-20, pp. 20-24).
Descriptions of conventional PKI devised to use the X.509 certificate-format can be found in myriad tutorials and presentations. One of the more useful is Xenitellis (2000, Ch. 5). See also Ford & Baum (1997), Adams & Lloyd (1999) and Austin (2000).
Important schemes that utilise X.509 certificates include SSL/TLS, PKIX, S/MIME and W3C XML-Signature (aka XMLDSig). These exhibit varying degrees of appreciation of the deficiencies of X.509 certificates and of prior designs for conventional PKI, and varying approaches to addressing some of those deficiencies.
Secure Sockets Layer (SSL) is a protocol that provides a layer of 'channel encryption' for Internet transmissions, particularly those using the http protocol. SSLv3 is implemented in all mainstream browsers (SSL 1996). Transport Layer Security (TLS) is a more recent enhancement to SSL (RFC2246 1999, RFC2487 1999, RFC2595 1999). In principle, SSLv3 and TLS support two-sided authentication of both server and client. In practice, they are usually used for one-sided authentication (because very few clients provide certificates), and with servers providing evidence of their (id)entity that is at best fairly weak. Moreover, many SSL implementations ignore the possibility that a certificate and/or the key-pair it attests to may have been revoked.
PKIX is an initiative to:
See PKIX(1993-), PKIX (1995-) and Xenitellis (2000).
Members of the PKIX standards team recognise, however, that PKIX is not sufficiently comprehensive to represent a complete PKI: "[PKI is] the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography ... A failure in any one of [many security] areas can cause the entire system security to fail. PKIX is limited in scope, however, and only directly addresses issues related to the operation of the PKI subsystem" (Arsenault & Turner 1999-2001).
S/MIME is a family of protocols for the transmission of messages with encryption and/or digital signatures. Earlier versions did not proceed to adoption as a formal Internet standard (partly due to patent issues), but version 3 may now be moving towards adoption (RFC2632 1999, RFC2633 1999, IMC 1999, S/MIME 2001). It builds on a set of prior standards, including MIME-encapsulation for email attachments (RFC1847 1995), X.509v3 certificate formats (X.509 1997), including CRLs; and the PKIX certificate-profile. It therefore generally has the features of X.509v3 and PKIX.
W3C's emergent XML-Signature provides a means of digitally signing data, and is therefore expressly intended to address only the authentication of an artefact's (id)entity and/or attributes (W3C 1999-, W3C 2001). Several mainstream certificate-formats are encompassed, viz. X.509v3, PGP and SPKI. To the extent that X.509v3 certificates and conventional PKI are used, XML-Signature inherits their features.
The following weaknesses in such conventional schemes are discussed below:
The X.509 specification pre-supposes the existence of CAs, and opens the way for the performance of pre-authentication procedures by an RA on the CA's behalf. A CA is required to have a 'certificate policy', which is "a named set of rules that indicates the applicability of a certificate to a particular community". It requires that CAs declare their certificate policy, possibly using a data-item within the X.509v3 certificate.
It appears, however, that the specification of what standards the RA and CA should measure up to, and how the pre-authentication of the association with the key-pair should be performed, are both beyond the scope of X.509. They are also quite possibly beyond the scope of an X.509-based PKI (or 'out-of-bound', as PKIX RFCs express it): "Section 11.2.a [of X.509v3] states that: "a [CA] shall be satisfied of the identity of a user before creating a certificate for it", which means that identity validation procedures are to be satisfied in the CA's frame of reference by following the CA's own self-defined rules" (Gerck 1997).
The PKIX specification goes a little further than the X.509 standard. For example, it says that "it is REQUIRED that CAs/RAs MUST enforce [proof of possession of the private key] by some means because there are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding ... exist, and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful" (RFC2510 1999). The expression 'somewhat less meaningful' is unduly restrained: if the association is not pre-authenticated, then the authentication that is later performed by means of the digital signature is devoid of meaning.
In addition to a 'policy statement', PKIX contemplates "a more detailed description of the practices followed by a CA in issuing and otherwise managing certificates [, which] may be contained in a certification practice statement (CPS) published by or referenced by the CA" (RFC2527, 1999).
However it does not appear that any minimum standard is imposed on pre-authentication processes, nor is it mandatory to communicate the certificate policy or a certificate practice statement, nor even the means of accessing them, and it is far from clear that failing to even have such statements is in contravention of the standard.
In short, PKIX provides the appearance of imposing requirements in relation to pre-authentication, but in fact does not do so. Pre-authentication, which is the only actual source of assurance of the relationship between the key-pair and the real world, is in practice not part of the infrastructure, but an applications-level feature. Yet X.509 and PKIX are so poorly written that applications designers have plenty of excuses for not appreciating that fact. The serious risk therefore exists that application designers will create dangerously ineffectual schemes because they assume that the association between the key-pair and the real world is someone else's problem.
One of the underlying assumptions of any X.509-based scheme is that an unknown sender can be trusted because a CA provides a certificate. But if a relying party has no trust in the unknown sender, why would they trust the unknown CA that signed the unknown sender's certificate? If the answer is 'because the CA has been vouched for by another CA', then the question degenerates into a cascade of blind belief in a chain of unknown entities.
Conventional PKI is inherently hierarchical: each layer of CAs is meant to be attested to by some superior layer. It is implicitly assumed that an ultimate authority exists, in which everyone has ultimate trust. Trust in the real world has never worked like that, and it is far from clear that it will work like that in e-business.
The failure of hierarchical schemes to gather commercial momentum has led suppliers to search for other means of inventing trust. This has involved cross-certification and more recently 'mesh architecture'. It is not clear that these notions are emjoying much success either.
A critical feature of PKI schemes is the warranties provided by the CA to accompany the assurance. It would be expected that the CA would incur financial liability if:
Moreover, the wording provided by web-browsers suggests considerable protection, e.g. "The signer of the Certificate promises you that the holder of this Certificate is who they say they are" (Macintosh Netscape Navigator 4.08).
The reality is very different, however, and the problem is compounded by the fact that a contract is unlikely to exist between the CA and the party that relies on the certificate. The commercial terms on which the CA provides assurance to other parties are commonly defined in Certificate Policy Statements. The conditions relating to even the more expensive certificate services are generally phrased so that they minimise the CA`s exposure to liabilities: they are essentially huge (70-100 pp.) and highly convoluted disclaimers, seeking to avoid all potentially avoidable liability under all contingencies, e.g. "... Verisign [gives] very limited express warranties and exclude[s] all other warranties and obligations of any type. Most of the CPS is occupied with disclaimers, limitations and exclusions of liability" (Sneddon 2000, p.24).
The legal situation is far from clear; but it seems that CAs might well be successful in their attempts: a relying party appears to have little or no legal protection, not just if the CA was wrong, but even if the CA was negligent (Sneddon 2000).
To the extent that CA's successfully avoid liability when the assurance is misplaced, their role in the process is valueless.
All certificate-based systems are utterly dependent on the existence and use of an effective and timely revocation mechanism, because once a private key has been compromised, it needs to be withdrawn immediately, or the confidence of participants will be seriously harmed.
A mechanism is specified in X.509v3 (1996): "This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked certificates which is signed by a CA and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number" (RFC 2459 1999).
The occasional, push, batch approach of CRLs is totally ineffectual in terms of both security and practicality. As the RFC coyly puts it: "One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next periodic CRL is issued -- this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs" (RFC 2459 1999). Moreover, some schemes do not even bother to consult CRLs (e.g. SSL).
A more recent specification for an on-request look-up is the Online Certificate Status Protocol (OCSP) (RFC 2560 1999). This still appears to be at Proposed Standard level; and because it was released in June 1999, and longstanding IETF policy and practice has been that Proposed Standards lapse after 12 months, RFC2560 would have to be re-instigated as a Proposed Standard before it could proceed further towards adoption. In any case, OCSP appears to be little-implemented to date.
Other proposals have been made, such as that by Rivest for a key compromise agent or suicide bureau that handles pre-signed suicide notes. To date, however, the much-vaunted security that is notionally offered by X.509-based PKI is seriously undermined by their failure to cope with revocations.
X.509 assumes a global name-space. Because no such name-space has been defined, designers of PKI are forced to adopt ad hoc approaches to the definition of the name of the entity to which the key-pair is associated. PKIX avoids the basic name-field, and instead uses the alternative data-item. There is no explicit statement of PKIX's intended scope, and there are conflicting terms in various parts of the specification.
On the one hand, it appears to associate a key-pair with an artefact (id)entifier. For example, "Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI)" (RFC2459, 1999). This implies that PKIX may be intended to apply primarily to artefacts, but could also apply to humans (at least to the extent that they are suitably identified by a domain-name or an email-address).
The RFC further states that "all parts of the subject alternative name MUST be verified by the CA". Computer engineers use 'verify' in a very limited sense, and the statement may merely mean that a response from a server, name-server or even a domain-name registry enquiry is sufficient, or perhaps merely that the content must be syntactically valid. An email-address must exclude brackets, and hence the most that could be verified appears to be the existence of an account of that name, not the (id)entity behind it.
On the other hand, an 'end-entity' (which is the term used in PKIX for the entity that is the 'subject' of the certificate) is defined to be "[the] user of PKI certificates and/or end user system" and "the ... remote subject (person or system)". Moreover, the RFC states that "The procedures performed by CAs and RAs to validate the binding of the subject's identity of [to?] their public key greatly affect the assurance that should be placed in the certificate". The fact that this explicitly refers to "the subject's identity", without any mention of devices, makes it appear that the scope is intended to be primarily humans and only secondarily devices.
Finally, the not-yet-official PKIX 'roadmap' (Aresenault & Turner 1999-2001) is expressed in terms that make it apparent that its scope is meant to at least include human identities, and possibly to include artefacts only to the extent that they are proxies for humans.
A recent document, RFC3039 (2001), specifies an X.509v3 profile that implements a so-called 'qualified certificate'. This is a term used by the European Commission to describe a particular type of certificate with relevance to European legislation. Such a certificate would be issued exclusively to physical persons. The RFC addresses the EU's wishes, but also envisages the application of the profile beyond Europe.
The RFC states that the certificate "contains an identity based on a pseudonym or a real name of the subject". This is highly misleading, because the motivation for this profile has everything to do with incontrovertible human entity authentication, and nothing at all to do with pseudonymity. The RFC obfuscates, by expressing this as "Many client implementations presuppose the presence of the commonName attribute value in the subject field". Moreover, a pseudonym, if used, has to be declared to be such. Provision is made for the certificate to contain a hash of a biometric template. Put simply, RFC3039 Qualified Certificates are the kind of electronic national ID mechanism of which totalitarian dreams and nightmares are made.
It therefore seems best to presume that the scope of PKIX is constructively vague: it could be applied to the authentication of artefact (id)entity and hence possibly artefact attributes with (id)entity (which represent 3 of the 15 kinds of authentication described above as being needed by e-business); but it could also be applied to human identity and identified attributes (a further 2); and if the Qualified Certificate profile of RFC3039 is applied, then it could also support human entity and human entity attribute authentication (a further 2).
Another issue from a public policy perspective is that PKIX is emphatically based on directories of certificates, and hence provides a ready means whereby the net-activities of a certificate-user can be traced and consolidated, building up a substantial behaviour-profile. Even if PKIX were only applied to artefacts, this would be a major problem because of the large amount of traffic a human generates through a single artefact; but the situation is even worse because of the apparent intention that PKIX be directly applied to human (id)entities.
The original theory underlying PKT was concerned only with the mathematics of producing and checking data-strings that are for all practical purposes unforgeable. The theory made a large number of assumptions about the contexts in which the cryptographic algorithms would be used. A great many of these assumptions transpired not to be reasonable. Several of them that have not been addressed so far apply to all forms of PKI. They are considered in the following sub-sections:
The final sub-section discusses what a PKI can and cannot do.
All forms of PKI are utterly dependent on the private key never being in the possession of any entity other than the one that uses it to sign messages, and on it never being able to be invoked by any other party.
Risk arises when the key-pair is generated. It would seem to be a fundamental requirement that the generation be performed in such a manner that the private key is never accessible by anyone else, which implies that it should be performed by a secure device that is in the possession of the party that will use that key.
Secure devices are uncommon, and expensive. Moreover, PKI designers mostly adopt the attitude that normal humans cannot be trusted to provide the device (because it could not be relied upon to be secure, nor to generate secure key-pairs), and that it must therefore be under the control of the CA.
As a result, in many installed schemes, key-pairs are generated by the CA, which has to be trusted not to use the private key for masquerade. This breaches one of the fundamental security assumptions underlying digital signatures. In schemes run by organisations such as taxation authorities, it creates an untenable conflict, because the primary party that could gain from a masquerade has control over the CA, and hence control over the private key at the time it is generated.
A further concern with some schemes is that the issuer of the key-pair in effect owns it, and only licenses the 'subject' to use it. This places the scheme-operator and/or CA in a position of enormous power, because they have the legal as well as the technical capability to revoke the key-pair, and hence deny the person's e-existence. This may be necessary for principal-agency relationships, but it certainly is not appropriate for personal and corporate keys.
Proposals have also been advanced for the compulsory storage of the private key for the benefit of parties other than the individual concerned (commonly referred to as 'key escrow'). From a public policy perspective, this is problematical in the case of encryption keys; but it is utterly inappropriate in the case of signature keys.
"The protection afforded private keys is a critical factor in maintaining security. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If the compromise is detected, all certificates issued to the CA shall be revoked, preventing services between its users and users of other CAs. Rebuilding after such a compromise will be problematic" (RFC2459 1999).
The range of vulnerabilities is often overlooked. Private keys need to be protected in main memory (where they have to be in clear at least during use). They also have to be protected in secondary storage and in backup-storage (where they may be in encrypted form; but the decryption key has to be stored somewhere, and this represents a further vulnerability). The processes that use private keys also have to be protected against unauthorised invocation, because otherwise a masquerade can be performed even though the private key itself has not been acquired.
There are many ways in which malicious software can be applied to discover, copy or invoke private keys, in memory or on disk. The hardware and systems software of commodity workstations, particularly mainstream Windows and MacOS machines, currently provide very little in the way of security features. Moreover, few products are available that enable consumers to graft such security features on to their work-and-play facilities, and such products as exist require considerable expertise to install and configure (Kaiser 2000).
During the last few years, corporate servers have been subject to a rash of electronic break-ins. The ease with which many of these `hacks` have been performed has demonstrated the serious inadequacy of the precautions taken by organisations of all kinds and all sizes. Standards have been issued by governments (e.g. TCSEC 1985, ITSEC 1991 and the Common Criteria - CCIB 1998), and guidance provided by text-books (e.g. Garfinkel & Spafford 1997), but the degree to which organisations have applied the principles and guidance is embarrassingly low. Many organisations use Microsoft servers, and many systems administrators fail to ensure that inherently insecure default parameter-settings are changed, that known vulnerabilities are addressed, and that available patches are applied.
For the majority of people, who use commodity workstations, security is basically impossible. All operating systems and client software have vulnerabilities, but none more so than the dominant Microsoft operating systems, browsers and email-clients, which are distributed with inherently insecure features and settings.
The possibility exists of private keys being stored on a tamper-proof token, such as a smartcard or PCMCIA card. If any convincing technical solutions appear, they are likely to be expensive and at least somewhat inconvenient; and will in any case demand adaptations to the vast installed base of workstations or a new generation of workstations with additional capabilities.
If signed messages are to have evidentiary value in a court, they need to withstand challenges. A simple way in which doubt can be cast on an assertion is by showing that the dates and times within the evidence are untrustworthy. There are difficulties in achieving synchronisation among networked artefacts, and even more in enforcing synchronisation on artefacts whose designers and/or users are intent on avoiding it. The time of the message, and hence the sequence of events, can therefore be unclear, or made to appear to the court to be unclear.
A deeper security problem exists, however. Latency, however short, means that even a frequently-updated certificate revocation list, and even a 'push' mechanism for communicating revocations, leave open the chance for error or fraud. Important decisions may have been made, and important actions performed, in the time that it takes for the compromise of a private key to be communicated. The reverse is also true: a message-signer could conceivably avoid responsibility for a valid message, simply by revoking a key-pair just before causing the message to be sent, relying on delays within the system to ensure that the revocation arrived too late, and then later repudiating the message. In any case, even slow CRLs are not reliably used in some systems, and the newer and rather faster OCSP protocol appears not to have been widely adopted.
The kind of assertion that digital certificates are supposed to provide assurance about is 'the sender of this message is the (id)entity that uses a particular (id)entifier', where a 'sender' may be a human, an organisation, or an artefact. But conventional PKI involve certificates that do not authenticate that kind of assertion.
What PKI can enable a certificate to attest to is that:
Depending on the registration process that was applied as part of the PKI or as part of the application, a certificate may also attest that:
Irrespective of the design of the PKI and the application, however, a certificate provides no assurance about whether:
A small number of circumstances exist in which conventional PKI may be appropriate.
In closed networks, tight control may be able to be exercised over the artefacts, and conventional PKI may be effective for authenticating artefact (id)entity and perhaps also attributes. It may be feasible to apply such techniques to artefacts in open networks. It is not clear, however, that certificates and CAs offer a great deal more than a simpler scheme based on private keys embedded within devices at the time of manufacture.
Strong authentication of human (id)entities and attributes may be achievable in highly authoritarian contexts. One example is within organisations with powerful hierarchical structures such as the military. Another is strongly authoritarian nations, with Singapore, Malaysia, Hong Kong, Finland and Denmark being possible laboratories. Even in these cases, however, the scheme may well need to be monolithic, because inter-operability is likely to prove impractical. If biometrics-bearing tokens are imposed, and sufficient biometrics-readers installed, this could extend beyond human identity authentication to human entity authentication. Anonymity is precluded by the certificate design. Pseudonymity would be unsustainable. Every electronic act would be readily traceable to the individual concerned, resulting in the chilling of dissent against mainstream views. Power would inevitably be concentrated in an elite, resulting in a regime that was totalitarian as well as authoritarian. Lest it be thought that this is unduly scare-mongering, the EU's 'qualified certificate' profile, expressed in RFC3039, exhibits the features necessary to support such an application.
A less apocalyptic application is moderate-strength identity authentication, implemented in moderately authoritarian contexts, such as taxation, social welfare and health insurance. Pre-authentication would be by means of documents (which would of course further entrench pre-existing multiple identities). In these cases as well, anonymity is precluded by the certificate-format. Pseudonymity would exist, but probably not in a generally-available manner. Those with the motivation, patience and resources (particularly organised crime) would use the many weaknesses in the pre-authentication process to establish additional identities that now carried the imprimatur of the sponsoring organisation and the CA. Processes to establish state-sanctioned aliases would need to exist (e.g. for undercover operatives and protected witnesses), creating an official channel that would also be exploitable by organised crime. Most people could, on the other hand, be successfully forced to comply with the scheme's requirements, and would be restricted to a single identity, at least within the particular context such as social welfare.
Function creep would ensure that the context would be defined fairly broadly (e.g. combining taxation with social welfare). Such schemes would probably need to be monolithic, but some sets of schemes established by related organisations might achieve some degree of cross-compatibility (e.g. social welfare with health). This would most likely be successful where a set of government-sponsored standards was established, e.g. in the U.S. through NIST (2000) and the Access Certificates for Electronic Services (ACES) program, and in Australia the Gatekeeper initiative (OGIT 1998).
Identity authentication might be extended to attribute authentication. (One possible application is for people with disabilities that qualify them for benefits from state and local governments, transport operators, and some private sector providers). Such attributes would be inextricably linked with the person's identity, because of the limitations of the certificate-design. Pre-authentication would probably be based on the internal records of organisations involved in the administration of the parent certificate scheme, or organisations closely linked with them.
On the other hand, conventional X.509-based PKI, including SSL/TLS, PKIX and S/MIME, are inappropriate to a wide array of e-business needs, including:
Conventional PKI also fail against a number of other business requirements described in section 4.2, particularly in the area of risks to private keys, clarity of responsibility for risks, and recourse against CAs and RAs. They are generally unfriendly to the public policy requirements discussed in section 4.3, such as convenience, equity, the safety of persons-at-risk, privacy and dataveillance.
This section considers alternative approaches to the use of public key technologies for authentication in the e-business context. It commences by considering the scope for further revision of the X.509 standards, discusses tools whose primary purpose is authorisation rather than authentication, and then moves on to authentication tools that adopt rather different assumptions and objectives to conventional, X.509-based PKI.
The deficiencies in X.509, described in section 5.1, are intrinsic to the standard. Removing them would involve fundamental changes, including data-item definitions, and the data structures that support attributes. As a result, the objective of backwards-compatibility to prior versions would probably be unachievable.
X.509 derived from the simplistic and threatening X.500 notion of a centralised world directory. It was an inappropriate foundation for PKI to support e-business. A new starting-point should be selected, which reflects the insights that have been gained during the last decade, and which addresses the requirements of both business and public policy that were outlined in section 4 above.
A variety of technologies have been developed to regulate access by human users and artefacts to data and processes. The generic terms used to refer to these techniques include 'authorisation' and 'access control'. Examples of authorisation technologies include all forms of security involving loginid-password pairs, Kerberos, and role-based access control (RBAC).
A comprehensive form of authorisation technology is Blazian Trust Management Systems, which represent a generalisation of longstanding access control techniques. A prototype trust management system has been developed called Keynote (RFC 2704, 1999, Blaze 1999). Trust management is argued to have five basic components:
The trust management approach, in common with all authorisation technologies, focusses primarily on privileges and restrictions. Its second element, however, is explicitly concerned with identities and authentication of the identities of humans and artefacts. It does not presume that it is authenticating the underlying entity, and it can deal with a nym representing a pseudonymous role just as readily as with an (id)entifier that is associated with a particular role or entity. Although primarily addressing a related matter rather than authentication per se, modern authorisation technologies appear to adopt a less narrow and more practical view of the assertion that is to be authenticated.
The conventional approach to PKI depends on hierarchies of CAs. An alternative approach is commonly referred to as a `web of trust'.
In a web-of-trust scheme, digital certificates can be issued by anyone, and fault-tolerance is achieved by each participant deciding for themselves how many and which certificates to rely on. Each certificate can carry a weighting that reflects the degree of trust that the certificate-issuer places in the key-owner and their ability to manage their private key. The approach does not naively assume transitivity of trust as a hierarchy of CAs does. It also requires message-recipients to consider the extent to which they really need assurance, and to confront the fact that all assurance is relative rather than absolute.
Pretty Good Privacy (PGP) is the earliest and best-known scheme that implements the web-of-trust concept (Zimmerman 1995, Garfinkel 1995, Bacard 1995, Stallings 1995. See also RFC2015 1996, IMC 1999). The original public domain form is now referred to as PGP 5.x or OpenPGP (RFC 2440 1998, OpenPGP 2001). A proprietary version also exists, marketed and undergoing further development by PGP Inc. PGP carries the signed and encrypted message in a MIME-encapsulated block, and uses its own form of certificates or `pgp keys'. These contain fewer data-items than X.509 certificates, but can be signed by multiple entities, not just one as is the case with X.509.
The practicality of PGP's specific implementation of the 'web of trust' notion has been criticised. On the other hand, it has been tested in the field, e.g. by Qualcomm in its popular Eudora email-client. Moreover, there are at least some commercial applications of it. For example, a recently-developed Australian superannuation industry scheme decided on PGP because it was a cheap, straightforward and effective alternative to a CA-based scheme. There is also a reasonable level of intellectual support for it (e.g. Maurer 1996, Khare & Rifkin (1997), Grossman 2000).
The hierarchical approach to the certification of CAs has been widely discredited during recent years. To replace it, the 'web of trust' concept has been re-invented under the rubric 'mesh architecture', and spoken of approvingly by purveyors of conventional PKI, industry commentators and government authorities (e.g. GAO 2001).
A web-of-trust approach addresses at least one of the issues of concern with conventional PKI: it obviates the need for authoritarian CAs, and the inconvenience and intrusiveness and cost that they entail in return for very limited additional assurances about the so-called 'binding' of the key-pair to an (id)entity. In common with other possible web of trust approaches, PGP substitutes for the CA's certificate a set of assertions by multiple entities that they also understand the key-pair to be associated with a particular (id)entity. This mirrors the real-world patterns of reputation-based authentication.
The Account Authority Digital Signature Model (AADS) is a cut-down variant of conventional digital signature processes, applicable to communications among parties that have well-established relationships (i.e. already have 'accounts' with one another), and who have already received and stored one another's public keys (Wheeler 1998, Wheeler & Wheeler 1998). This obviates the need for public keys and key certificates to be transmitted with each message, and thereby avoids some of the problems inherent in X.509.
However, many of the challenges remain, such as how keys are securely generated, stored, backed-up and recovered, and revoked. Furthermore, the approach involves the recipient of a message acquiring the public key of the sender through some process that is 'out of band' (i.e. unspecified).
Simple Public Key Infrastructure (SPKI) was specified in the mid-1990s. See Ellison (1996), SPKI (1997-), Wang (1998), Ellison (1998), Ellison et al. (1999), RFC2692 (1999), RFC2693 (1999), Ellison (2000b) and Ellison (2001). In parallel, a team at MIT had been working on a Simple Distributed Security Infrastructure (SDSI). SDSI v.2 incorporates the SPKI concepts. See SDSI (1996-), Rivest & Lampson (1996), Ellison (2000b) and Ellison (2001). Both SPKI and SDSI are oriented towards authorisation, with authentication as a service to access control.
The key element of SDSI is that the X.509 nirvana of a single, global name-space has been abandoned. With it, the presumption has been removed that 'name' (or, better expressed, 'identifier') is reliably bound to a particular entity. Identifiers are unique locally, but not necessarily globally; and hence the approach scales easily. CAs are not necessary, so there is no hierarchical global infrastructure, and each entity can issue certificates.
The certificate, which has its own format-specification, associates a public key (and hence a key-pair) to an entity that only the certificate-issuer knows, and no warranties are provided by the certificate-issuer to the recipient of the message as to who or what the keyholder is. It is up to the relying party to build up an image of the sender based on its successive interactions with the holder of that key. This encourages application-level design, based on the requirements of the particular context.
Attributes are associated with public keys, not with (id)entities. Hence, for example, a recipient can be assured that a particular message was provided by a medical practitioner, or a person over 18, or over 65; but the certificate is silent about the (id)entity of the person who is using the key (Ellison 2000). SPKI and hence SDSI certificates are described in RFC2692 (1999) and RFC2693 (1999).
SPKI/SDSI can also address revocation of key-pairs more effectively than conventional PKI, through the notion of a 'suicide note', pre-signed at the time the pair was generated, which is only despatched in the event that the key-holder discovers that the private-key has been compromised.
Brands (2000) proposes a different conception and implementation of digital certificates, such that privacy is protected without sacrificing security. The validity of such certificates and their contents can be checked, but the identity of the certificate-holder cannot be extracted, and different actions by the same person cannot be linked. Certificate holders have control over what information is disclosed, and to whom.
Brandsian private credentials are fundamentally anonymous, although implementations can be devised to achieve pseudonymity or identification. They "fully preserve privacy, without sacrificing security. The new certificates function in much the same way as do cash, stamps, cinema tickets, subway tokens, and so on: anyone can establish the validity of these certificates and the data they specify, but no more than that. Furthermore, different actions by the same person cannot be linked [except where that is expressly designed into the application]" (2000, p. viii).
The basic definition of the Brandsian 'secret-key certificate' is in Brands (2000, pp. 74-77). Details are in a patent filed in 1994, and are explained through the remainder of Brands (2000) and in Brands (2001). Among other features of Brandsian certificates, "certificate holders can decide for themselves, depending on the circumstances, which property they disclose of the data encoded into their certificates. Also, a certificate can be presented in such a manner that the organisation is left with no evidence at all of the transaction, or only with self-authenticating evidence of a message or a part of the disclosed property. Furthermore, the self-authenticating evidence can be limited to designated parties" (2000, p. ix).
Brandsian certificates may attest to the holder's (id)entity (where that is what the application calls for), but more generally attest to the (unidentified) holder having one or more specific attributes that are relevant to the transaction. They encompass conventional X.509v3 digital certificates as a special case (Brands 2000, p.29). They may be used over an extended period (in which case the scope for a dossier to be constructed increases, because each use of the same certificate carries the same public key). Alternatively, each certificate may be used only a few times, or just once, and the holder can obtain replacements for them (p. 166).
Brandsian Private Credentials represent a superior alternative to conventional approaches to PKI. Their cryptographic design provides the following significant advantages:
To date, there have been a small number of implementations of Brandsian private credentials, but knowledge about them has not yet become widespread.
There has been speculation for some time that a measure of a human could be used as a key, in order to enhance the quality of digital signatures, or even as a basis for generating keys. See, for example, Daugman (1999).
The proposition is seriously problematical, however. A biometric is not a secret, because it is open to the world. It is also not a constant, fixed value, because measurements of the underlying physiological characteristic vary. For both reasons, it is not appropriate to use a biometric as a private key.
An alternative would be to use it as a public key. A single measure could be provided by the individual to recipients of messages. A private key could be generated from the public key/biometric, and used to sign messages. But a vital assumption underlying public key cryptography is that one key cannot be derived from the other, i.e. they must be generated as a pair from the same process. Moreover, it is fundamental that a key-pair has to be able to be revoked, and replaced by another, if it is compromised.
It would appear unlikely that biometrics could be of direct value as a basis for digital signatures. They may, on the other hand, be of considerable value as a more effective means than passwords and PINs for protecting the private signing key.
This paper has expressed a set of requirements, reflecting both business and public policy perspectives, and based upon a comprehensive model of authentication.
An evaluation of X.509-based PKI has concluded that they match poorly against those requirements. In addition, experience with them has shown them to be disappointingly complex, slow to develop and deploy, expensive, and subject to both technical and legal deficiencies. Moreover, claims about the assurances that X.509 certificates provide are generally highly exaggerated, and the terms offered by certificate-providers offer very little comfort to the parties that need to rely on them. On top of all of those problems, many schemes using conventional PKI are highly privacy-intrusive, and frequently far more so than is justified in the particular circumstances in which they are employed. Conventional X.509-based PKI are untenable, except in the very specific circumstances described in the paper.
Some alternative approaches appear to be much more suitable as a means of satisfying the requirements of business and public policy. Attention is drawn in particular to SPKI/SDSI and to Brandsian Private Credentials.
Public key technology in general appears to make some fundamental assumptions about the real world that are not reasonable. There is an urgent need for more, and more substantial, implementations of the alternative approaches, in order to assess whether they provide an appropriate basis for authentication of the wide variety of assertions relevant to e-business.
Adams C. & Lloyd S. (1999) 'Understanding the Public-Key Infrastructure' New Riders Publishing, 1999
A. Aresenault A. & Turner S. (1999-2001) 'Internet X.509 Public Key Infrastructure: Roadmap' Version of November 2000, private communication, sometimes available from http://www.imc.org/draft-ietf-pkix-roadmap
Austin T. (2000) `PKI: A Wiley Tech Brief` Wiley, 2000
Blaze M. (1999) 'Using the KeyNote Trust Management System', November 1999, at http://www.crypto.com/trustmgt/kn.html
Brands S.A. (2000) 'Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy' MIT Press, 2000
Brands S. (2001) 'A Technical Introduction to Private Credentials', 1 October 2001
CCIB (1998) 'Common Criteria for Information Technology Security Evaluation', Common Criteria Implementation Board, Version 2, 1998, at http://www.cse.dnd.ca/cse/english/cc2dwnld.html
Clarke R. (1988) 'Information Technology and Dataveillance' Commun. ACM 31,5 (May 1988). Re-published in C. Dunlop and R. Kling (Eds.) 'Controversies in Computing', Academic Press, 1991, at http://www.anu.edu.au/people/Roger.Clarke/DV/CACM88.html
Clarke R. (1992) 'Extra-Organisational Systems: A Challenge to the Software Engineering Paradigm' Proc. IFIP World Congress, Madrid, September 1992, at http://www.anu.edu.au/people/Roger.Clarke/SOS/PaperExtraOrgSys.html
Clarke R. (1994a) 'The Digital Persona and its Application to Data Surveillance', The Information Society 10, 2 (June 1994)', at http://www.anu.edu.au/people/Roger.Clarke/DV/DigPersona.html
Clarke R. (1994b) 'Human Identification in Information Systems: Management Challenges and Public Policy Issues', Information Technology & People 7,4 (December 1994) 6-37, at http://www.anu.edu.au/people/Roger.Clarke/DV/HumanID.html
Clarke R. (1995) 'When Do They Need to Know 'Whodunnit?' The Justification for Transaction Identification: The Scope for Transaction Anonymity and Pseudonymity' Proc. Conf. Computers, Freedom & Privacy, San Francisco, 31 March 1995, at http://www.anu.edu.au/people/Roger.Clarke/DV/PaperCFP95.html
Clarke R. (1996a) 'Message Transmission Security (or 'Cryptography in Plain Text')' Privacy Law & Policy Reporter 3, 2 (May 1996), pp. 24-27, at http://www.anu.edu.au/people/Roger.Clarke//II/CryptoSecy.html
Clarke R. (1996b) 'Identification, Anonymity and Pseudonymity in Consumer Transactions: A Vital Systems Design and Public Policy Issue' Proc. Conf. 'Smart Cards: The Issues', Sydney, 18 October 1996, at http://www.anu.edu.au/people/Roger.Clarke/DV/AnonPsPol.html
Clarke R. (1997) 'Electronic Publishing: A Specialised Form of Electronic Commerce' Proc. 10th Int'l Electronic Commerce Conf., Bled, Slovenia, June 1997, at http://www.anu.edu.au/people/Roger.Clarke/EC/Bled97.html
Clarke R. (1998) 'Public Key Infrastructure: Position Statement', May 1998, at http://www.anu.edu.au/people/Roger.Clarke/DV/PKIPosn.html
Clarke R. (1999a) 'The Real 'Who's Who' of Electronic Commerce: The Identification of Organisations', Working Paper available from the author, April 1999, at http://www.anu.edu.au/people/Roger.Clarke/EC/OrgID.html
Clarke R. (1999b) 'The Willingness of Net-Consumers to Pay: A Lack-of-Progress Report' Proc. Twelfth Int'l Bled Electronic Commerce Conf., Bled, Slovenia, June 7 - 9, 1999, at http://www.anu.edu.au/people/Roger.Clarke/EC/WillPay.html
Clarke R. (1999c) 'Electronic Services Delivery: From Brochure-Ware to Entry Points' Proc. 12th Int'l EC Conf., Bled, Slovenia, 8-9 June 1999, at http://www.anu.edu.au/people/Roger.Clarke/EC/ESD.html
Clarke R. (1999d) 'Identified, Anonymous and Pseudonymous Transactions: The Spectrum of Choice' Proc. User Identification & Privacy Protection Conf., Stockholm, 14-15 June 1999, at http://www.anu.edu.au/people/Roger.Clarke/DV/UIPP99.html
Clarke R. (2000) 'Privacy Requirements of Public Key Infrastructure' Internet Law Bulletin 3, 1 (April 2000) 2-6. Republished in 'Global Electronic Commerce', published by the World Markets Research Centre in collaboration with the UN/ECE's e-Commerce Forum on 'Electronic Commerce for Transition Economies in the Digital Age', 19-20 June 2000, at http://www.anu.edu.au/people/Roger.Clarke/DV/PKI2000.html
Clarke R. (2001a) 'Introduction to Information Security', February 2001, at http://www.anu.edu.au/people/Roger.Clarke/EC/IntroSecy.html
Clarke R. (2001b) 'Towards a Taxonomy of B2B e-Commerce Schemes' Proc. 14th Int'l EC Conf., Bled, Slovenia, 25-26 June 2001, at http://www.anu.edu.au/people/Roger.Clarke/EC/Bled01.html
Clarke R. (2001c) 'The Fundamental Inadequacies of Conventional Public Key Infrastructure' Proc. Conf. ECIS'2001, Bled, Slovenia, 27-29 June 2001, at http://www.anu.edu.au/people/Roger.Clarke/II/ECIS2001.html
Clarke R. (2001d) 'Person-Location and Person-Tracking: Technologies, Risks and Policy Implications' Information Technology & People 14, 2 (Summer 2001) 206-231. Original version in Proc. 21st International Conference on Privacy and Personal Data Protection, pp.131-150, Hong Kong, 13-15 September 1999, at http://www.anu.edu.au/people/Roger.Clarke/DV/PLT.html
Clarke R. (2001e) 'Authentication: A Sufficiently Rich Model to Enable e-Business' , November 2001, at http://www.anu.edu.au/people/Roger.Clarke/EC/AuthModel.html
Daugman J. (1999) 'Biometric decision landscapes" Technical Report No. TR482, University of Cambridge Computer Laboratory, at http://www.cl.cam.ac.uk/users/jgd1000/biomdecis.pdf
Davis D. (1996) `Compliance Defects in Public-Key Cryptography` Proc. 6th Usenix Security Symp., San Jose CA, 1996, pp.171-178, at http://world.std.com/~dtd/compliance/compliance.pdf
Denning D.E. & MacDoran P.F. (1996) 'Location-Based Authentication: Grounding Cyberspace for Better Security' Computer Fraud & Security, February 1996, at http://www.cs.georgetown.edu/~denning/infosec/Grounding.txt
Diffie W. & Hellman M. (1976) 'New directions in cryptography' IEEE Transactions on Information Theory IT-22 (November 1976) 644-654
Ellison C. (1996) 'Establishing Identity Without Certification Authorities', Proc. 6th USENIX Security Symposium, San Jose CA, July 22-25, 1996, at http://world.std.com/~cme/usenix.html
Ellison C. (1997) 'What do you need to know about the person with whom you are doing business?' Written testimony of Carl M. Ellison to the U.S. House of Representatives Science and Technology Subcommittee, Hearing of 28 October 1997: Signatures in a Digital Age, at http://world.std.com/~cme/html/congress1.html
Ellison C. (1998) 'SPKI Examples', March 1998, at http://world.std.com/~cme/examples.txt
Ellison C. (1999) 'The nature of a usable PKI' Computer Networks 31 (1999) 823-830
Ellison C. (2000a) 'Naming and Certificates', Proc. Computers, Freedom & Privacy 2000, at http://www.cfp2000.org/papers/ellison.pdf
Ellison C. (2000b) 'SPKI/SDSI and the Web of Trust' September 2000, at http://world.std.com/~cme/html/web.html
Ellison C. (2001) 'SPKI/SDSI Certificates' 21 September 2001, at http://world.std.com/~cme/html/spki.html
Ellison C., Frantz B., Lampson B, Rivest R., Thomas B. & Ylonen T. (1999) `Simple Public Key Certificate' The Internet Society, July 1999, at http://world.std.com/~cme/spki.txt
Ellison C. & Schneier B. (2000a) 'Risks of PKI: Electronic Commerce' Inside Risks 116, Commun. ACM 43, 2 (February 2000), at http://www.counterpane.com/insiderisks5.html
Ellison C. & Schneier B. (2000b) 'Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure' Computer Security Journal, v 16, n 1, 2000, pp. 1-7, at http://www.counterpane.com/pki-risks.html
Ford W. & Baum M.S. (1997) 'Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption', Prentice Hall, 1997
Froomkin A.M. (1995) 'Anonymity and Its Enmities' 1995 J. Online L., at http://www.law.cornell.edu/jol/froomkin.htm
GAO (2001) 'Information Security: Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology', U.S. General Accounting Office, GAO-01-277, February 2001, at http://www.gao.gov/new.items/d01277.pdf
Gerck E. (1997) 'Certification: Extrinsic, Intrinsic and Combined', July, 1997, at http://www.mcg.org.br/cie.htm
Gerck E. (1997-2000) 'Overview of Certification Systems: X.509, CA, PGP and SKIP', First published April 17, 1997, revisions to 18 July 2000, at http://www.mcg.org.br/certover.pdf
Greenleaf G.W. & Clarke R. (1997) 'Privacy Implications of Digital Signatures', Proc. IBC Conference on Digital Signatures, Sydney, March 1997, at http://www.anu.edu.au/people/Roger.Clarke/DV/DigSig.html
Grossman W. (2000) 'Circles of Trust', Scientific American, August 2000, at http://www.sciam.com/2000/0800issue/0800cyber.html
Gutmann P. (2000) 'X.509 Style Guide', at http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
Hill C. (2001) 'Risk of Masquerade Arising from the Storage of Biometrics', Honours Thesis, Dept of Computer Science, Australian National University, November 2001
IMC (1999) 'S/MIME and OpenPGP', Internet Mail Consortium, July 1999, at http://www.imc.org/smime-pgpmime.html
ITSEC (1991) 'Information Technology Security Evaluation Criteria (ITSEC): Harmonised Criteria of France, Germany, the Netherlands and the United Kingdom', Version 1.2, Commission of the European Communities, June 1991, at http://www.itsec.gov.uk/docs/
Kaiser T. (2000) 'Secure Storage of Private Keys on Commodity Workstations', Unpublished Honours Thesis, Department of Computer Science, Australian National University, November 2000
Khare R. & Rifkin A. (1997) 'Weaving a Web of Trust' Revised version of a paper in World Wide Web Journal 2 3 (Summer 1997) 77-112, at http://www.cs.caltech.edu/~adam/local/trust.html
Kohnfelder, L. M. (1978) 'Towards a Practical Public-key Cryptosystem' MIT S.B. Thesis, May 1978
Maurer U. (1996) 'Modelling a Public-Key Infrastructure' Proc. 1996 European Symposium on Research in Computer Security (ESORICS' 96), Lecture Notes in Computer Science, Springer-Verlag, vol. 1146, pp. 325-350, 1996, at ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/wwwisc/Maurer96b.pdf
NIST (2000) 'Federal Agency Use of Public Key Technology for Digital Signatures and Authentication' National Institute of Standards, NIST Special Publication 800-25, October 2000, at http://csrc.nist.gov/publications/nistpubs/800-25/sp800-25.pdf
OGIT (1998) `Gatekeeper: A strategy for public key technology use in the Government', Office of Government Information Technology, May 1998, at http://www.ogo.gov.au/projects/publickey/Gatekeeper.htm
OpenPGP (2001) 'An Open Specification for Pretty Good Privacy (openpgp)' Internet Engineering Task Force of The Internet Society, at http://www.ietf.org/html.charters/openpgp-charter.html
PKIX (1993-) `PKIX Working Group', at http://www.imc.org/ietf-pkix/
PKIX (1995-) 'Public-Key Infrastructure (X.509) (pkix)', at http://www.ietf.org/html.charters/pkix-charter.html
RFC1847 (1995) 'Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted' Internet Engineering Task Force of The Internet Society, October 1995, at ftp://ftp.isi.edu/in-notes/rfc1847.txt
RFC2015 (1996) 'MIME Security with Pretty Good Privacy (PGP)' Internet Engineering Task Force of The Internet Society, October 1996, at ftp://ftp.isi.edu/in-notes/rfc2015.txt
RFC2246 (1999) 'The TLS Protocol' Internet Engineering Task Force of The Internet Society, January 1999, at ftp://ftp.isi.edu/in-notes/rfc2246.txt
RFC2440 (1998) 'OpenPGP Message Format', Internet Engineering Task Force of The Internet Society, November 1998, at ftp://ftp.isi.edu/in-notes/rfc2440.txt
RFC2459 (1999) 'Internet X.509 Public Key Infrastructure Certificate and CRL Profile' Internet Engineering Task Force of The Internet Society, January 1999, at http://www.ietf.org/rfc/rfc2459.txt
RFC2487 (1999) 'SMTP Service Extension for Secure SMTP over TLS' Internet Engineering Task Force of The Internet Society, January 1999, at http://www.ietf.org/rfc/rfc2487.txt
RFC2510 (1999) 'Internet X.509 Public Key Infrastructure: Certificate Management Protocols', Internet Engineering Task Force of The Internet Society, March 1999, at ftp://ftp.isi.edu/in-notes/rfc2510.txt
RFC2511 (1999) 'Internet X.509 Certificate Request Message Format', Internet Engineering Task Force of The Internet Society, March 1999, at ftp://ftp.isi.edu/in-notes/rfc2511.txt
RFC2527 (1999) 'Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework', Internet Engineering Task Force of The Internet Society, March 1999, at ftp://ftp.isi.edu/in-notes/rfc2527.txt
RFC2560 (1999) 'X.509 Internet Public Key Infrastructure: Online Certificate Status Protocol - OCSP' Internet Engineering Task Force of The Internet Society, June 1999, at http://www.ietf.org/rfc/rfc2560.txt
RFC2595 (1999) 'Using TLS with IMAP, POP3 and ACAP' Internet Engineering Task Force of The Internet Society, June 1999, at http://www.ietf.org/rfc/rfc2595.txt
RFC2632 (1999) 'S/MIME Version 3 Certificate Handling' Internet Engineering Task Force of The Internet Society, June 1999, at ftp://ftp.isi.edu/in-notes/rfc2632.txt
RFC2633 (1999) 'S/MIME Version 3 Message Specification' Internet Engineering Task Force of The Internet Society, June 1999, at ftp://ftp.isi.edu/in-notes/rfc2633.txt
RFC2692 (1999) 'SPKI Requirements' Internet Engineering Task Force of The Internet Society, September 1999, at ftp://ftp.isi.edu/in-notes/rfc2692.txt
RFC2693 (1999) 'SPKI Certificate Theory' Internet Engineering Task Force of The Internet Society, September 1999, at ftp://ftp.isi.edu/in-notes/rfc2693.txt
RFC2704 (1999) 'The KeyNote Trust-Management System Version 2' Internet Engineering Task Force of The Internet Society, September 1999, at http://www.crypto.com/papers/rfc2704.txt
RFC2828 (2000) `Internet Security Glossary' Internet Engineering Task Force of The Internet Society, 2000, at ftp://ftp.isi.edu/in-notes/rfc2828.txt
RFC3039 (2001) `Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' Internet Engineering Task Force of The Internet Society, 2001, at ftp://ftp.isi.edu/in-notes/rfc3039.txt
Rivest R.L. & Lampson B. (1996) 'SDSI - A Simple Distributed Security Infrastructure', 15 Sep 1996, at http://theory.lcs.mit.edu/~rivest/sdsi10.html
RSA (2001) 'RSA Laboratories Frequently Asked Questions About Today's Cryptography 4.1' RSA Laboratories, at http://www.rsasecurity.com/rsalabs/faq/sections.html
Schneier B. (1996) 'Applied Cryptography' Wiley, 2nd Ed., 1996
Schneier B. (2000) 'Why Digital Signatures Are Not Signatures` Crypto-Gram 15 November 2000, at http://www.counterpane.com/crypto-gram-0011.html
SDSI (1996-) 'A Simple Distributed Security Infrastructure (SDSI)', 1996-, at http://theory.lcs.mit.edu/~cis/sdsi.html
Smith A.O. & Clarke R. (1999) 'Identification, Authentication and Anonymity in a Legal Context', Proc. IFIP User Identification & Privacy Protection Conference, Stockholm, June 1999, at http://www.anu.edu.au/people/Roger.Clarke/DV/AnonLegal.html (primary author A. Smith). Republished in Computer Law & Security Report 16, 2 (March/April 2000) CLSR 95-101
Sneddon M. (2000) 'Legal Liability and e-Transactions` National Electronic Authentication Council, Canberra, Australia, August 2000, at http://www.noie.gov.au/publications/NOIE/NEAC/publication_utz1508.pdf
SPKI (1997-) 'Simple Public Key Infrastructure (SPKI)', at http://www.ietf.org/html.charters/spki-charter.html
SSL (1996) 'The SSL Protocol, Version 3.0', Draft Internet Standard of the Transport Layer Security Working Group, Internet Engineering Task Force of The Internet Society, November 1996, at http://home.netscape.com/eng/ssl3/draft302.txt
S/MIME (2001) 'S/MIME Mail Security (smime)' Internet Engineering Task Force of The Internet Society, at http://www.ietf.org/html.charters/smime-charter.html
TCSEC (1985) 'Trusted Computer System Evaluation Criteria', U.S. Department of Defense, at http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
W3C (1999-) 'XML-Signature WG', at http://www.w3.org/Signature/
W3C (2001) 'XML-Signature Syntax and Processing' W3C Proposed Recommendation, 20 August 2001, at http://www.w3.org/TR/xmldsig-core/
Wang Y. (1998) 'SPKI' December 1998, at http://www.hut.fi/~yuwang/publications/SPKI/SPKI.html
Wheeler L. (1998) 'Account Authority Digital Signature Model (AADS)', at http://www.garlic.com/~lynn/aadsover.htm
Wheeler A. & Wheeler L. (1998) 'PKI Account Authority Digital Signature Infrastructure', November 1998, at http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
Winn J.K. (2001) ,The Emperor's New Clothes: The Shocking Truth About Ditial Signatures and Internet Commerce` forthcoming, Idaho Law Review, 2001, at http://www.smu.edu/~jwinn/shocking-truth.htm
Xenitellis S. (2000) 'The Open-source PKI Book', 2000, at http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/pkix-concepts.htm
X.509 (1988, 1997) 'The Directory - Authentication Framework', Volume VIII of CCITT Blue Book, pp. 48-81, CCITT/ITU, 1988, 1997, v1 1988, v2 1993, v3 1996; most recent edition apparently dated 13 April 2000
Zimmermann P.R. (1995) 'PGP 5.0 User's Guide' MIT Press, 1995, at http://mitpress.mit.edu/book-home.tcl?isbn=0262740176
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.
From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 50 million in early 2015.
Sponsored by Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916
Created: 5 October 2001 - Last Amended: 22 December 2001 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/PKIReinv.html