MCG Home-Page
Overview and Research Papers on Certification, Trust, Cryptography, etc.

Net Reference: This paper has been downloaded more 250,000 times from 1997to 2000.
 Visit also the July/2000 revision of this paper, in PDF format: certover.pdf - 540 Kb

Overview of Certification Systems: X.509, CA, PGP and SKIP

Attention: This is version 1.8 -- issued August 1, 1998. This was a work document  for open peer-review and public discussion. The PDF  format contains a more recent version.

E. Gerck,
Copyright © 1997-1998 by E. Gerck and MCG, first published on April 17, 1997 by the MCG
All rights reserved, free copying and citation allowed with source and author reference.


1. Certification Methods
        1.1. X.509 and CAs
        1.2. PGP
        1.3. SKIP
         2. Proposed Solutions
         3. Meta-Certificate
         4. References


The Internet is an open system, where the identity [1] of the communicating partners is not easy to define. Further, the communication path is non-physical and may include any number of eavesdropping and active interference possibilities. Thus, Internet communication is much like anonymous postcards, which are answered by anonymous recipients. However, these postcards, open for anyone to read -- and even write in them -- must carry messages between specific endpoints in a secure and private way.

The solution is to use encryption (to assure privacy and security) and certification (to assure that communication is happening between the desired endpoints). This paper deals with the question of certification. The closely related question of encryption is also referred to, in order to set the various certification stages.

The problems that may be caused by false certification or no certification mechanisms can range from a "man-in-the-middle" attack in order to gain knowledge over controlled data, to a completely open situation to gain access to data and resources. It is important to note that these problems do not disappear with encryption or even a secure protocol. If the user is led to connect to a spoofing site, which appears to be what he wants, he may have a secure connection to a thief and that will not make it safer. Thus, identity certification, or authentication, is a must.

But, the reader may ask: "I just need to have the other party's public-key, what is so complicated about it? Public-key cryptography allows my public-key to be distributed at will, as well as anyone else's". However, certification is harder than it looks, as the reader may verify.

This paper reviews the three most common certification methods in use today, which are based on X.509 Certificates and Certification Authorities, PGP and, SKIP. These methods are studied from a systemic point of view. The main motivations for this paper are: (i) Conduct a comparative review of the three methods, (ii) Unify a set of references to the most important issues in certification and encryption, as they are related to Internet needs and recent governmental policies, (iii) Provide a basis for the evaluation of other certification solutions available or to be developed, (iv) Identify room for improvements on the current security level of certification, that could be dealt with by other methods, (v) Access the impact on Internet transaction security due to the security control policy needs of Governments currently actively promoting such policy solutions.

It is important to note that other certification methods which are in development, such as IETF’s PKIX, are still in a volatile stage and would not be reviewed in this paper in a fair way as compared to the three methods cited above. However, PKIX is a direct derivation of X.509 and the reader will find essentially the same features and probems in PKIX.

The main motivations for this paper are:

1. Certification Methods

Absolute certification methods are a logical impossibility, because a certificate cannot certify itself. Thus, three main methods have been proposed to deal with this situation:

Each of the above paradigms deals with the basic certification question in a different way, analyzed below.

A further theme to be discussed is trust, because certification is based on two different properties: trust (qualitative) and keys (quantitative). It will be shown that, in any certification system, what makes a certificate trustworthy is not any magically infused trust from the certificate's issuer (e.g., the CA). Rather, this paper takes the stance that a certificate is trustworthy as decided by the user (i.e., the party that relies on the information -- who is at risk), based on the trust the user decides to place in the certificate's issuer and as a function of perceived risks, costs, threats, situation, etc. In other words: like in day-to-day business, trust must be earned, not merely assigned.

It is relevant to note that protocols such as X.509, PGP and others, do not define well what trust is but start by defining means to convey it. Such attitude ignores the properties of trust but not without a price, which can lead to security risks and lack of standardization as this paper shows. This is one of the basic contradictions in the protocols reviewed here, which contains the seeds for further problems as the reader may verify. For a presentation of the trust model and concepts used by Meta-Certificates, see "Towards a Real-Worl Model of Trust".

1.1. X.509 and CAs

The ITU-T Recommendation X.509 (which has been implemented as a de facto standard) defines a framework for the provision of authentication services, under a central control paradigm represented by a "Directory". It describes two levels of authentication: simple authentication, using a password as a verification of claimed identity; and strong authentication, involving credentials formed by using cryptographic techniques. It is this second level that interests us here, especially in regard to three central questions:  (1) what is a X.509 certificate, (2) what is the naming scheme used in X.509 such that a certificate can be associated with a user and, (3) what is the validation procedures for the certified data that is included in a certificate:

  1. Section 3.3.3 of X.509v3 defines a certificate as: "user certificate; public key certificate; certificate:  The public keys of a user, together with some other information, rendered unforgeable by encipherment with the private key of the certification authority which issued it.".
  2. Section 11.2 of X.509v3, "Management of certificates", states that the certificate allows an association between a name called "unique distinguished name" or DN for the user and the user's public-key: "A  certificate  associates  the public key and unique distinguished name of the user it describes.", while Section 7 explains that such DNs are essential to the security design of X.509: "Authentication relies on each user possessing a unique distinguished name." But, how are such DNs assigned? Where are they unique? The DN is denoted by a NA (Naming Authority) and accepted by a CA (Certification Authority) as unique within the CA's domain, where the CA can double as a NA. It is interesting to note that the same user can have different DNs in different CAs, or can use the same DN in different CAs even if it is not the first one to use it in a CA -- so different DNs for different CAs do not necessarily mean different users and vice-versa. Further, a DN does not have to contain the user's real-world name or location. Thus, semantically, the CA certificate refers to a name; however it does not denote it.
  3. X.509 is moot on validation procedures for data included in a certificate such as the user's name, with the exception of validation procedures for the user's public-key which are suggested (not mandated) in Section 10 of X.509v3. For example, regarding validation procedures for the user's identity, Section 11.2.a states that: "a certification authority 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 (called CPS), which are declared outside the scope of X.509 and can be entirely different for different CAs. Further, all public CA's CPSs accept indirect references of "soft-trust" when issuing certificates, which is a security risk that could only be acessed by auditing, to verify the procedures used to accept an ID for example -- but, auditing is not possible with today's CPS.
Thus, X.509 focuses on defining a mechanism by which information can be made available in a secure way to a third-party. However, X.509 does not intend to address the level of effort which is needed to validate the information in a certificate neither define a global meaning to that information outside the CA's management acts. The main purpose of a CA is to bind a public key to the name contained in the certificate and thus assure third parties that some measure of care was taken to ensure that this binding is valid for both -- i.e., name and key. However, the issue whether a user's DN actually corresponds to identity credentials that are linked to a person or simply to an e-mail address -- and how such association was verified --  is outside the scope of X.509 and depends on each CA's self-defined CPS.

Regarding the DN specification, X.509 is based on X.500 in order to specify the DN naming scheme -- but X.500 is not completely defined. This has left room for many different readings of the proposed X.509 Recommendation, as the only way which actually allowed X.509 to be used. Also the X.509 Recommendation depends on many others ISO, ANSI, ITU, and IETF standards, amendments, meeting notes, draft standards, committee drafts, working drafts, and other work-in-progress documents, besides the convoluted language used in some of these specifications, as pointed out by Peter Gutmann.

A characteristic of  X.509 is that it predicates that almost all issues that involve semantics or trust are delegated to a CA's CPS  -- Certification Practice Statement -- which is declared out of scope in relationship to X.509. The CA's CPS is the governing law that the CA presents to potential clients and represents a top-down framework. While some consider the CPS mechanism to be a good way to introduce flexibility in X.509 because each CA can have their own rules for different needs, such mechanism can be considered as X.509's "black-hole" and cannot be harmonized for different CAs. Thus, while this "black-hole" mechanism affords a "solution" to the undefined semantic and trust features in X.509 (as they are declared out of scope and delegated to the CPS), such "laissez faire" attitude leaves ample room for strong differences between CAs and for a  biased "take-it-or-leave it" attitude regarding what a CA subscriber can expect. Further, it does not scale to a planetary Internet because even though it could work in a parochial Internet where everyone knows what to expect and share a common law and trust system, it is doubtful that it could be always successfully applied between competing businesses or different states in  a country -- much less between different countries.

These problems have caused independent interpretations of X.509 in actual implementations, as given by Netscape, Microsoft, RSA, etc., and by the CAs.

For example, let us analyse SSL (Secure Socket Layer now in version 3.0, see also this reference) -- which is not a socket protocol as the name might indicate but which allows for encryption and certification functionality in a TCP/IP environment. SSL is perhaps the widest used security protocol on the Internet today and implements X.509 Certificates as interpreted by SSL's proponent,  Netscape. There are also other implementations of SSL, such as a free implementation called SSleay which is export-free and user-friendly -- developed by Eric Young and Internet collaborators. SSleay is widely used with the Apache Web server. The first fully functional version of Apache with SSL support was implemented by Ben Laurie. A full-Java implementation of SSL3.0 called  J/SSL is available from Baltimore Technologies.

However, if a X.509 Certificate is acceptable by a Netscape SSL product it does not mean it will necessarily be acceptable by products from Microsoft or RSA or another vendor. This is further confused by a number of ill-defined market names as defined by CAs, such as "Digital-ID" and others, that hide the dependency on X.509 but which nonetheless depend on the same concepts.

Besides, X.509 certificates are not human readable and the user cannot easily see what is being accepted, in fact he has to take it for granted that it is correct -- even if a browser presents a readable conversion. However, even experts disagree on basic X.509 issues, as explained above, and there is usually ample room for doubt about what exactly a X.509 certificate is, why it is acceptable or why it is not acceptable. In other words, X.509 certificates have a twilight zone exactly on the most important issue with certification: what has been certified. At the end of this section, a link to a readable example of a generic X.509 certificate is provided, which illustrates these points.

Another point is that X.509 certificates need a "Directory" service, that deals with the users and supplies copies of the certificates -- even though the certificate is used off-line with the "Directory". This means that the "Directory" needs CAs for two reasons: (i) to issue "standard" X.509 certificates that can be interpreted unambiguously and, (ii) to make it possible to have their validity verifiable by a user. However, who verifies the CA's validity? The CAs themselves are usually "self-certified" or depend on a CA that is "self-certified". Users may use any CA or any number of CAs, depending on their location and ease of access. The different CAs are in general independent, even in the same country.

The CA paradigm is thus, essentially, to rely on an authentication chain that ends in a ... CA that eventually certifies itself. Therefore, the validity problem is shifted from a local perspective to a global perspective, with the whole chain depending on one final link. At the end, ignorance (and the possibility of fraud) is leveraged to a high degree, in which one weak link may compromise a whole chain of certificates.

What are the causes for weak links? Besides the conceptual points above, several. The most important ones are discussed below, with some references taken from various discussion groups as cited.

(i) Most of the servers that use CA certificates force the client to accept certain CAs' signatures, which are "hardwired" into the software. The decision of trust is from the beginning entirely removed from the client (ie, the user) -- which contradicts the discussion that the user should be central to the decision process in all steps, since the user is the party that is relying on the information and is thus at risk.

(ii) The client needs to accept the server CAs' key signatures, usually in a list that may include an unknown (i.e., untrusted) CA if that CA is trusted by a CA that the client trusts, and so on to a possibly large depth starting from only one known CA -- otherwise, the client has the choice of terminating the connection, which is hardly a choice (i.e., no alternative). However, a good certificate list could decrease, clearly, the number of untrusted entries (and, risk) in such a chain. Further, the job of providing a good certificate list is more challenging for the server than it would have been for the client -- the server is essentially groping in the dark because it is not informed by the client what CAs to best aim for in a ranking list (CAs that are directly trusted by the client or, untrusted CAs directly trusted by a CA that the client trusts or, etc.). The client, however, would know which CAs are acceptable to the server because the server sends a list of distinguished names [2] in the "certificate request" message. Note that there is no corresponding list sent in the other direction (from the client to the server).

(iii) The life of a server or client certificate cannot extend beyond the life of the certificate of the signing CA. The principle here is that after the expiration of the CA's certificate, one should assume that the corresponding root-key may have been cracked (which is why it has a finite life in the first place) or discarded without enough care (e.g., by wipping disk areas, surely destroying all copies, etc.). Anything signed by that key thereafter should be suspected of being a forgery. In other words, if someone presents to you a certificate today that was signed by a key linked to a certificate that expired last month, you should assume it might be a forgery. However, if you knew that the certificate was signed during the lifetime of the signing CA's certificate, you could assume that it was authentic (based on the principle that the private key had not yet been cracked). The trouble is, there is no way to ascertain from the certificate exactly when it was signed in relation to other lifetimes.

(iv) The lifetime of a certificate also depends on various factors, as pointed out by Ian Simpson. A simplified mathematical analysis and simulation shows that optimal certificate lifetimes may be as short as a few weeks rather than a year or more as is the case of some current commercial CA infrastructure offerings. Note that such short lifetimes mean a large overhead in costs, time and effort.

(v) You must have multiple copies of certificates, to cope with the use of different non-communicating CAs and with different expiration dates. For example, if you have a server that is certified by a CA, your own certificate must be substituted before it expires, while the older one is still valid and is registered in someone's access files, somewhere.

(vi) The Certification Authority's public key might be the target of an extensive decryption attack. For this reason, CAs should use very long keys and change keys regularly. Top-level CAs unfortunately are exceptions: it may not be practical for them to change keys frequently because their keys may be written into software (such as the browser you are using now) used by a large number of verifiers. Thus, the very CA's that may be the most probable targets are the ones that offer the smallest protection level. Protection, in this case, is an inverse function of worth.

(vii) There is also a serious question of how one would distribute an updated top level CA certificate, when the expired certificate is "hardwired" in the software. Unless there is a second trusted CA who can sign the distribution, the new certificate cannot be certified.

(viii) CA's may suffer internal problems (software bugs, internal frauds, bad bookkeeping, bad auditing practices before issuing a certificate, etc.) that may compromise any number of certificates, including the CA's own root certificate.

(ix) Certificates do not usually include information about and do not certify e-mails, phone numbers, fax numbers, addresses and other data that may be crucial for identification or, to establish a reliable contact [3]. They also do not certify commercial information, such as that which may allow for the intended flow of documents and monies, for example the correct bank account to receive deposits. They also do not allow for temporary changes of personnel in charge, to cope with, for example, vacation schedules. To alleviate this problem, Netscape has proposed a new type of certificate, to be used together with X.509 Certificates, called Attribute Certificates. These are signed objects that assert additional properties about a particular identity certificate. An attribute certificate has no associated key pair and consequently cannot be used to establish identity. Informally, one can think of them as a mechanism for extending the attributes of an identity certificate without requiring that the identity certificate be reissued. Formally, they are a "patch" type of solution -- that may introduce a series of inconsistencies (e.g., revocation lists for either type of certificate, cross dependencies, etc.).  Recent (end of 1997) meetings on the X.509 standard have discussed what distinguishes an attribute certificate from a public key (identity) certificate -- it was argued that there was not much difference (e.g. no public key in an attribute certificate) and that everything one could include in an attribute certificate one could also include in a public key certificate, which thus could allow attribute certificates to merge with identity certificates within X.509.

(x) Revocation lists, or CRLs, are needed to notify that an otherwise valid certificate is not valid. This, which was first thought to be a positive aspect of relying on CAs -- as compared to PGP for instance, presents several unsolvable problems [4]. For example, there may be a considerable delay (no warranties on the CAs contracts can be found on upper limits for such delays) between the actual need to revoke a certificate and the reflection of this need in a certificate chain with different CAs. Further, the major X.509 security application today, SSL, does not check revocation lists -- so they are near to useless. Also, the user is not able to check server certificates (and certificates in the CA chains) against revocation lists. An examplary case regarding  CRLs, is that they are a will to revoke but not an actual revocation. Few recognize that CRLS are a solution to a non-existent problem ... while the real problem is left utterly unsolved. The non-existent problem solved by CRLs is how to communicate that a certificate is no longer valid ... because if a certificate were really no longer valid (as it should be) then no one would need to find a CRL to know about it.

(xi) In business practice, it is often reasonable for one party to rely upon the representations of another without verifying them. Would this be the case for the relationship between a server and a user, when a server certificate issued by a CA is presented? At first look, it would seem so, because in this case "... the user is the relying party and views the other party as an expert." [5], the "other party" being the server and the CA that issued the certificate -- certainly, in the user's view, experts on certificates. Also, to add further weight to this presumption, this is a case where "... the other party's statements (i.e., the statements on the CA's server certificate) seem reasonable on their face value (i.e., especially with the name "certificate" together with "authority") but are especially hard to check." [6], i.e., it is hard to check the validity of the CA's signature in the server's certificate, for example. However, these well-known principles and guidelines may not be valid in all countries, as exemplified by the proposed US Uniform Commercial Code, because "for data processing and design or consultation work, the basic focus for gauging liability centers on the process, rather than on a guaranty of correct result " [7]. Therefore, even though the user can rely upon the certificate presented by the server as being free from tampering (i.e., because of the cryptographic assurances) since it was issued by the CA, the user should not rely entirely upon the CA's declarations in it and should somehow judge the reliability of the data contained in the Certificate, which is further complicated by the question of the applicable governing law. Further, the ABA Guidelines  suggests that such decision must indeed involve a final "relying party" attitude, because the user must rely upon the last CA as "reasonably reliable" before considering the server certificate valid: "... a person relying on the certificate must verify its digital signature by referring, in turn, to another certificate, and so on along a chain of certificates until reaching a valid certificate digitally signed by a primary certification authority, whose digital signature is reasonably reliable...". This means that even though the expected behavior is not to be expected, the user has no choice but to rely upon the CA's representations in the certificate.

(xii) As it has been discussed in the MCG and elsewhere, mainly MS IE and secondarily NS Communicator do not follow a secure protocol for clients certificates issued for SSL or S/MIME. Thus, both browsers introduce the possibility of implicit key-escrow, weak-keys and CAK-ware without the user being able to verify it, even though such possibly is less pronounced for the Netscape browser. This means that a system could be imposed where a CA would demand the user's encryption keys before signing the certificate for the public key. However, this would not happen if the private key generation procedure would be done entirely off-line, without an Internet connection -- which is simply not needed for the procedure. This simple act would completely allay such privacy concerns and, yet, it is not done in MS IE and NS Communicator.

(xiii) The denominations "Certificate Authorities" and "Certificates" are certainly not to be understood by their etymology. A "Certificate", which has the same root as the word "certain", is used in day-to-day words such as Gold Certificates, Certificates of Deposit, etc., with a very clear and precise meaning above any doubt. Not quite the situation with the "certificates" we are dealing with here. This represents a wrong contextual clue that leads to a type of implicit spoofing situation, in which the unwary user, or even the non-technical user which is the majority, is led to believe that the words "authority" or "certificate" carry the same weight as their dictionary entries and day-to-day experience would imply. The user does not expect them to be misnomers. To quote from Ed Felten et al.,

Thus, the system gives the impression of a self-regulated and safe system, whereas it is clear from the points above that the user is the one and only true authority who will eventually certify the so-called "Certificate Authorities" and "Certificates".

In summary, there are many reasons that may jeopardize a "certificate", create a weak link or, give the wrong contextual clues for on-the-spot decision making.

The uncertainty reaches a point of almost uselessness, where CAs usually explicitly state in the certification contracts that the CA is exempt of all or almost all responsibility regarding the "certificate", its accuracy and its data. For example:

However, the issuer's disclaimer (i.e., the CA's) is generally not visible in the certificate itself, for all browsers and all X.509 implementations.

Further, such CA disclaimers are part of the CA's CPS (Certification Practice Statement, which is outside the scope of X.509 and constitutes the governing law that the CA presents to potential clients). Thus, it can be seen as a legally-enforced way to reduce deliverables to almost zero -- which is an accepted legal practice to effectively reduce liability to zero. So, the point is not so much that CAs deliver a product with zero warranty (which could be disputed in court even in countries with common-law systems) but that  CAs are delivering a product with almost zero content (which any court would accept as envolving almost zero liability) -- as it is clearly exemplified in the second and third sentences of the above disclaimer ("...MAKES NO REPRESENTATION ..." and "...MAKES NO ASSURANCES ...").

Actually, the content of a CA's services in relationship to the subject's data is not zero because there are two items that X.509 mandates and that a CA must deliver in a certificate without content disclaimers (but, which may still be limited in scope by the CPS): (i) that the subject's public-key has a working private-key counterpart elsewhere (with no warranties that the public/private key pair is not artifically weakened, that it is actually in the possession of the named subject and that no one else has obtained a copy of it), and (ii) that the subject's DN is unique to that CA (with no warranties that such DN contains the actual subject's name, location or that the subject even exists or has a correctly spelled name -- as in "Internet Serices"). There are other items in the certificate which have no relationship to the data supplied by the subject but which are necessary for the proper use of the certificate as a secure transport for  information in the X.509 model, such as its serial number, date of issuance, validity, the CA's signature, etc., which usually also carry limited CPS warranties (e.g., as in the case of fraud, computer viruses, etc.) that may further jeopardize the secure use of the certificate, without the user being even aware of it.

Now, having cited Verisign's disclaimer, it is important to understand its reasoning and need. It does not say that Verisign has no warranty on its services or that it does not take any liability on them. It only says that Verisign has no warranties and accepts no liability for services that Verisign does not recognize it provides. The fact that Verisign does not provide what perhaps the majority may think they provide is another point altogether. The solution is, perhaps, much more to educate the majority than to expect a company to do what is maybe technically unfeasible in X.509 terms.  Thus, in the author's opinion, Verisign's CPS is not at all at odds with X.509 or legislation -- so, it could very well be an example to be copied. Maybe, it just truly represents the maximum one commercially and technically could wish for in X.509's and CPS's terms.

Thus, for any generic CA one might expect a similar reasoning. Indeed, if the only thing that a CA does (as per X.509) is to challenge the subscriber's private-key in order to bind the corresponding public-key with the subscriber's  DN and,  if it signs the certificate with a CPS that says that any other data are being copied as received but have not been verified (and have thus no warranty) then the CA has no responsibility for the contents of the certificate -- save the positive acknowledgement that the public-key did have a counterpart when it was linked to that DN (where the CPS could further provide exceptions for frauds, virus, MITM attacks, etc.).

One may ask, why are such content limitations and disclaimers  necessary for certificates? First, a certificate is not like a car that has a limited liablity in space and time (after all, a car is a localized entity that can contain a limited number of people and only one driver). A certificate can be endlessly multiplied and simultaneously presented in a planet-wide area. Certificates are used without limit in a chain of events, which can include other fully unrelated certificates and people. With the growing attitude of  seeking large legal compensation for one's lack of foresight, the liability pyramid created by a lesser disclaimer could easily extend to the CA's client's clients and so on.

Insurance protection may help here, but there are several issues that must be touched upon. The use of insurance always signals lack of knowledge  -- so it clearly cannot replace it. Further, there is no insurance needed for a sure event and there is no insurance possible for a sure risk. If a user (ie, a CA subscriber) is going to for pay insurance to cover his liabilities and the CA's liabilities (which is what it amounts to),  then responsibility has gone full-circle and is now only in the user's hands -- both to get adequate coverage and to pay for it. While the CA has zero risk and cashes in as the middleman between the user and the insurance companies. However, that does not solve the risk problem for the user either, because one cannot make the whole world sign up one huge insurance policy -- so the user and the CA may be protected by the insurance policy that the user has bought with their names as beneficiaries but that does not protect a third-party (ie, the rest of the world). Last, since CA auditing does not help here, then insurance does not have a reliable risk estimator either, even for the CA subscriber.

Regarding recent legislation efforts, such as in Utah (US),  Illinois (US) and other legislation, it is clear form the above discussion that demanding broader warrants by law can be self-defeating because CAs may then be forced to reduce the deliverables to zero -- instead of coming out and providing for more warranties. There simply is a limit to what X.509 and the CA paradigm can offer regarding legal certificate reliance and -- most importantly and often confused with the former -- legal certificate content reliance. Law cannot push the technical envelope of X.509.

When confronted with risk situations, a normal business solution is to rely on auditing. However, auditing of a CA's certificates is also a difficult, if not impossible, task. This is due to X.509, which allows CA's practices and policies to be built upon islands of self-regulation exactly on the most important issues of trust and trust management. As publicly declared by  Phillip Hallam-Baker, a Verisign consultant, not only are the CPSs indeed different and self-made by each CA but they are not designed to be audited, either: "There is not as yet a defined standard for CA practices against which a company may be audited. In effect each company states their own practices in their Certificate Practices Statement (CPS). The CPS is not a document designed for auditing use however. It describes a 'specification', it does not describe details which may be checked by a third party in a systematic manner."

Thus, a X.509 certificate is essentially a bag of bytes, which meaning and validity strongly depends on the CA. Moreover, in legal reliance terms, one may trust the confirmation procedures of the CA during certificate reliance, but one cannot rely upon them for other than their value as a representation of the CA's authentication management act expressed in the CA's own terms and rules -- therefore, a X.509 certificate is neither necessarily meaningful nor valid in a user's reference frame or for the user's purposes.

Last, when one waches for some time the different mailing lists that collects doubts and questions on certification systems from users or, when one reads the majority of the newspaper or magazine articles on the subject, one cannot help but perceive a pervailing feeling in the user community to the effect that a certificate is magically infused with trustworthiness -- which would imply a deterministic and absolute view of certification. For example, as one user wrote: "Please provide me with a list of all trusted CAs so that I can enter those certificates into my browser.", few understand that trust must be evaluated relative to the user -- the party at risk. Thus, the very names Trusted Third Party or trusted CA raise already several questions:

- in relationship to whom?
- trusted by whom?
- trusted for what?
- trusted for how long?
-- etc.

How are these questions answered? Clearly, by each user (ie, verifier or, relying party -- who is at risk) in its own domain, references and terms. This means that certificates are essentially statements from a CA, not fact, and that meaning and trust on a certificate (like beauty) is in the eyes of the beholder, i.e., depends on each user.

To conclude, we are led to observe that so-called "X.509 certificates" are not at all "certain" as the etymology would imply, being mere indications with no assurances or warranties, but nonetheless well paid for in money and system complexity. To see a graphical birds's eye view of this exposition, with a less terse treatment, the reader can visit the unabridged inside view of a typical X.509 certificate.

1.2. PGP

PGP has two parts: certification and encryption. The discussion below is centered exclusively on the certification aspects of PGP.

First, comparing PGP with X.509 can be very instructive. X.509 is often times spotted as predicating a top-down trust structure (see the CPS discussion above) that is just dictatorially imposed upon the verifier, while PGP would follow a grass-roots approach -- thus more Internet-like. However, both PGP and X.509 define their central role to be played by the verifier regarding certificate acceptance, while certificate metrics is defined in both cases without any influence from the verifier (thus, "dictatorially" for both). Further, both are key-transport protocols, and they depend on two types of external references: keys (quantitative) and trust (qualitative). Further still, the web-of-trust in PGP finds its parallel in the X.509 CPS, also where the issuer sets the rules and defines semantic acceptance conditions before certificate signature. The first main difference is possibly syntatic, in the sense that PGP allows certificates to be stacked up so to say as signatures upon signatures, whereas in X.509 the certificates are linked one to another as in an one-way linked-list (though X.509 could also include PGP syntax). A second main difference is semantic, in which PGP allows an association between keys and real-world persons by the web-of-trust but not transitive trust, whereas X.509 binds keys to names and accepts transitive trust -- even though a proper CPS could allow the same in X.509 as a function of the CA's policies (again, the analogy between the web of trust rules in PGP and the CA's CPS rules in X.509) .

PGP is based on an "introducer-model" which depends on the integrity of a chain of authenticators, the users themselves. The users and their keys are referred from one user to the other, as in a friendship circle, forming an authentication ring -- the term ring is not used here to denote a closed structure but as a mathematical set which can at present be loosely modelled as a list -- or "web of trust". At the end, you may not know very well the last person that entered the ring, but you hope that someone else in the ring does. Or you may have different rings, with "contact points" which guarantee the referrals. However, the reader should note that no user can know for sure if everyone in his authentication ring has a valid entry. The term "chain" can be used to denote such connected rings, which can also, of course, be multiply connected.

The reader should notice further that the maintenance of this chain -- changing, adding or deleting data -- is done by the authenticators themselves, in a happenstance pattern. There is no guarantee if and when the chain is up-to-date. Everyone familiar with the classical problem (or need) of file-locking in a multi-user environment will recognize that there is no "file-locking" mechanism here.  So, while PGP enforces a model of "hard-trust" with "trust is intransitive" to setup entries in the web of trust it uses "soft-trust" to upkeep entries, without discussing its validity/gauge nor allowing for time factors such
as lack of synch.

There are several other problems and benefits of PGP, which this paper will not address. This is not intended to be a dismissive treatment of PGP, but rather a focus on commercial applications. It is important, however, to note that one of the benefits of PGP is that it can interoperate with a CA fully-trusted by all parties in a domain (such as an internal CA in a company) that is willing to guarantee certificates, as a trusted introducer. Better tools would certainly be necessary for central administration of PGP trust parameters in a corporate system, but the flexibility of PGP makes it a good example of a quasi-decentralized system.

It is important to note that the concept of "central administration of PGP" -- which to some might sound even sacrilegious -- is a way to guarantee accountability, coherence, dependability and, above all, correct authentication. Of course, within a circle of close friends this is not important.

Because there is no entity responsible if (or when) something goes wrong -- not even the user -- the use of PGP in a commercial situation is difficult and may not adequately protect the business interests involved, as they usually need to be guaranteed in well-defined contracts with loss responsibilities and fines. Further, PGP does not scale well in size (because of the aforementioned asynchronous maintenance difficulties of the web of trust) or time (because of the same maintenance problems reflected in the so-called certificate revocation certificates, a CRL for PGP certificates). Again, within a circle of close friends this is not important.

1.3. SKIP

SKIP implements a linked chain of two-sided node authenticators. Each node authenticator derives its information from a type of directory service. Without dismissing SKIP as a valid and interesting protocol, it is important to note that non-repudiation and other security features that depend on certificates will necessarily also depend on data from the application layer. But, as every step of the SKIP authentication process happens at the protocol level (not at the message level), the SKIP protocol needs to be complemented by a second authentication protocol, in a higher layer.

Note that SKIP is transparent to the user, for better or for worse.This means that SKIP lacks user-tunable controls, such as the rejection, revocation, visualization or choice of certificates.

Here, also, a type of "directory service" must be used by the node authenticators to obtain information. This is a type of "central administration of SKIP" -- which is needed to guarantee accountability, coherence, dependability and, above all, correct authentication. The difficulties of implementing such an administration system worldwide are compounded by the fact that a given packet route will not have a unique path, not even if the same packet route is being used for a series of requests such as produced when a Web site is visited. The situation is totally different from, for example, a PGP session, where the authentication is done at fixed endpoints and the routing path is not important.

Therefore, the user has no practical way to control the process, can not decide which node authenticator is reliable, can not exclude nodes which have been infected by the enemy, can not choose to choose certificates, etc. The use of SKIP in a commercial situation is thus difficult because the control decisions are totally removed from the user -- who is at risk. Further, the system liabilities are ill-defined and responsibilities for fines and losses hard to recover.

2. Proposed Solutions

As explained in the introduction to this paper, in the Internet encryption is not a luxury, but a necessity. And encryption without authentication is an open door to spoofing and other kinds of attack. However, in each of the three methods analysed above the basic authentication question remains: who is on the other side?

To try to cope with this situation, which can have national and international impact, governments have proposed several initiatives. Because: (i) certificates depend on some form of encryption (e.g., X.509), (ii) encryption does not make sense without certification and, (iii) encryption must be used, the two issues -- of certification and encryption -- are inherently present in all proposed initiatives. Before discussing the other aspects of these initiatives, which range from anti-terrorism to politics and beyond, it is important to review the two most important technical issues.

First, the issuing of a certificate by a CA can be seen as a public service and thus must be a par with other public services which must be and indeed have been regulated by the govenment to avoid abuse and misuse. For example, the biscotti paradigm. If you want to make and eat your own biscotti, fine. If your neighboor wants to eat some of the homemade biscotti you made for your own consumption, this is also usually fine (unless you fear a lawsuit in case of food poisoning). If you want to buy it from someone else for your own private consumption, it is your decision. But if you want to sell it to the general public or to a store, then you must have a seal of approval and must comply with a set of rules. The same principle applies to a public service that sells services to provide signature keys, public-keys or passwords. They can be subjected to impersonation, falsification, blackmail, etc., all with great potential harm. In other words, because the social order may be disrupted by this service, it must be regulated by the government. The alternative would be for it to be in effect regulated by criminals, which no one would support.

Second, one must take into account the lawful possibility and need to track communications, under court order, to prevent theft, terrorism and all types of crimes, including spying and national security threats. False certificates or too strong encryption can thwart these lawful prerrogatives.

These two technical reasons have provided governments both with a reason as well as with an excuse to step in and issue or propose regulations for the Internet on a national as well as on an international level, regarding the issues of certificates and encryption.

Much controversy has been going on in the Internet  on this theme, both pro and con. It is not a purpose of this paper to add to this controversy or to take issue on these subjects, but rather to present and discuss factual data that is pertinent to the technical discussion of the authentication question. Besides, this paper focuses on the question of certificates, leaving the issue of cryptography for other efforts.

According with the TTP-certification initiative, or the PKI proposal, the certificates issued by CAs and the CAs themselves would be vouched by a complex chain of certificates that would all depend on some government appointed agency or seal of approval. Other initiatives, which can work together with TTP-certification, are the so-called key escrow or key recovery schemes, the Clipper chip, GAKware of the type present in the so-called International Cryptography Framework, or even propositions to cripple cryptography. All these methods, besides the obvious advantages of a legal and centralized control method, provide however a back door into each person's or company's private businesses by giving government agencies the possibility of easy decryption of otherwise private messages. One could add that these methods make a network systems insecure also by design, whereas before they were insecure by accident.

At the least, these methods may eventually represent the end of the Internet as we have it today: a free, essentially self-regulated and uncensored territory, with no visible national borders. While this is justified by some as necessary, "in order to control crime and anarchy",for others, "one should avoid the indiscriminate extension of government to the Internet".

Adding other political and commercial undertones, the US, the UK, Australia, Belgium, Canada, France, and The Netherlands have tried to or already did impose some kind of restriction on cryptography, authentication or CAs. A comprehensive survey is being conducted by B-J Koops, with data on almost all countries.

While some may consider this solution acceptable, its clear that not everyone and not every corporation want their private correspondence to be written as in an open postcard. Legal requirements, such as client-lawyer secrecy, patent rights and other internationally protected rights such as diplomatic mail, also need a different solution.

Against the expansion of centralized control, the OECD (Organisation for Economic Co-operation and Development ) has issued its Cryptography Policy Guidelines, that clearly states:

Thus, while it is clear that all the models reviewed (e.g., X.509, CA, PGP, SKIP) do not offer adequate certification and actually demand some type of control -- in order to avoid crime and anarchy -- the consequences of such a control (e.g., TTPs, GAKware or key escrow) would jeopardize the free use of standard Internet practices, such as PGP mail encryption, SSL-enabled connections, etc.

3. Meta-Certificate

X.509 Certificates, CAs, PGP and SKIP need some type of centralized certification control systems in order to be useful in commercial situations. This is the conclusion of each subsection. There is therefore a basic systemic conflict between this need and the Internet architecture -- which is totally decentralized and very independent in actions as well as in form. A solution to the certification problem, both from the technical as well as from the legislation viewpoints, would be to construct a decentralized certification method. -- a par with the Internet architecture. Such a system would not need any type of centralized certification control systems, and, further, would make centralized control near to impossible just as it is near to impossible for anyone to control the Internet today. Actually, since some conjecture that no one could control the Internet, this would -- in a dialetic way -- make the whole system safe and stable in its own self-regulated orbit.

However, would it be possible to devise such a certification architecture?

Also, no entity or country controls the Internet. And yet, it works and expands. Could this evolutionary concept be also applied to certificates?

The Meta-Certificate Group - MCG, an international non-profit open group, is reaching a positive answer for both questions. These answers need to be verified and critized in the Internet way -- openly and as it is done -- to be coherent from the start.

The MCG is currently drafting a proposal for an open standard-track Internet RFC, describing a layered certification protocol tentatively called "Meta-Certificate", designed to enhance security and flexibility, that will allow either standalone operation or interoperation with current technologies such as X.509, CAs, PGP, SKIP, etc. This proposal is also an attempt to make it possible to use the Internet without violating the laws of any home country.

The first draft was already released in April 1997, for preliminary discussions within the MCG. Essential parts of the proposal itself were presented to the general public in draft form in various MCG documents, such as the MC-FAQ, the MCS Presentation Plan and the various published papers, published e-mails and in the e-mail repository of the public discussions in  mcg-talk. The draft is being currently exercised in pre-commercial software, in order to allow it to be presented as coherently as possible with the design goals.

No parts of this general work will be patented, but published -- including source code -- and shared under the common protection of the copyright law to avoid third-party patenting. Members of the MCG will profit by contributing towards a better and easier communications standard and by being at the forefront of said development. Applications will be independently developed by any individual or organization, not necessarily connected with the MCG. Presently, the entities that compose the MCG envision and are actively developing software for the following applications that will be marketed worldwide:

It is noteworthy that because the Meta-Certificate design avoids the international security issues it has the potential to be the vehicle of choice for international products and services -- a modern "lingua franca" in Internet certification. One of the design goals is to make it as transparent as possible to any national legislation in existence or in planning.

All interested parties, with all backgrounds, of all countries, are invited to cooperate with the MCG, especially in the listserver mcg-talk [8] , in order to discuss the drafts and help prepare the proposed standard. The MCG believes in publicly-discussed algorithms, design rules and limitations.

The MCG is connected by a moderated-entry free-posting anonymized-id list-server [8] located in a country [9] that currently has no restrictions on the use or distribution of cryptographic tools or any other area of cryptography or certification. All group members with names and e-mails, as well as all contributors to this paper, are held under absolute non-disclosure terms, hereby binding, unless otherwise explicitly desired in writing. If you want your name and/or company to be recognized as a contributor in this focused enquiry, please send an e-mail with your personal data, after you subscribe to the MCG.

It is the desire of the MCG group to be open and yet to protect the privacy of any and all who wish to participate or observe. This is in no way an attempt to violate any law in any country. The MCG is a fresh exploration of applied cryptography to solve real-world Internet security issues of today, for both individuals, corporations and governments, as represented by the current certificate and cryptography questions.

4. References

The author acknowledges helpful hints and discussions with members of the Meta-Certificate Group, especially L. Zorzella, L. Machado, and Nicholas Bohm MA (Cantab), Solicitor of the Supreme Court of Judicature in England and Wales, also members of the ssl-talk list, ssl-users list, cert-talk list, SPKI list, IETF S/MIME list Usenet newsgroups such as talk.politics.crypto,,, sci.crypt, and the Internet community. The names, e-mails and attributes herein cited are the sole responsibility of the bearers and this list does not mean their endorsement or responsibility in this work, which is the sole responsibility of the author, reflecting his viewpoints -- not the viewpoints of any corporation, company, agency or Governments.

1 It is interesting to comment on some aspects of identity, anonymity, privacy and security. There are cases for which the identity of the communicating partners is not necessarily relevant. Anonymous speech is useful in many circumstances, even when privacy is required. The US historical case of "Deep Throat" disclosing information about the criminal activities of President Nixon is one example of an anonymous though identifiable source, in a private and secure environment. The public release of RC4 algorithm information on the Usenet is an example of an anonymous unindentifiable source, in a public and insecure environment. To assure anonymity is sometimes as difficult as to assure identification. This paper however deals with the commercial relevant cases of identification neeeds.

2 The X.500 describes a set of rules to obtain worldwide Distinguished Names (DNs). There are also many simple alternative rules such as using business names for DNs, e-mail addresses, postal addresses, fully qualified phone numbers, random long identifiers, hash values of any or all of the above quantities, etc.. For personal communications, sometimes Social Security Numbers (SSNs) are used in the US, but some regard this as an intrusion in their privacy rights. A major problem with the use of SSNs as DNs is that it makes it hard to control access to personal information once the SSN is made known.

3 This is also a problem for PGP and SKIP.

4 Besides the problems presented in the text, it is worth mentioning a few other cases. Requiring the user to check with a CA before sending a message makes the use of multiple CAs much more difficult, unless they can be convinced to work together, an interesting problem for competing businesses. Constant checking with a single CA also makes traffic analysis much easier. Even if the attacker cannot intercept the message which is sent, if the attacker can monitor the central CA (with a single administrative order and a GAKware system to circumvent any encryption), everyone's communication patterns can be seen. Also, an attacker can fool a CA into revoking a key -- a denial of service attack.

5 There are several examples of this logical principle, in which the user has to rely on an expert, as in Hartong v. Partake, Inc., 266 Cal. App. 2d 942, 966, 72 Cal. Rptr. 722, 737 (1968); Hefferan v. Freebairn, 34 Cal. 2d 715, 719-20, 214 P.2d 386, 388-90 (1950).

6 This is a logical situation where the user can see that the information appears correct as given but can not check it using reasonable time and effort, as in Mariani v. Schonfeld, 126 Cal. App. 2d 187, 189-90, 271 P.2d 940, 942 (1954)

7 All users are expected to know -- is this reasonable? -- that in the US the Uniform Commercial Code indeed treat data processing services on a different footing, so that the jurisprudence given in [5] and [6] does not apply in this case. In other countries similar restrictions may also apply.

8 An anonymized-id list-server is available. It is based on majordomo, which was changed by the staff at Novaware to have the following characteristics: (i) all postings to the list are stripped clean of all source and routing information, retaining only the subject, date and body fields, with no attachments or MIME fields, the postings are anonymously identified with an anonymized-id -- a "salted-version" of the SHA-1 hash function of the sender's e-mail -- and then echoed to the participants, (ii) any participant can post and receive posts, (iii) standard procedures are used to automatically subscribe and unsubscribe to the list. To participate in the mcg-talk send e-mail with an empty subject and only the following words in the body:
and please wait for confirmation from the list moderator.The list address is

9 One of the countries with zero restrictions is Brazil, where MCG Internet servers are located.

MCG - The Meta-Certificate Group, is an international non-profit open group. The MCG is a fresh exploration of applied cryptography to solve real-world Internet security issues of today, for both individuals, corporations and governments, as represented by the current certificate questions. The MCG Home-Page is at

Appendix: Changes, Additions, Examples

1. "Certified" Spoof Addresses: Kevin McCurley reports that he has obtained trusted Certificates from VeriSign, digitally-signed and cryptographically secure, recognizing "his" e-mail addresses of: "This is of course dangereous. On most UNIX machines, these e-mail addresses are associated with priviledged users or system administrators. If you received e-mail from root@localhost telling you to call a certain phone number to receive your new password, you might be tempted into doing so." This is an example of the following problems cited in the text: decision of trust (i), bad auditing (viii), e-mail certification (ix), relying partner (xi), spoofing (xii), CA disclaimer. Also, if and when the "certificates" were revoked, the following problems also surface: revocation lists (x) and, "hard-wired" certificates (i). Also, as cited in this Appendix, this is an example of "hidden" rules and presumed "certification". The same happens with certificates that show spelling errors as in  "Internet Serices", which could easily change context in an URL that exploits such mistakes.

2. e-mails as Distinguished Names: It is not a safe and reliable practice to use e-mails as DNs. It is relatively easy to define e-mail aliases that enable one e-mail to correspond to more than one person or entity. This can be done also without priviledged access, such as using a "root" password, if a normal user can change an include file that is referenced by the aliases file. Another way is much simpler: a user can simply register himself in more than one ISP, such as using an office account and a home account. This means that the function user <--> e-mail is not reversible in either way, for a user may have more than one e-mail and one e-mail may correspond to more than one user. Still another way is when the system is wrongly configured and you have e-mail collisions, as exemplified by the actual protocol Many other security related questions present themselves in this case, the least being a possible profissional conflict or competition between the two users, that the e-mail sender is not aware of. Note that in this case, the e-mail sender has not enough information in order to choose between the two recipients, lest the user knows them personally or knows their middle initial. This is an example of a system that accepts faults by accident or by wrong configuration, whereas a well designed system should not allow such faults to occur. This example also illustrates other security problems such as: an artificial increase in traffic, a possible denial-of-service attack, a spoofing attack, etc.

3. Check a root CA Certificate: This is a root CA Certificate. This shows that a CA Certificate may give you the impression of a correct document, as in a spoofing situation, that was accepted by your browser as in a standard Certificate format, with "exact" information about the CA, its name and e-mail. Besides, all the client and server Certificates that are derived from this root CA will carry the same information. Because the CA certified itself by itself, it is not possible to guarantee that the CA is actually itself or that its data are correct. Anyone can request server or client Certificates from that CA, increasing the security hole. As there is a very limited liability under the law, because the legislation grants the data processing service provider a special shelter, the usual CAs disclaimers (or lack of) actually turn the relying partners (servers and clients) into "blind partners" because there is really no reason to rely on that type of certificate.

4. Check a client Certificate: Whenever a server sees a client Certificate, it takes such data by their face value and proceeds to use the certified client's public-key because the client Certificate is signed by a trusted CA. However, client certificates may be subject to potential key-escrow or weak-keys when issued because of the current weak protocols used by Internet Explorer and Netscape. This also makes situations such as reported by McCurley much more dangerous when a known CA issues certificates with false data. Besides, in a Certificate chain, a known CA may rely on data from another CA and so on, which may all begin with a false premise.

5. Germany's policy: Germany's Government has proposed a strong ban on cryptographic applications.

6. Internet access blocking: Some countries block themselves from the Internet, where a sanitized intranet serves the country. The same happens in reverse, when entire countries or domains are or were blocked. In 1997, an entire ISP in Holland has been blocked from the Internet in Germany, because of some www pages published by one of the ISP's clients. In April 11th 1997, the XS4ALL website was censored by the Deutsches Forschungsnetz, the German academic Internet provider. This was confirmed by Dr. Klaus-Eckart Maass, managing director of Deutsches Forschungsnetz in a press release. The pages in question, however, were mirrored in other sites elsewhere in the world and it was thought that it would be near impossible to find and block all such sites. The same situation happened in Canada, with the Homolka case, with the result that it was indeed impossible to block the information spread and access.

7. Paradigm shift: One lesson to be learned from such cases as above is that Governments may need to adapt control policies to the times at hand. Everyone knows the story of the person that always used a hammer in his work and thus thought that all problems were nails. Modern problems need modern solutions. It is one of this paper's assertion that technology may provide the answer -- as well as it did provide the problem -- but the answer lies not in an increased control that would be impossible, rather it predicates a paradigm change: "The Internet is at odds with centralized control -- thus Internet control must be decentralized in order to be effective". Note that this principle does not imply the absence of some type of control or "checks and balances" situation -- that would be incoherent with this paper and with logic, but indicates a new type of control. This new type of control can already be felt in many areas, but especially in Internet newsgroups and list-servers. For example, the academic society that only used ftp and telnet was at first shocked by the "vandals" that invaded the Net after 1992-93, but the newcomers soon began to learn the working rules of a Netizen.

8. Too long expiration dates: As commented in item (vi), top level CAs may choose too long lifetimes, that may jeopardize security -- especially in view of actual possible short lifetimes, of the order of weeks as estimated in item (iv). This example, shows an actual root CA certificate that has a lifetime of twenty (20) years. Note also that there is no e-mail information, telephone, etc., to help the user decide if that certificate is valid, still, or if it actually belongs to the self-certified owner.

9. Expired Certificates: The expiration date in a certificate does not mean that it can not be used after that date, as one would expect. The user can decide, based on a set of open questions -- which compromises security, if he wants to accept it. As a test, the reader can connect to Conexware, using SSL, accept the expired (yes, self-signed) server certificate and enter a secure connection (albeit 40-bit US export version).

10. Spoofing chain: A spoofing chain is an operation that tries to obfuscate false data, by giving it a shroud of credibility based on secondary steps that may not be perceived as insecure by a third person. For example, to obtain a false ID a person might begin by obtaining a copy of a true birth certificate of a deceased person, faking mail addresses directed to that name, obtaining secondary IDs such as library cards and working up the ladder to reach a higher level ID and even a SSN. However, because of such frauds, some governments now stamp with "deceased" copies of birth certificates of deceased persons and routinely cross check IDs on a local and national level. This increase in government control of personal IDs is a parallel situation to the current increase of government control of "Internet IDs" -- because the public order is at risk. And, as such, it is perfectly needed and indispensable as explained in the "biscotti paradigm". See also the item below.

11. Presumed "certification": The issuing of a certificate that contains false data -- certified or not -- gives credibility to that data, which may be used for a second step in a spoofing chain. Thus it is not acceptable for a certificate to include fields that carry no verification, without explicitily declaring so, as the case with e-mails in current certificates. It is a poor practice to provide a "security" feature that can not be verified or enforced. It gives a presumption of safety to the unwary user. "In California, for example, each drivers license features a photo, several holograms, and a metallic strip for fraud prevention. But this didn't stop employees of the state's Department of Motor Vehicles from issuing bogus licenses to anyone willing to fork over the right amount of cash. An estimated 250 DMV employees have issued over 25,000 genuine-looking, but fraudulent licenses in a two year period. Some were paid as much as $1,000 for such licenses. 'Ironically, as our documents become more tamper-proof, it's become more of a problem', DMV Director Sally Reed admitted to the San Jose Mercury News", as reported by Nathan J. Muller.

12. Hidden rules: Certificates do not make clear to the user the complete set of rules that govern their issuance, maintenance, use and revocation. The user is not aware of the inherent limitations exposed in this paper and the limited coverage under the law and under the CA's disclaimer. For example, the issuer's disclaimer (i.e., the CA's) is clearly not visible in the certificate referred to in the first item of this Appendix, especially the fact that even though the user's e-mail was given as root@localhost in the certificate, that information was not being certified and the issuer was not legally responsible.

13. Trust:  (also, hard-trust and soft-trust) To exemplify some concepts of trust, let us use a scenario with two strangers (let us say Skywalker and Alice) that want to have a transaction or information exchange, for example with an exchange of values. Suppose Skywalker would acquire somewhere a list of TTPs so that Skywalker would input it to his server and then be ready for e-commerce transactions with Alice -- and Alice would do the same for her browser. Of course, these lists would be utterly useless regarding Skywalker's trust on these TTPs, as well as Alice's -- because trust is not something you accept at face value by someone else's classification of it, even if this someone else is some government because we are talking about the Internet and surely jurisdiction questions would appear, not to talk about civil rights questions, competition, etc. Neither can you accept it regarding something, but you must evaluate it yourself for the purpose you have in mind. The concepts of hard-trust and soft-trust are connected to the properties of trust that can be accepted, where hard-trust means safe properties -- hard-trust is not transitive (if you trust a friend, this does not mean that you must trust your friend's friends), not distributive (if you trust your lawyer this does not mean that you will continue to trust him after he trusts your competitor) and not symmetric (if you trust a person this does not mean that the person must trust you). On  the other hand, soft-trust is transitive, distributive and symmetric to a degree. PGP uses hard-trust to issue and link certificates but uses soft-trust for certificate maintenance, while X.509 uses soft-trust for all three activities. For further references on trust, hard-trust, soft-trust and the conceptualization of trust, see the next item (14) and Trust Properties, Towards a real-world model of trust, Re: Towards a real-world model of trust, [MCG] On the nature of trust plus a search for the word "trust" at .

14. Trust is relative to the user: Suppose we would paraphrase Augustine of Hippo and would discuss: "whether certificates are trustful because they certify, or certify because they are trustful.". Then, like him, we might give the "doubtless reply" that they certify because they are trustful. On one level this is a fairly straightforward expression of the objectivist stance that trust is a quality of the certificate itself, as opposed to the subjectivist stance that trust is relative to the user (or, in other words, "trust is in the eyes of the beholder"). However, the risk is borne by the user (ie, the verifier, the relying party) who is in the subjective stance, so we must reject here the notion that trust is somehow embedded or infused in the certificate and accept that trust must be a concept relative to the user's point of view. Moreover, the user's evaluation can differ for different CAs and for different certificates from the same CA, so a further overly-variable quantity is introduced and the user must take an inter-subjective stance in order to decide if that certificate in particular can be trusted -- which means that we must further reject the notion that trust is somehow supplied in batch-form from a CA to any certificates of the same class that it issues and accept that trust must be a concept further relative to each certificate issued, even for the same CA. Thus, uniting the consequences of both stances, for certificates "trust is relative to the user" and "certificates are trustful because they certify" -- not the other way around. The logical expression "certificates are trustful because they certify" has a far reaching consequence: that trust on the certificate will be transfered to the user not from the certificate itself (the objective view) but from the user's perceived assurance (which must be received from a different information channel than the certificate itself, such as legal reliance on a CA's CPS, friendship reliance on a PGP's web-of-trust or protocol reliance on the Meta-Certificate Standard) that the certificate will work as desired -- it will certify. Therefore, one may say that a certificate is like a tool, that is trusted because it is expected that it will work, while trust is a result of the user's perceived assurance on a set of declarations. The role of trust in certification is thus to be earned, not merely assigned. Of course, after trust is earned in a sufficient level it can be assigned -- but only if the environment is secure (as applied to the information community).

15. Subjective and Inter-Subjective: Subjective means that one needs to take a subjective or personal instance in order to evaluate an object, and Inter-Subjective meaning that this instance can yield different results for objects of the same class. For example, beauty and trust are subjective concepts ("beauty is in the eyes of the beholder" and "trust depends on the observer") because trust and beauty are abstract objects that cannot be differently instantiated, while a medical diagnosis for a patient is inter-subjective because the diagnosis itself is a particular instance from the class of all diagnosis possible for that patient at that time, each clearly dependent on the patient's relationship to the physician and different from the other. An inter-subjective concept is overly-variable in reference to a subjective concept, because it also depends on the particular instance of the class' object. So, even though trust is subjective, trust on a CA certificate is inter-subjective because it cannot be harmonized or harmonizable for all CAs or, even, for all similar certificates issued by a particular CA. See the discussions above on Trust and Trust is relative to the user.

Reader Feedback

Do you think this paper gave you new information or a fresh look at the problems cited? Then, if your answer is "Yes", please contribute with the dissemination of this information by setting up a link to this page. You can also e-mail the author or, participate in the open list mcg-talk. However, if your answer is "No", please let the author know and explain your viewpoint.