Fw: FW: Fun PKI Article from Down Under

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

fyi -
----- Original Message -----
From: "Toby Brown" <toby@o2exchange.com>
To: <ST-ISC@MAIL.ABANET.ORG>
Sent: Monday, November 13, 2000 8:37 AM
Subject: FW: Fun PKI Article from Down Under


> In case people haven't seen this one.
>
>
>
> Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the
> Information Society
> Roger Clarke
>
> Principal, Xamax Consultancy Pty Ltd, Canberra
>
> Visiting Fellow, Department of Computer Science, Australian National
> University
>
> Prepared for submission to the 'IS in the Information Society' Track of
the
> Euro. Conf. in Inf. Syst. (ECIS 2001), Bled, Slovenia, 27-29 June 2001
>
> Version of 9 November 2000
>
> © Xamax Consultancy Pty Ltd, 2000
>
> This document is at
> http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Abstract
> It has been conventional wisdom that, for e-commerce to fulfil its
> potential, each party to a transaction must be confident in the identity
of
> the others. Digital signature technology, based on public key
cryptography,
> has been claimed as the means whereby this can be achieved. Digital
> signatures do little, however, unless a substantial infrastructure is in
> place to provide a basis for believing that the signature means something
of
> significance to the relying party.
>
> Conventional, hierarchical PKI, built around the ISO standard X.509, has
> been, and will continue to be, a substantial failure. This paper examines
> that form of PKI architecture, and concludes that it is a very poor fit to
> the real needs of cyberspace participants. The reasons are its inherently
> hierarchical and authoritarian nature, the unreasonable presumptions it
> makes about the security of private keys, a range of other technical
> defects, confusions about what it is that a certificate actually
> authenticates, and its inherent privacy-invasiveness. Alternatives are
> identified.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Contents
> 1. Introduction
> 2. The Perceived Need
> 3. Conventional Technology
> 3.1 Digital Signatures
> 3.2 Public Key Infrastructure
> 3.3 The X.509v3 Standard
> 3.4 The Hierarchical Model of Trust and Liability
> 4. Private Key [In]Security
> 5. Other Technical Weaknesses in X.509
> 6. What Assurance Does an X.509v3 Certificate Actually Provide?
> 7. Privacy Concerns
> 8. Alternative Models of Trust
> 8.1 PGP's 'Web of Trust'
> 8.2 SPKI/SDSI
> 8.3 Stefan Brand's Alternative Certificates
> 8.4 Reputation and Brand
> 8.5 Nyms
> 8.6 Trust Management
> 9. Conclusions
> References
>
> --------------------------------------------------------------------------
--
> ----
>
> 1.Introduction
> There has been a perception that the adoption of e-commerce has been
> significantly slowed because, in cyberspace, buyers don't trust
> unidentifiable sellers. Digital signatures, and the mechanism that support
> them, Public Key Infrastructure (PKI), have been touted as the solution to
> the problem. Despite quite some years of development, however, each step
> forward with PKI seems to create a set of new sub-problems.
>
> Meanwhile, a range of other impediments to net-consumer trust of
cyberspace
> merchants has been identified (Clarke 1999c). And PKI has been criticised
on
> both technical grounds (e.g. Ellison and Schneier 2000) and privacy
grounds
> (e.g. Greenleaf & Clarke 1997). This paper examines PKI from a broader
> perspective, by relating its features to what the Information Society
really
> needs.
>
> The paper commences by stating the problem that was originally perceived,
> and describing the currently conventional technology that has been
harnessed
> to solve it. Major problems with that solution are then identified, in the
> areas of key insecurity, other technical deficiencies, its failure to
> provide useful assurances to net-users, and its privacy-invasiveness. The
> paper concludes by explaining the critical nature of 'nyms', and a brisk
> assessment of alternative approaches that hold out greater prospect for
> meeting the needs of Information Society.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 2. The Perceived Need
> The commercial potential of the Internet became apparent only in the
> mid-1990s. Wired Magazine, launched in October 1994, claimed (with
> justification) that its Hotwired venture was the first commercial
web-site.
>
> >From an early stage, the conventional wisdom was that e-commerce, in
> comparison with purchasing in a physical location like a shop, lacks the
> important comfort factor of seeing who you're dealing with, or at least
> being able to see the merchant's physical 'foot-print'. It was therefore
> postulated that successful commerce on public networks would be dependent
on
> some other means of establishing trust.
>
> A leap was then made to the conclusion that trust would need to be based
on
> a mechanism for the identification of parties who deal on the net,
> supplemented by authentication mechanisms to test the assertions of
> identity. A recent expression of this is that "Fundamentally, electronic
> commerce involves the use of remote communications and therefore
> necessitates all parties involved to authenticate one another ...
[because]
> the parties will not at the time of transacting have face to face
dialogue"
> (McCullagh & Caelli, 2000).
>
> Moreover, the demand for identity was presumed to be two-sided, i.e. not
> only would the merchant or services-provider identify themselves to the
> consumer but consumers would also identify themselves to sellers. It is
> unclear whether this was a conscious assumption, and if so whether it was
> based on an analysis of merchant behaviour, or was merely a pretext for
the
> creation of exploitable trails of consumer behaviour. Either way, it
> represents a significant compromise of what have hitherto been to a
> considerable extent anonymous transactions.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3. Conventional Technology
> This section provides a brief overview of the key technologies that have
> enabled engineers to address the perceived problem described above.
>
> During the 1980s, public key (or 'asymmetric') cryptography had emerged.
> Public key cryptography involves two related keys, referred to as a
> 'key-pair', one of which only the owner knows (the 'private key') and the
> other which anyone can know (the 'public key'). Because only one party
needs
> to know the private key, it does not need to be transmitted between
parties,
> and hence it need never be exposed to the risk of interception. Knowledge
of
> the public key by a third party, on the other hand, does not compromise
the
> security of message transmissions (Diffie & Hellman 1976, Schneier 1996).
> For a tutorial treatment, see Clarke 1996).
>
> The following sub-sections introduce the key application of 'digital
> signatures', and then the infrastructure on which they depend. The
dominant
> form of public key infrastructure is then outlined and interpreted.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.1 Digital Signatures
> Digital signatures are a particular application of public key
cryptography.
> A digital signature is a block of data that is generated from a message
> prior to its despatch, and is appended to it. The block is prepared by a
> two-step process:
>
> a 'message digest' is created by processing the actual message using a
> pre-agreed one-way hash algorithm; and
> this message digest is encrypted with the sender's private key.
> The recipient re-creates the message digest from the message that they
> receive, uses the sender's public key to decrypt the digital signature
that
> they received appended to the message itself, and compares the two
results.
> If they are identical, then:
>
> the content of the message received must be the same as that which was
sent
> (assuring message content integrity);
> the message can only have been sent by the purported sender (providing a
> means of authentication); and
> the sender cannot credibly deny that they sent it (addressing the need for
> non-repudiatiability of messages).
> This paper concerns itself with only the second of these, the use of a
> digital signature to authenticate something about the message-sender.
>
> Digital signatures were naively presumed by many people to provide
> unqualified assurance. In practice, however, the effectiveness of the
> mechanism is dependent on a number of conditions, in particular:
>
> a third party must have checked that the private key is in the possession
of
> the appropriate party;
> that third party must be trustworthy;
> the private key must be subject to strong security measures, such that no
> other party can ever gain access to it or invoke it;
> the public key used must be the appropriate one, and not one provided by
an
> imposter; and
> a number of infrastructural elements must all be in place, functioning
> effectively, and their security not compromised.
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.2 Public Key Infrastructure
> Digital signature schemes depend on the public key of the message-sender
> being available to the recipient. The most practicable methods of
achieving
> this are:
>
> senders can include their public keys in each message;
> senders can store them at a site that is readily accessible (e.g. using
FTP
> or HTTP); or
> public keys may be stored in one or more centrally managed directories,
> enabling each party to an exchange to look up the public key of the other
> party.
> All of these approaches are subject to 'spoofing', i.e. an imposter can
send
> a message that includes a public key, or store a public key in a
directory,
> and thereby fool the other party into thinking the message came from a
> particular person or organisation.
>
> To address this risk, the concept was created of a 'certificate' that
> attests to the fact that that public key is associated with a particular
> party. (The technical literature uses the term 'is bound to' rather than
'is
> associated with'. This implies to the normal reader a far stronger kind of
> association than the technique actually warrants).
>
> More precisely, a 'certificate' is a digitally signed, structured message
> that asserts an association between specific data and a particular public
> key. An 'identity certificate' is then a particular class of certificate
> that associates a particular identifier with a particular public key. (It
> will be argued later in this paper that the term 'identifier' should
really
> be replaced by 'nym'). Regrettably, most of the literature uses the term
> 'certificate' to refer to both of these concepts, often in the same
> sentence, despite the fact that the differences are extremely important.
>
> According to conventional thinking, a certificate needs to be created by a
> trusted 'public key certification authority' (CA). A CA digitally signs
each
> certificate using its own private key. In most schemes, that certificate
is
> provided to the party that claims the particular key to be its own, who
> includes it in the messages that they send. A message with a CA's
> certificate attached therefore functions in a manner analogous to a letter
> applying for a job being accompanied by a letter from a referee attesting
to
> something about the applicant, such as their identity, their good
character,
> their experience, or their qualifications.
>
> A CA needs to undertake some form of authentication process in order to
> satisfy itself that the claimed association actually exists. A
conventional
> approach is to depend on the services of a Registration Authority (RA),
such
> as a Post Office. A comprehensive process would require the person with
whom
> the key is to be associated to undertake all of the following:
>
> present themselves at the RA's premises;
> provide physical evidence of the characteristic claimed. This would
> typically involve 'photo-id', and documentary evidence of (for example)
age,
> qualifications and/or professional membership, supported by a documentary
> trail evidencing the use of the relevant identifier(s) over a period of
time
> (including, for example, marriage certificate or deeds poll);
> provide the public-key;
> provide evidence that they are the holder of the private-key (e.g. by
> signing a message in the presence of the RA);
> provide evidence that they have the private-key secure;
> nominate a contact-point; and
> nominate a delivery-point for the certificate.
> Because of the effort and expense involved, the onerousness and the
> demeaning nature of the process, schemes generally compromise on these
> requirements. Many ignore them almost entirely by, for example, depending
on
> some prior relationship between the person and the RA or CA.
>
> CAs deflect attention from the critical weaknesses of their registration
> processes by drawing attention to the physical and electronic security of
> the facilities that they use to generate the certificate.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.3 The X.509v3 Standard
> The dominant standard at present is the family of CCITT X.500 standards,
in
> particular X.509 (X.509 1988, Housley et al. 1999). The current version of
> X.509 is number 3, usually referred to as X.509v3, which was finalised in
> 1997. A set of standards, dubbed PKIX, enables use of X.509 approaches
> within the web-context (W3C 2000). Guidance has been provided by texts
such
> as Ford & Baum (1997), Adams & Lloyd (1999) and Austin et al. (2000).
>
> Ellison (1997) describes the history this way: "the X.500 proposal was
> published [in the late 1980s]. It was to be a global directory of named
> entities. To tie a public key to some node or sub-directory of that
> structure, the X.509 certificate was defined. The Subject of such a
> certificate was a path name indicating a node in the X.500 database - a
> so-called 'Distinguished Name'. The X.500 dream has effectively died but
the
> X.509 certificate has lived on. 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 ...". In short, X.509 was the
> hammer that came to hand when the nail was discovered.
>
> All forms of PKI necessarily involve some degree of intrusiveness, in
order
> that sufficient quality can be achieved. Conventional PKI, built around
> X.509v3 certificates, is especially severe. Implementations commonly have
> many of the following features:
>
> a single key-pair per person;
> a 'distinguished name' that is unique across a name-space that is in
> principle vast, and in practice large, and that denies the opportunity for
> pseudonyms;
> a certificate that expressly claims to 'bind' the key to a person;
> little or no choice in the manner in which the key-pair is generated;
> in many cases, generation of the key-pair outside the control of the
person
> concerned, with the result that the private key is ab initio in someone
> else's possession;
> issuer-ownership of the key-pair, with individuals merely licensed to use
> it;
> little or no choice as to what token (such as a diskette or chip-card) is
> used to store and carry the private-key and certificates;
> little or no choice as to who will issue the token;
> issuer-ownership of the token, with individuals merely licensed to use it;
> little or no choice in the organisation from which the individual acquires
a
> certificate; and/or
> a hierarchy of certificate authorities.
> Current X.509v3 certificates go so far as to permit an agent of an
> organisation to protect their personal identity through the use of a
> role-title; but they actually preclude an individual (referred to as a
> 'residential person') from having that capability. 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.
>
> Some schemes even involve the key-pair generation process being
compulsorily
> performed by some organisation on behalf of individuals, and compulsory
> storage (or 'escrow') of the private key.
>
> X.509v3 certificates provide a limited means for communicating attributes,
> within the primary certificate or through the creation of secondary
> certificates which may attest to one or more characteristics of the
> individual. But the attributes are inherently linked to and dependent on
the
> primary certificate, which bears the individual's identifier.
>
> Given the nature of X.509v3-based PKI, individuals, including not only
> consumers, but also employees and contractors, especially those in
sensitive
> occupations, are justified in having serious concerns about schemes of
this
> nature being inflicted upon them.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.4 The Hierarchical Model of Trust and Liability
> X.509v3-based PKI is inherently hierarchical. This is because trust in the
> CA is not automatic, and each layer of CAs needs to be attested to by some
> superior layer. Conventional PKI therefore depends on one partly but not
> entirely trusted third party, which in turns depends on another such
partly
> but not entirely trusted third party, which needs to be attested to be
some
> further superior layer. This results in an unholy spiral up to some
mythical
> authority in which everyone is assumed to have ultimate trust. Trust in
the
> real world has never worked like that, and trust in cyberspace won't
either.
>
> Such shemes can also be readily argued to be authoritarian in nature
(Clarke
> 1994b). For example, there is an intrinsic assumption that all parties
> providing certificates are required to disclose their identity, even if
the
> only functional need is to communicate eligibility (e.g. age, their age,
> qualifications, or agency relationship with a principal).
>
> The further assumption is made that the 'distinguished name' has to be
> unique within the 'name-space'. This precludes the second and subsequent,
> say John Robinson, from using their own name without some kind of
qualifier.
> It also provides no basis for individuals to use alternative identifiers,
> and implicitly denies individuals the capability to have and use multiple
> key-pairs, and multiple certificates. The engineers who created the X.509
> standard appear to have been blithely unaware that multiple identities per
> person are entirely legal in many jurisdictions, including those whose
legal
> systems derive from the United Kingdom (Clarke 1994c).
>
> A further feature of schemes of this kind is an implicit assumption that a
> CA will provide some form of warranty and/or indemnity to accompany the
> assurance, i.e. to recognise financial liability in the event that the
> assurance transpires to be incorrect, and that a party's reasonable
> dependence on the assurance resulted in economic cost. In practice,
however,
> CAs are very eager to phrase what are commonly termed 'Certificate Policy
> Statements' in such a manner that they minimise their exposure.
>
> With some qualifications, X.509v3 architectures are designed work within
an
> 'absolute trust' view of security, rather than a 'risk-management'
approach.
> On the other hand, actual implementations tend to compromise this,
sometimes
> severely. In particular, most operational schemes have only one layer of
CA,
> and the basis on which each recipient of a message is supposed to trust
> those CAs is a 'self-signed' certificate, i.e. blind trust in the company,
> its intentions, and its procedures.
>
> For whatever reason, the major implementations of X.509-based PKI, such as
> that based on the Verisign certificates embedded in commercially-available
> web-browsers, are at best 'relaxed' applications of formal X.509
standards,
> and hence the current PKI is even less meaningful than that which would be
> feasible if it was applied as intended.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 4. Private Key [In]Security
> Underlying digital signatures and PKI is the assumption that the holder of
a
> private key will be able to ensure its security. During the 1999-2000
> period, corporate servers have been subject to a rash of electronic
> break-ins. The ease with which many of these have been performed have
> demonstrated the serious inadequacy of the precautions taken by
> organisations of all kinds and all sizes.
>
> To date, it does not appear that private keys have been a particular
target
> of the crackers. There are likely to have been multiple reasons for this,
> not least the relatively small usage of private keys, and the fact that
> there have been plenty of more attractive items of data to aim for. As and
> when private digital signature keys attract more attention, it is
reasonable
> to expect that more attacks will be made, and that many corporate keys
will
> be compromised.
>
> Conventional PKI also assumes that consumers and citizens will have, and
> will need to use, private keys. The author has recently supervised a
project
> to examine the scope for consumers to protect their keys within 'commodity
> workstations', such as Windows, MacOS and Linux machines directly
connected
> to the Internet via commercial Internet access service providers (Kaiser
> 2000). In general, commodity workstations have very limited security
> features within the available hardware or systems software. There are few
> products available that would enable consumers to graft security features
on
> to their work-and-play facilities, and such products as exist require
> considerable expertise to install and configure.
>
> Private keys are susceptible to a vast array of risks, both of capture,
and
> of invocation without the authority of, or even knowledge of, the
> consumer/citizen. As Ellison & Schneier (2000b) put it: "Alice's digital
> signature does not prove that Alice signed the message, only that her
> private key did. When writing about non-repudiation, cryptographic
theorists
> often ignore a messy detail that lies between Alice and her key: her
> computer. If her computer were appropriately infected, the malicious code
> could use her key to sign documents without her knowledge or permission.
> Even if she needed to give explicit approval for each signature (e.g., via
a
> fingerprint scanner), the malicious code could wait until she approved a
> signature and sign its own message instead of hers. If the private key is
> not in tamper-resistant hardware, the malicious code can just steal the
key
> as soon as it's used".
>
> In short, the context of use of digital signatures is such that very
little
> confidence can be placed in the meaningfulness and reliability of
> authentication processes that depend on them.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 5. Other Technical Weaknesses in X.509
> A range of other difficulties have been identified (Ellison & Schneier
> 2000).
>
> For example, there are difficulties in detecting that a private key has
been
> compromised, and after that there are difficulties in implementing an
> effective revocation process. This is especially serious if retrospective
> revocation is permitted (i.e. notification to a set of recipients that a
> private key had been compromised since some past time, and that the sender
> reserves the right to repudiate transactions signed after that time).
> Time-stamping is a critical aspect of revocation processes; but it is not
an
> assured, secure service.
>
> Another issus is that X.509-based PKI assumes either that there is a
single
> global name-space (i.e. world government, and a single, unique identifier
> imposed on every citizen of the world), or that multiple name-spaces
exist,
> but that they inter-operate (and that each regional authority imposes a
> single, unique identifier on every person under their jurisdiction).
>
> Ellison (1996) long ago concluded that "if the bond between key and person
> is broken, no layer of certificates will strengthen it. On the contrary,
in
> this case certificates merely provide a false sense of security to the
> [recipient]".
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 6. What Assurance Does an X.509v3 Certificate Actually Provide?
> The final issue strikes at the very heart of PKI. The presumption made by
> most commentators is that a certificate provides the message-recipient
with
> assurance that the sender was indeed who the sender purports to be. But
that
> is not the case.
>
> The concept of 'authentication' has been seriously misunderstood by the
> designers of X.509-based PKI. Authentication is a process whereby a degree
> of confidence is established in the truth of an assertion. There are many
> kinds of assertions that can be the subject of authentication processes.
> Among them are assertions of the form 'this artefact has a value
equivalent
> to so much of a particular currency', and 'the sender of this message has
a
> credential that attests to their eligibility to perform a particular
> function'.
>
> In order to discuss the real meaning of a certificate, some definitions of
> terms are needed:
>
> an entity is a real-world thing. A pallet, a package and a widget are
> examples of entities that are generally not relevant in the current
context;
> whereas a person, an organisation, and an artefact that is capable of
taking
> a relevant action (e.g. a hardware-server, a software-server, a
> hardware-client, a software-client, a software agent) are of direct
> relevance. An entity is not capable of being directly expressed as data;
> an identity is a defined and specific instance of a class of entity (e.g.
a
> particular person, organisation, computer or software process). Each
entity
> has precisely one identity. An identity is not capable of being directly
> expressed as data;
> an identifier is a data-item or group of data-items which reliably
> distinguish the identity of an entity. An identity may have many
identifiers
> (i.e. the mapping is 1:n). (Note that, in most of the literature relating
to
> digital signatures, certificates and PKI, the term 'name' is used
variously
> to refer to a specific kind of identifier and to refer to identifiers
> generally).
> One (but only one) kind of assertion that may be subject to authentication
> is 'the sender of this message is the (or an) entity that uses a
particular
> identifier'.
>
> But a certificate doesn't attest to that. It does attest that:
>
> a particular message was generated by an artefact that had available to it
a
> particular key; and
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that private key to be associated with a particular
> entity.
> Depending on the registration process that was applied, it may also attest
> that:
>
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that the entity had some kind of right to use that
> identifier, or had used that identifier in the past; and
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that the entity had access to the appropriate
private
> key.
> A certificate provides no assurance about whether:
>
> the private key was originally available to other entities as well as the
> entity to which it purports to be 'bound';
> the private key is now available to other entitiess as well as the entity
to
> which it purports to be 'bound';
> the private key invocation that gave rise to a particular message was
> performed with the entity's free and informed consent.
> Morover, such assurance as a certificate provides is qualified by terms
> dictated by the CA's lawyers; and very limited recourse is available
should
> the assurance be wrong.
>
> McCullagh & Caelli (2000) argue that "In the legal sense an alleged
> signatory to a document is always able to repudiate a signature that has
> been attributed to him or her. The basis for a repudiation of a
traditional
> signature may include:
>
> The signature is a forgery;
> The signature is not a forgery, but was obtained via:
> Unconscionable conduct by a party to a transaction;
> Fraud instigated by a third party; [or]
> Undue influence exerted by a third party.
> "There is a strong movement to legally reverse the onus of proof for
digital
> signatures. The position being promoted is for the alleged signatory to
have
> the onus of proof in establishing that he or she did not digitally sign a
> given document. ... It is submitted that the law should not in the
> electronic commerce environment alter this position as regards to the
legal
> rights of parties to repudiate a digital signature".
>
> McCullagh and Caelli conclude that "Without a trusted computing system,
> neither party - the signer or the recipient - is in a position to produce
> the necessary evidence to prove their respective case". In short, an
X.509v3
> PKI is of no use, unless conditions are satisfied that manifestly are not
> satisfied.
>
> The inescapable conclusion is that the contemporary implementation of PKI
in
> the Internet context is a complete waste of time and effort, and
represents
> nothing more than a gesture towards the need for security.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 7. Privacy Concerns
> The previous sections have focussed mainly on technical inadequacies, but
> mentioned privacy in passing. This section summarises the privacy impact
of
> conventional digital signatures and PKI. Greenleaf & Clarke (1997)
> identified a wide range of threats, and categorised them as follows:
>
> Private Keys
> Private key generation. To ensure that the private key is never outside
the
> possession of the user, it needs to be generated entirely under the user's
> control;
> Private key storage and backup. To ensure that the private key is never
> outside the possession of the user, it needs to be securely stored and
> backed-up;
> Private key escrow. Because of the need to ensure that the private key is
> never outside the possession of the user, any form of escrow of digital
> signature private keys is inimical to the very concept of PKI;
> Private key access. Because of the need to ensure that the private key is
> never outside the possession of the user, private digital signature keys
> need to be exempt from court orders and search warrants;
> Private key revocation. Revocation needs to be very carefully undertaken
> (because, by definition, doubt has been thrown on the authenticity of a
> message signed using that private key); yet it needs to be very quickly
> undertaken (because of the risk of masquerade and fraud in the interim);
> Public Keys
> Certification identification requirements. Presentation at a Registration
> Authority in order to seek a certificate is onerous, and may involve
> intrusive demands for documents and even biometrics;
> Registers of public keys and/or certificates. Any such register that may
be
> established inevitably contains sensitive personal data. Moreover, it
> creates a serious risk of the public key or certificate id becoming used
as
> a multi-purpose identifier for individuals, with all the
> privacy-invasiveness that multi-purpose identification entails (Clarke
> 1994c, 1997);
> Certificate Revocation Lists (CRLs). To the extent that it might become
> normal to check the CRL as part of the processing of a transaction, the
CRL
> logs would become a centralised and highly intensive trail of a person's
> e-activity. Moreover, the CRL represents an opportunity for an authority
to
> cancel a person's cyber-identity;
> Consequential Privacy Implications
> Increased expectations of identification. The existence of a means whereby
> senders can identify themselves might well lead to an increased level of
> expectation that they do so in all forms of communication. This would
break
> down long-established and vital traditions of anonymity and pseudonymity;
> Chip-storage as a means of carriage of the private key. Because of the
need
> for secure storage of the private key, individuals could be coerced into
the
> acquisition and use of some form of chip-carriage mechanism. This would
> currently most likely be a card, but many other carriers are feasible,
> including direct implantation into the person (Clarke 1997);
> Central storage of biometrics. One means of preventing persons other than
> the owner of the private key from invoking it is to protect it with a
> biometric. Most biometric schemes to date involve central storage, which
is
> an enormous risk to individuals, because of the potential for the
biometric
> to be used as a basis for masquerade (Clarke 2000).
> Some of these problems are features of conventional PKI schemes that could
> be avoided or designed around. Many, however, are direct implications of
the
> nature of the X.509 architecture and certificate design.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8. Alternative Models of Trust
> Conventional PKI are ineffectual and privacy-invasive. Fortunately, there
> are other ways to address the need for trust in marketspaces. Their
> discovery depends in part on re-definition of the problem.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.1 PGP's 'Web of Trust'
> The 'web of trust' approach is intrinsic to the longstanding alternative
> product Pretty Good Privacy (PGP) - ( (Zimmerman 1995, Garfinkel 1995,
> Bacard 1995, Stallings 1995). This avoids the need for professional CAs,
> because certificates can be issued by anyone. Fault-tolerance is achieved
by
> depending on multiple certificates, probably with varying weightings
> assigned to them by the evaluator, on the basis of the degree of trust
they
> place in the person who provided the certificate. The 'identifier' used is
> the email-address. This is unique, simply because of the manner in which
> domain-names are allocated, and aliases and user-names are assigned.
>
> The approach requires message-recipients to consider the extent to which
> they really need assurance, and confront the simple fact that all
assurance
> is relative rather than absolute. The PGP concept is non-deterministic and
> uncomfortable, but it reflects the reality of social and economic
activity.
>
> This finds echoes in the works of some theorists. For example, Maurer
(1996)
> highlights the fragility of the assumption that the determination of trust
> is deterministic and computable on the basis of certificates, and
discusses
> the alternative of a probabilistic approach to the problem. This is
related
> to the naive military concept of 'absolute trust' and the less naive, more
> realistic and less expensive alternative of a 'risk-managed' approach to
> security issues.
>
> Criticisms have been levelled at PGP's specific implementation of the 'web
> of trust' notion. But arguments have been pursued for the concept to be
> broadened and applied more generally (Grossman 2000).
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.2 SPKI/SDSI
> Another standardisation process is that which grew out of Simple Public
Key
> Architecture (SPKI) - (Ellison 1996, IETF 1997-, Wang 1998, Ellison 2000).
> The momentum has now shifted to a parallel initiative, the Simple
> Distributed Security Infrastructure (SDSI) - (Rivest & Lampson 1996, SDSI
> 1996, Ellison 2000). The two approaches are in the process of being
> harmonised.
>
> 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. In effect, the certificate binds a public key (and
hence
> a key-pair) to an entity that only the CA knows. No warranties are
provided
> by the CA to the recipient of the message as to who the keyholder is.
>
> Attributes are associated with public keys, not with identities of
> real-world 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, or in possession of power of attorney for a company for
> purchases up to $10,000; but the certificate is silent about the identity
of
> the person who is using the key (Ellison 2000).
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.3 Stefan Brand's Alternative Certificates
> 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.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.4 Reputation and Brand
> Trust may be based on reputation, by which is meant 'generally held'
> positive opinion about an entity.
>
> There are several ways in which 'generally held' opinion can arise. These
> include:
>
> performance-based reputation, whereby an entity is active within a
community
> for some time, and comes to be perceived by participants in that community
> to have positive characteristics, and hence to be trustworthy;
> social-network-based reputation, whereby entities that are already known
> within an community introduce the entity, in effect attesting that 'yes,
> this entity is known to me';
> an entity may use advertising and public relations techniques to establish
> or embellish a 'brand'; and
> an entity can seek to engender trust in itself by using a 'meta-brand',
such
> as a seal of approval from some organisation that projects advertising and
> public relations on behalf of its clients, e.g. TRUSTe and WebTrust.
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.5 Nyms
> An earlier section argued that the privacy impacts of PKI are severe. It
is
> critical that any assurance mechanism that is implemented on the Internet
be
> at least tolerant, and even actively supportive, of anonymity and
> pseudonymity. These concepts, examined in Clarke (1993), Clarke (1994) and
> Clarke (1999), are critical to ensure that the advent of cyberspace does
not
> mean the death of private space.
>
> If PKI is to serve the needs of information society, the focus must be
moved
> away from identities of individuals. One direction of importance is to
> address the question of agents, both other humans and artefacts, and
> mechanisms for effective delegation to them.
>
> Another vital set of needs is for:
>
> roles to be supported without necessarily declaring the identity of the
> individual performing them;
> attributes to be able to be communicated without being linked to identity;
> and
> persistent relationships to be enabled even though either or both parties
> are anonymous.
> These objectives can be achieved through the application of the concept of
a
> 'nym'. This is the pseudo-identity that arises from anonymous and
> pseudonymous dealings (McCullagh 1996-, Clarke 1999).
>
> An earlier section offered definitions for the terms 'entity', 'identity'
> and 'identifier'. Two further terms require explanation:
>
> a role is a particular presentation of an entity. An entity may have many
> roles; and a role may be associated with more than one entity (i.e. the
> mapping of role to entity is m:n). A role is not capable of being directly
> expressed as data;
> a nym is a data-item or group of data-items which reliably distinguishes a
> role. However, because a role is not reliably related to an entity, there
is
> no reliable mapping between a nym and the underlying entity or entities
> (i.e. the mapping is m:n, but is not determinable).
> Nyms are not mere imagination: technologies exist that enable them. See
EPIC
> (1997-) and Clarke (1999a). Moreover, it may be very important to the
future
> of e-commerce that infrastructure support nyms, and that people adjust to
> their existence and nature. As Ellison (1997) argued: "The [U.S. House
> Hearing] asked 'Do you know who you are doing business with?'. Before
> answering that question, one should really answer the two questions: 'Do
you
> need to know who you are doing business with?', and 'Can you know who you
> are doing business with?'".
>
> Nyms are in practice replacing identifers. Leaving aside services /
> protocols such as IRC, MUDDs and ICQ:
>
> PGP depends on email-addresses, which are not formally linked to entities,
> and which may have any of a 1:1 relationship with a single person, or 1:n
> (multiple people may share the same address), or n:1 (a person may have
> multiple addresses); or indeed m:n (multiple accounts may be used by
> multiple people);
> with SPKI/SDSI-based PKI, an 'identifier' is not reliably bound to a
> particular entity, because the certificate relates to the key, and says
> nothing reliable about the key-holder; and attributes are associated with
> the key, not with the identity/ies of the real-world entity/ies who use
the
> key. SPKI's originator, Carl Ellison draws attention to the privacy
dangers
> of using any identifier consistently, because the action provides the
means
> whereby the data trails the person leaves behind can be collated: "The
real
> solution is for the user to generate multiple key pairs and use them for
> carefully walled-off purposes" (2000a). These are, of course, nyms; and
> Stefan Brands' certificates are expressly anonymous.
> Any approach to inculcating trust in marketspaces will need to implement
> persistent nyms at least for the consumer side of the transaction.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.6 Trust Management
> An approach that avoids and dissolves the problems with PKI rather than
> trying to solve them, is trust-management systems (Blaze et al. 1999a,
Blaze
> et al. 1999b). These can be viewed as generalisations of longstanding
access
> control techniques for achieving security of software processes and data.
>
> Trust management systems are argued by Blaze (1999) to have five basic
> components:
>
> a language for describing `actions', which are operations with security
> consequences that are to be controlled by the system;
> a mechanism for identifying `principals', which are entities that can be
> authorised to perform actions;
> a language for specifying application `policies', which govern the actions
> that principals are authorised to perform;
> a language for specifying `credentials', which allow principals to
delegate
> authorisation to other principals; and
> a `compliance checker', which provides a service to applications for
> determining how an action requested by principals should be handled, given
a
> policy and a set of credentials.
> The trust management approach also offers ways of addressing privacy,
> because it is much less concerned about identified individuals, because it
> focusses primarily on privileges and restrictions; and because it can deal
> with nyms representing pseudonymous roles just as readily as with names
that
> are associated with an identified human.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 9. Conclusions
> The originally perceived need was that, for e-commerce to become
mainstream,
> at least merchants, and probably also consumers, needed to identify
> themselves, and enable authentication of the identifiers they provided.
>
> But the technical orientation that has been adopted by the proponents of
PKI
> does not address the needs of the Information Society. The real social
need
> is for trust in e-interactions: for consumers to have security and
> convenience, but without surrendering personal data to sellers (and hence
to
> others who may gain access to it, such as other merchants, and agencies of
> government).
>
> Conventional X.509v3-based PKI suffers from such serious inadequacies that
> its application is highly suspect. The existence of an increasingly rich
set
> of alternatives to conventional, hierarchical PKI shows that the time has
> now come to recognise the inherent deficiencies of X.509 architectures,
> abandon attempts to impose them on open, public systems, and restrict
their
> use to within organisations that have strict hierarchical structures.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> References
> Adams C. & Lloyd S. (1999) 'Understanding the Public-Key Infrastructure'
New
> Riders Publishing, 1999
>
> Austin T., Huaman D. & Austin T.W. (2000) 'Public Key Infrastructure
> Essentials', John Wiley & Sons, 2000
>
> Bacard A. (1995) 'The Computer Privacy Handbook: A Practical Guide to
E-Mail
> Encryption, Data Protection, and PGP Privacy Software', Peachpit Press
1995,
> at http://www.andrebacard.com/press.html
>
> Blaze M. (1999) 'Using the KeyNote Trust Management System', November
1999,
> at http://www.crypto.com/trustmgt/kn.html
>
> Blaze M., J. Feigenbaum J., Ioannidis J. & Keromytis A. (1999a) 'The
KeyNote
> Trust-Management System Version 2' RFC2704, IETF, September 1999, at
> http://www.crypto.com/papers/rfc2704.txt
>
> Blaze M., Feigenbaum J., Ioannidis J. & Keromytis A. (1999b) 'The Role of
> Trust Management in Distributed System Security' Chapter in Vitek & Jensen
> (Eds.) 'Secure Internet Programming: Security Issues for Mobile and
> Distributed Objects, Springer-Verlag, 1999, at
> http://www.crypto.com/papers/trustmgt.pdf
>
> Branchaud, M. (1997) 'A Survey of Public Key Infrastructures', Master's
> Thesis, Department of Computer Science, McGill University, Montreal, March
> 1997, at http://www.xcert.com/~marcnarc/PKI/thesis/
>
> Brands S.A. (2000) 'Rethinking Public Key Infrastructures and Digital
> Certificates: Building in Privacy' MIT Press, 2000
>
> Clarke R. (1993) 'Computer Matching and Digital Identity' Proc. Computers,
> Freedom & Privacy, February 1993, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/CFP93.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) 'Information Technology: Weapon of Authoritarianism or
> Tool of Democracy?' Proc. World Congress, Int'l Fed. of Info. Processing,
> Hamburg, September 1994. At
> http://www.anu.edu.au/people/Roger.Clarke/DV/PaperAuthism.html
>
> Clarke R. (1994c) 'Human Identification in Information Systems: Management
> Challenges and Public Policy Issues' Info. Technology & People 7,4
(December
> 1994). At http://www.anu.edu.au/people/Roger.Clarke/DV/HumanID.html
>
> Clarke R. (1996) 'Cryptography in Plain Text', Privacy Law & Policy
Reporter
> 3, 2 (May 1996) 24-27, 30-33, at
> http://www.anu.edu.au/people/Roger.Clarke/II/CryptoSecy.html
>
> Clarke R. (1997) 'Chip-Based ID: Promise and Peril' Proc. Int'l Conf. on
> Privacy, Montreal, 23-26 September 1997, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/IDCards97.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) 'Privacy-Enhancing and Privacy-Sympathetic Technologies:
> Resources', April 1999, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/PEPST.html
>
> Clarke R. (1999b) '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. (1999c) 'The Willingness of Net-Consumers to Pay: A
> Lack-of-Progress Report', Proc. 12th International Bled EC Conf.,
Slovenia,
> June 1999, at http://www.anu.edu.au/people/Roger.Clarke/EC/WillPay.html
>
> Clarke R. (2000a) '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. (2000b) 'Interview', September 2000, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/BiometixIview.html
>
> Diffie W. & Hellman M. (1976) 'New directions in cryptography' IEEE
> Transactions on Information Theory, pp. 644-654, November 1976
>
> 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. (1999) 'The nature of a usable PKI' Computer Networks 31 (1999)
> 823-830
>
> Ellison C. (2000) 'Naming and Certificates', Proc. Computers, Freedom &
> Privacy 2000, at http://www.cfp2000.org/papers/ellison.pdf
>
> Ellison C. (2000) 'SPKI/SDSI and the Web of Trust' September 2000, at
> http://world.std.com/~cme/html/web.html
>
> 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
>
> EPIC (1997-) 'EPIC Online Guide to Practical Privacy Tools', at
> http://www.epic.org/privacy/tools.html
>
> Ford W. & Baum M.S. (1997) 'Secure Electronic Commerce: Building the
> Infrastructure for Digital Signatures and Encryption', Prentice Hall, 1997
>
> Froomkin A.M. (1996) 'The Essential Role of Trusted Third Parties in
> Electronic Commerce' Oregon L. Rev. 75,1 (Spring, 1996) 49-115
>
> Garfinkel S. (1995) 'PGP: Pretty Good Privacy' O'Reilly & Associates,
1995,
> AT http://www.ora.com/catalog/pgp/
>
> Greenleaf G.W. & Clarke R. (1997) `Privacy Implications of Digital
> Signatures', 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
>
> Housley R., Ford W., Polk W. and Solo D. (1999) 'Internet X.509 Public Key
> Infrastructure Certificate and CRL Profile', RFC 2459, January 1999, at
> http://www.ietf.org/rfc/rfc2459.txt
>
> IETF (1997-) 'Simple Public Key Infrastructure (SPKI)', at
> http://www.ietf.org/html.charters/spki-charter.html
>
> 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 World Wide Web Journal 2 3 (Summer 1997) 77-112, at
> http://www.cs.caltech.edu/~adam/local/trust.html
>
> Lampson B., Abadi M., Burrows M. & Wobber E. (1992) 'Authentication in
> distributed systems: theory and practice' ACM Transactions on Computer
> Systems, 10(4):265{310, November 1992, at
>
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083.
> html
>
> McCullagh D. (1996-) 'Nym', at http://www.well.com/user/declan/nym/
>
> McCullagh A. & Caelli W. (2000) 'Non-Repudiation in the Digital
Environment'
> First Monday 5, 8 (August 2000), at
> http://firstmonday.org/issues/issue5_8/mccullagh/index.html
>
> 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
>
> Rivest R.L. & Lampson B. (1996) 'SDSI - A Simple Distributed Security
> Infrastructure', 15 Sep 1996, at
> http://theory.lcs.mit.edu/~rivest/sdsi10.html
>
> Schneier B. (1996) 'Applied Cryptography' Wiley, 2nd Ed., 1996
>
> SDSI (1996-) 'A Simple Distributed Security Infrastructure (SDSI)', 1996-,
> at http://theory.lcs.mit.edu/~cis/sdsi.html
>
> Stallings W. (1995) 'Protect Your Privacy: The PGP User's Guide' Prentice
> Hall, 1995
>
> W3C (2000) 'Public-Key Infrastructure (X.509) (pkix)', at
> http://www.ietf.org/html.charters/pkix-charter.html
>
> Wang Y. (1998) 'SPKI' December 1998, at
> http://www.hut.fi/~yuwang/publications/SPKI/SPKI.html
>
> X.509 (1988) 'The Directory - Authentication Framework', Volume VIII of
> CCITT Blue Book, pages 48-81, CCITT, 1988
>
> Zimmermann P.R. (1995) 'PGP 5.0 User's Guide' MIT Press, 1995, at
> http://mitpress.mit.edu/book-home.tcl?isbn=0262740176
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Navigation
> Go to Roger's Home Page.
>
> Go to the contents-page for this segment.
>
> Send an email to Roger
>
> Created: 6 November 2000
>
> Last Amended: 9 November 2000
>
>
> --------------------------------------------------------------------------
--
> ----
>  These community service pages are a joint offering of the Australian
> National University (which provides the infrastructure), and Roger Clarke
> (who provides the content).
> The Australian National University
> Visiting Fellow, Faculty of
> Engineering and Information Technology,
> Information Sciences Building Room 211 Xamax Consultancy Pty Ltd, ACN: 002
> 360 456
> 78 Sidaway St
> Chapman ACT 2611 AUSTRALIA
> Tel: +61 2 6288 1472, 6288 6916
>
> To unsubscribe send the following in the body of a message to
> listserv@abanet.org  - unsubscribe st-isc