The MCG Threads

The MCG-THREADS

Edited by E. Gerck
(updated until 07.May.97)

This is a summary of the main points posted to the mcg-talk list, that contributed to the MCG discussions on issues related to certification procedures, X.500, CA, PGP, SKIP and Meta-Certficates ( a work-in-progress at the MCG, participating companies and individuals). The references cited should be considered as viewpoints, some of them contradictory, some of them wrong and some of them expressing work-in-progress, moderated and selected by the MCG coordinator, Dr. E. Gerck. The Threads are not alphabetically listed, but follow thread order in the discussions. Since the mcg-talk list is anonymized, the topics are also anonymous.

The Threads sometimes refer to the Overview and Authentication papers, published by the MCG, as well as the Identity e-mail also selected from the mcg-talk.

1. X.500 versus Atributte Certificates: what does ISO say?

It's possible to include all sorts of weird and wonderful things as X.520 attributes, including phone and fax numbers, etc. Unfortunately a lot of these assume everyone uses ISO standards (which is pretty rare) and don't allow for non-ISO stuff (which is pretty common). Newer, not-yet-finalised X.500 versions fix some of this.

2. How about CRLs?

Comment 1: CRL's are really messy. I've seen them described as a type of antimatter which wanders around until it collides with the certificate matter, at which point the two cancel out. This leads to all sorts of problems such as what happens if the matter/antimatter collision never occurs, or if it does occur but takes a long time to propagate (for example there was a study done in the US some time ago which examined the effect of CRL propagation from one side of the US to the other and looked at how many millions of dollars per minute could be lost in electronic trading if it took X amount of time for the propagation and people were using revoked certificates).

Comment 2: And like PGP, once you get your key into a key server, it's there forever. I've got several keys stuck in servers that I can't get rid of, and I have forgotten the pass phrase to them. Substitution isn't a problem, inability to revoke might be (but not really, anyone who sends me a message won't get a reply :)

Comment 3: I cannot guess that my key was compromised until I get a loss (maybe only one loss, maybe the first and last). I can do a risk analysis, but the variance is large and there are other problems why I may not want to change my X.509 keys every 4 weeks (cost being not the weakest factor)

Comment 4: I think we agree that CRL's, in whichever flavor (X.509, PGP), are a problem to try to solve a problem.

3. Could a CA Certificate include a disclaimer, like the actual CA Disclaimer shown in the Overview paper, so the user knows the risks?

The disclaimer shown is an example of the sort of thing which might get included in a certificate, which makes it mostly useless because it's no longer machine-readable - the whole point of a certificate is to have a machine-readable assertion.

4. How about CA warranties. Are they responsible for their services?

Comment1: First off, and this has less to do with a technical side and more to do with the legal/business/my-jaded-view-on-society side, but if you were a technology based firm, specificly dealing with Internet/computer security, would you guarantee anything? With the over-abundance of lawyers in the US alone, and the growing attitude of "I got burned by being stupid so someone else needs to be published" it would be suicidal to guarantee much of anything. Even organizations like the WheelGroup, who charge as much as $75,000 for site security evaluations, don't guarantee anything .... they just make it harder to get in. To quote one of their employees, "The only secure computer is one that's turned off, locked in a safe, and buried 20 feet down in a secret location - and I'm not completely confident of that one either" Remember, the goal of MOST security-related implementations, whether its an encryption algorithm or a firewall, is to make it more costly for an intruder to get at the data than the value of actual data itself. (did that make sense?) For a different angle, lets take a look, for example, at what these CAs are trying to do. Take Verisgin, for instance. Verisign is not saying that by using their certificates people are guaranteed other people are who they say they are. They are saying that there is a HIGHER level of probability that they are who they say they are. Using a level 3 cert from Verisign means Verisign confirmed through policy X that user Y is who he says he is, right? However, this is worthless if that user takes that cert and sticks it on a public computer in the local library. So, in a sense, you are correct in saying that things can be a bit misleading - however the CA is only part of the equation....

CA's having internal bugs: this IS something I think the CA should be liable for. And as for the CA not being able to be held liable: Well, I think they should be held liable for their end of the bargain, meaning: - They can provide a reliable system for issueing certificates - Their root CAs are secured - They publicly state and adhere to their issueing policies However, once they issue a certificate, where that certificate goes and what it is used for is really out of their hands.

CAs warranties : The points discussed in the Overview paper are mainly (on that thread): - All CAs are inherently flawed by X.509 and X.500 - The American UCC says that CAs are not responsible for results - With increasing litigation, CAs are correct in exempting themselves. - No CA can guarantee certification -- ever. All CAs have the same problems. Some CAs actually could be a bit better than the majority because they could have a higher reputation to risk (remember: reputation is above the law; the UCC says CAs are exempted but the market demands otherwise)

5. Are the base technical documents ambiguous?

Ambiguity of RFCs, documents, etc: agreed! However, I think the agreed web-based cert is pretty much standard, and the SET spec is, too. I prefer to think of it along the lines of SNMP: you have a defined MIB, with room for expansion. The people who write RFCs should take more lessons from writers and fewer from lawyers. :)

6. Directory needed for Certs.

From what I can see, a lot of companies are really working on this. I think the whole LDAP movement will help immensly, as well. Multiple copies of a cert: yes, however, products make this easy to deal with, or rather, products not written by MS make this easier to deal with.)

7. Is there a false sense of security in certficates?

CAs give a sense of security that is not there -- and will not be if the current standards are not changed.

8. Who is responsible for what?

If you take a look at the Internet, each provider holds up his or her own piece because its in their best interest to do so - if they don't, their clients will leave. However, no provider (or very few) guarantee much of anything...just that you'll be connected to THEM at speed X and that you may or may not be able to get to site Y. With CAs though, I would think you'd need something a little better than this, and the model could break if someone didn't keep up with their end of the deal. Heck, to use the Internet example again take a look at the SYN floods of last fall. If all providers setup simple filters to DUMP spoofed packets from THEIR network (meaning, if my IP range is 1.1.0.0 and something claims to have a SOURCE address on my segment of 2.2.4.1 then dump it) the problem wouldn't have existed - or at least not as bad. The truth is, some providers are barely capable of maintaining a stable service, and barely understand and/or bother with these higher level issues.

9. PGP certification

PGP key signatures work in the domain space and are thus able to bind public-keys to people's identities, defining a certified set (person, private-key, public-key). Any hash function of the form person --> identification can now be uniquely defined and reversed, where anyone can encrypt but only (person, private-key, public-key) could decrypt. Thus, PGP offers authentication in both spaces, domain space and image space.

10. Are X.509 certificates *inherently* hierarchical?

No: They are only hierarchical in the implementations that have been made of them primarily recently. While the X.509 certificate format was indeed designed for use within the Directory, there is nothing constraining its use to that kind of a format. A good example to look at might be the case of S/MIME. In S/MIME, the distinguished name for the X.509 certificate is normally only a common name and an e-mail address. This is hardly hierarchical at all. And the trust model is much closer to the web of trust idea than to the hierarchical VeriSign model, although it incorporates elements of both. When you send an S/MIME message, you include with it as many certificates as you think necessary to insure trust. So while frequently only your own certificate is sent, it is quite possible to send fifty other certificates, *all* of which have signed yours, and if the receiver trusts any of the people who signed any of those fifty certificates, they trust your message. How is that inherently hierarchical? Another example is in what has been mentioned below, with the case of individual CAs, which are cross-trusted. Several companies are currently distributing software allowing small companies to act as their own CAs for corporate Intranets. Entrust Technologies has a free version which will deliver 25 certificates downloadable as a demo from their web site (http://www.entrust.com/). Netscape Certificate Server is free for educational or non-profit use, as well as for evaluation. (http://www.netscape.com/) XCert and Frontier Technologies also have their own software for being your own CA.

Yes: I can recognize in X.509 and derivations, three types of elements: (i) built-in but dispensable, (ii) inherent and, (iii) that can be added without breaking the basic rules. Of course, if you go for classes (i) or (iii) it may not be X.509 anymore, but, who cares? I don't. Take the Directory hierarchy, I think it is class (i). The certificate redundance you speak of, I would say it is class (iii). DNs as common names + e-mail, I think it is class (iii). However, any of those fifty certificates are class (ii) for their root CA, even if one of them is self-signed. You should have a server certificate and a root CA certificate at least. Note that it is not practical (known cases) to have just the root CA. This is the dependence I mention as inherently hierarchical. But it is more a matter of semantics if everyone agrees with that or not. The main point is that X.509 need some sort of central control. This is the ultimate inherent hierarchy, class (ii).

11. The cafeteria example (various forms)

Assertion: Suppose I would go to the cafeteria and would try to find you, using a msg encrypted with your public key. Would I suceed? No! That is, the definition that a key "speaks" for the owner, i.e., that an identity is established by the "key pair", would not be sufficient to establish your identity in the cafeteria.

Against: It might not be sufficient to find me, but -- once found -- it would certainly be sufficient to *prove* that I am the owner of that key. No one else would be able to encrypt something such that the key could decrypt it. Also, you would fare no better with a PGP signed key than I would with an unadorned key.

Final: That's the point. I would certainly, surely, absolutely, fare better with PGP, but not because I would use the signed key -- but because I would use the "web-of-trust" and ask one of my friends that knows one of your friends, that will show me you. You are forgetting that PGP offers one more constraint than X.509 , SKIP or SPIK: the "web-of-trust". Logically, one more constraint means one less degree of freedom. Thus, without PGP's web-of-trust, knowledge of a key pair is not sufficient to distinguish an individual (that is the "octopus question", see below). Unless, of course, that individual is permanently tattoed with his public key in a publicly visible area, does not mutilate himself by cutting that area, memorizes without fault his private key and has access on demand to a computer that can perform the necessary calculations. But that is also not in X.509, SKIP or SPKI, hardly.

12. The octopus example

Supose that some large corporation were to identify its personnel by "mere possession of a particular [private] key (pair)" as you suggest. Such unique key pairs are not adequate to disambiguate an individual from the point of view of all possible key pair holders. Supose that Alice has an old friend, Bob Jones, at IBM. Although she has a unique public key from IBM for each employed Bob Jones, and one responds to her encrypted message, she can not trust him (or, in fact, any of them) to be her friend. Therefore, the "mere possession of a particular key" has failed in its task of binding identity to the key. If you compare the Internet to an octopus, with any number of like "arms", then they seem alike to you.

13. Are identity certificates necessary?

No: The Internet itself changed the world from the one in which identity certificates were considered necessary. As Internet use increases, we increasingly interact with people or companies with whom we have no relationship in the physical world. A transfer of relationship from the physical world to the digital world is meaningless in such cases. Instead, we need to establish relationships directly in the digital world through an instrument which assigns attributes (authority, permission, ...) to the digital principal. We call that an "authorization certificate". SPKI certificates were designed to perform that function by directly specifying the <auth,key> binding which is of interest in the digital world. You are clearly trying to make the mapping from physical world to digital world. SPKI, on the other hand, recognizes that "identity" is inherently ambiguous and doesn't attempt to solve that problem.

Yes: ... a comment on the thought that a machine might have an identity for the purposes under discussion. I want to suggest some reasons why this may be unhelpful, at least at present: (1) I still have my grandfather's axe. My father replaced the blade and I replaced the handle. (2) Without wishing to adopt a position on the possibilities of artificial intelligence, it has not yet arrived. Machines are still different. (3) "Personality" is a concept known to the law. It belongs to human individuals and to a variety of corporate entities recognised by law as having legal personality. Only a person known to the law can own property, have rights and be subject to duties. I think that a proposal which accords with this classification is more likely to be successful than one which includes the possibility that machines can own things. I don't mind my refrigerator having its own IP address if this serves some purpose, but I don't want it to sue me for not maintaining it. I think it will be a long time before an appliance can get into an argument. The identity of a refrigerator is much easier to discern than that of a "personality". If the task is to determine _identity_ then we should be able to authenticate a machine very easily. If the task is to determine "personality", then the problem is much more complex. This leads me to question the human-machine interface. It may be simpler to certify machines, and let the human(s) who has(ve) access to that machine determine the personality represented. You can certify that a machine is owned by some individual or group, you may not be able to certify that the individual or group actually sent a message. In some sense the certification process is only a connection between human and machine. I certainly don't want an implant to prove I'm part of the net, and I'm not certain how a simple process could prove the connection. The "slow interactions" of normal human interaction seem to be a good place to start.

14. What is being certified?

An identity? An identification? Both? Neither? An attribute? To place the discussion on a logical basis, the question was re-estated in a mathematical framework in the Meta-Certificate project, as simplified as possible. This framework begins by defining identification as a hash function of identity. This, in turn, defines the domain space (where the identity lives) and the image space (where the identification lives). Because the hash function can not be reversed, this introduces an asymmetry into the problem. Public-key encryption enters the scene as a tool. The fact that PGP can use the "web-of-trust" to authenticate a person means that PGP offers authentication in domain space. The consequent authentication in image space is trivially proved. Note that X.509v3, SKIP and SPIK cannot offer that. They are only able to offer image space authentication. Domain space authentication is subject to error.The conclusion that PGP is the only method (among X.509v3, SKIP, SPKI) that coherently allows for authentication in one space to cross to another space should not be such a surprise, because PGP is the only method that works in the domain space and allows for a well-defined binding between identity and the key pair. The other methods work in the image space and are thus blocked from a unique backward connection to identity.

15. The concept of web-of-trust and Domain-Space certification

http://www.pegasus.esprit.ec.org/people/arne/pgpdoc2/pgpdoc2_2.html#10

"If you get a public key from someone that is not certified by anyone you trust, how can you tell if it's really their key? The best way to verify an uncertified key is to verify it over some independent channel other than the one you received the key through. One convenient way to tell, if you know this person and would recognize them on the phone, is to call them and verify their key over the telephone. Rather than reading their whole tiresome (ASCII-armored) key to them over the phone, you can just read their key's fingerprint to them. You can both verify each other's keys this way, and then you can sign each other's keys with confidence. This is a safe and convenient way to get the key trust network started for your circle of friends."

16. Fraud and the Net

A Deloitte & Touche report commissioned by the European Union says that cross-border fraud involving Internet abuse, banking and investment frauds, and smuggling is costing society $77 billion a year. The report suggests that perhaps the largest single threat comes from fraud through the Internet, because encryption technology remains vulnerable to sophisticated computer vandals. (Financial Times 24 Apr 97). The report is available to members of the MCG, as a cooperation from Deloitte & Touche, by e-mail in the list mcg-talk.

17. What would be a slow authentication, in the sense of the Identity e-mail published by the MCG? The author (N. Bohm) answers.

I caused some understandable doubts about what I meant by "slow authentication", an expression of regrettable lack of clarity. What I had in mind is that in the course of commercial and social life the accumulation of identifiers over a period of time, thus "slow", provides strong evidence that I am not faced by an impersonator. If a fellow lawyer has had his name in the telephone directory and official lists of lawyers for twenty years, if I can speak to him by telephoning his office, if I can meet him when I call there and he is recognised by others in the office or at professional meetings, he is probably not an imposter. (It cannot be certain: elaborate conspiracies can happen, especially in espionage by governments.) Similar certainty may be very difficult to achieve by "one-shot" methods such as the tests used by VeriSign. My signing his PGP key doesn't tell anyone how sure I am about him, but at least it tells them I think I know something worth them asking me about. I agree that after a sufficient series of electronic interchanges between two entities whose consistency is ascertained by (for example) PGP key authentication and encryption, each side may have a clear picture of the of the other. (I pause to note that a group of people could share a single key-pair, so that one side of this exchange, or both, could be a group rather than a single person.) In such a case there is no effective connection between the electronic world of communications and the personal world of social contacts and personal knowledge. You could meet your correspondent at a dinner party without either knowing they had met in person. That may not always matter, but often it does. I say no more about this than that it is important, in formulating proposals for certificates or schemes, to ensure that people can understand clearly what the proposals hope to achieve.

18. Anonymous entity with identification and certification. Possible?

No: For my own definition of anonymous, I think it is ultimately impossible to certify an anonymous entity, or even an entity hiding behind an impenetrable, persistent pseudonym. However, it is possible to use certification-type principles to transfer one individual's knowledge of a distinct (apparent) entity to another individual. This sounds a little unclear, so let me provide an example. Two or three years ago, there was an individual who periodically posted crypto-related software to the Cypherpunks mailing list (for example, see http://www.unicorn.com/pgp/mm-readme.html). The entity always signed its posts "Pr0duct Cypher" and PGP-signed them. Hence, over time, people were able to associate a particular PGP key with a particular (perceived) entity with a certain personality and a reputation for good crypto knowledge and coding skills. Now, can one issue a certificate of some kind for Pr0duct Cypher (or PGP-sign his/her key)? Sure, but all one can authenticate is the persistence of this personality (non-legal definition). There is no known mapping from the identification to any actual identity. And, since every one of Pr0duct Cypher's posts from the very beginning could (theoretically) have been intercepted and re-signed by a man-in-the- middle, there's no way of even being able to say for sure that the author of the code is the same individual who signed his/her posts as Pr0duct Cypher.

Yes: For instance, you are anonymous to the list but you have a known characteristic (among others): your hash number is 324946. And this identification will even remain the same (persistent) in our next e-mail exchange (it wouldn't have to be so, you could have non-persistent identification and still have an identification -- however just so your e-mail is not confused with some other e-mail). So, you are an anonymous entity with known and persistent identification and thus certified.

Yes, and even with a signature: For example -- a simple case -- you could be anon in the mcg-talk and use the alias Skywalker. Suppose other 10 people also do the same, with the same alias, in the same list. You are still identified differently because your list-provided hash is different, e.g., your hash is 132562. This means that the mcg-talk list allows another user (Alice) to bind an identification (132562) to your alias (Skywalker) and to your attributes (writing style, arguments, viewpoints). It is now a simple matter to exchange public-keys that will allow you and Alice to establish a secure and private channel using an insecure and public network, while you remain totally anonymous to Alice and to the list. This example shows also that: 1. Skywalker can be anonymous to a set of entities (the list except the list-owner) while it is not to the list-owner. 2. Skywalker can use an anonymized remailer to post to the list and be anonymous to all members of the list, including the list owner. Going back to key exchange, it is simple to exchange keys if you do not worry about mitm ("man-in-the-middle") attacks. They can be also be taken care of, but since this would take us too far, let's keep it simple. One way to do it, would be for Skywalker to send his PGP key in one of his messages, that everyone and Alice would read. He would be authenticated by his list-hash number so Alice knows it is his key. The same would be done by Alice, so Skywalker would know Alice's PGP key. This means they can mutually sign and encrypt messages. Skywalker would know that Alice's message came from Alice because it would be digitally-signed by Alice, and vice-versa. Then they can use the list to exchange messages that would be private, secure, digitally signed, identifiable and yet anonymous.

19. Certification: who certifies? The server? The client?

Suppose Joe Doe wants to buy a pair of shoes that cost US$ 100. Then the seller, who does not care about Joe Doe (excludes this information) needs, however, to do a certification process on the monies that Joe Doe will use to pay for the shoes. In this case, Joe Doe gives the seller a 100 dollar bill. The seller (the active side) needs to certify the dollar bill (the passive side, the supplier of information, the "server"). The seller sees that it is a US$100.00 bill, good enough and certifies it to his own satisfaction that the money is acceptable. He has certified the dollar bill. A "connection" existed in conceptual terms, because there was information flow and this flow happened not from Joe Doe to the seller but from the object (the bill) to the seller. Here communication means the "flow of information" and "information" is understod in Shannon's sense, then if you don't have the flow of information you cannot possibly have information for identification (mind you, new information because old data has no information content).

20. Meta-Certificates and anonymity

In the discussion of the concept of anonymity I think we should remember the need to connect meta-certificates in a sensible way with the practical purposes they must serve in the "real world". With this in mind I suggest that an entity is anonymous if it cannot be identified with a personality, i.e. a person known to the law who can be sued and can own property from which a plaintiff can obtain the fruits of his suit. It is no doubt often important to be sure your conversation is with the same person over an extended period without it being necessary that you can say whether or not that person is your next-door neighbour. But if you are injured by that person and wish to sue, then if they are anonymous you willfail; otherwise you may succeed. I digress from anonymity to say that in my last paragraph there may be practical problems about what "the same person" means. In the case of a corporation the individuals representing it and indeed controlling it may obviously change over time while the corporate person remains the same. Even in the case of an individual, a group of friends might share an Internet identity so that the actual author of the correspondence might change without any apparent change in the entity participating. In making this perhaps obvious comment, I mean no more than to indicate that we must be careful not to let the language of the definitions (however formally accurate) mislead us about their practical significance in an applied system.

21. Why define?

Definitions are necessary to clarify and quantify the discussion, the secondary definitions, logical proofs and inductions. Many of the key terms used in this proposal have been subject to much use and abuse, often conflicting. In the famous Lewis Carroll passage, one can read: "When I use a word," Humpty Dumpty said in a rather a scornful tone, it means just what I choose it to mean--neither more nor less." While most of us agree that Humpty Dumpty's attitude is not too useful for :public discussions, technical terms may have radically different definitions than standard usage. First, I have to explain that we are defining a technical language, which may not resemble the layman's use. Just like in law, when you use the word "robbery" you mean a very precise definition, whereas the common person uses robbery for theft. "In particular, the information of information theory has little to do with knowledge or meaning, concepts which defy precise definition, to say nothing of quantitative measurement. In the context of communication, information is simply that which is produced by the source for transfer to the user." This is the example we follow. Technical, precise, quantitative meaning-- whenever possible. Besides, different dictionaries in the same language often have conflicting entries. In different languages, the differences between similar concepts are even larger. The situation is actually worse if you take language dictionaries (after all, the Internet is international) and try to follow a word through a series of dictionaries, such as english --> german --> spanish --> swedish --> chinese --> portuguese --> english. Some entries won't even translate. The reason why one of our efforts should be to define the terms is because we will be using boolean expressions and logical inference on those terms. hen, the key to your bank account might depend on the correct interpretation -- as precise as a good programming language -- of the term anonymous. You may have an anonymous account and yet be precisely identified as yourself, without any biometrics. You may have the equivalent of cash in your hands and anonymously buy software -- to which you are entitled a named warranty (using your identification) that is enforceable by "reputation". The question of degrees of anonymity, security, etc. is, imho, a different thing. It is implementation dependent. We all know that the one-time-pad is considered 100% secure in cryptographic theory. Implementations will strive to reach this limit. For example, after considerable discussions in this list there is a consensus that the concept of anonymity is relative and transient. But we do not have to define the % of relativity or the lifetime.

22. Anonymous: a matter of degree?

Comment 1: Untraceability is, like security or tamper-resistance, a matter of degree; I don't believe it is moot simply because the effort needed to remain strongly untraceable is relatively large. I suspect the same applies to anonymity.

Comment2: Actually, I think that "anonymous" is not properly applied to entities but to the communication mechanism itself, and perhaps to messages. At best, applying the term "anonymous" to entities seems to be useful only as a relative measure -- within the context of a conversation. Any document or message has the potential to provide a link to its author. A plagiarism program might show that link; or the author might directly reveal their identity. The document can be initially anonymous and later unanonymous. Another document by that author may remain anonymous. Is the entity then anonymous or unanonymous? (This subtlety is easily overlooked when one equates "anonymous" with "pseudonymous.")

23. Persona:.

The definition must be consistent with the indirection level needed by international affairs (a personality in UK may not be so in Iran), but not many people are used to this kind of thinking. Also, a minor surely has legal rights and duties, but not fully. The definition would be "Personality: Entity with legal rights, duties and capaciites." and the comments would explain the other concepts, including the fact that the rights and duties are without restrictions -- whatever that may be in the particular land ;-) The law recognises that a person can make contracts and own property, and these abilities are correctly referred to as capacities (rather than rights or duties): in cases such as minors or those of unsound mind it is commonly the capacities as much as the rights and duties that are affected. English judges, when wishing to sound quaint, sometimes refer to a corporation as a "persona ficta" to emphasise that its personality is artificial and conferred by law rather than nature; so "persona" for the present purpose would be fine.

24. Identity:

"The collective qualities and characteristics that belong to an Entity over time." because you cannot eliminate one attribute without (maybe) changing the Identity.

25. Name:

Name would be "An identification using signs and symbols, not necessarily permanent, unique or singular." In this case, Identification clearly refers to "the hash function of the collective distinctive qualities and characteristics that belong to an Entity", so the term Entity does not have to be included in the definition. The inclusion of "signs and symbols" would avoid the notion that a concept could be used. Not "unique" refers to the fact that other Entities may have the same name. Not "singular" means that one particular Entity -- i.e., with a unique Identity -- may have more than one Name (alias or pseudonym).

26. Distinguished Name:

A unique and singular Name. A DN may not be permanent (for example, marriage, moving, changing jobs, etc.). A DN may be a random number. In this proposal, the cryptographic hash of the public key will be used in this meaning in the MC proposal, forming a token called MC-DN.

27. Anonymous

The concept of anonymous is not inherent, like the racial characteristics or the DNA sequence -- which will remain unaltered during the lifetime of the person. Also, an entity may be anonymous to some and not to others. So, anonymous is a relative state -- it depends on the observer and it may change. So, anonymous would be: "an entity in a relative state of void personality." Technically, an anonymous entity may have an identification -- that is, a name -- and yet remain anonymous. Could also have a DN or MC-DN and still remain anonymous. Anonymity is a characteristic of a particular transaction: the sender of a message may be anonymous to me when I receive it, although known to others that receive copies at the same time, and may become known to me at another time.

28. Anonymous versus Unaccountable

Comment1: I think it is important to note the difference between anonymity and accountability. For example, this mailing list could require a deposit of $100 with enrollment. If an anonymous author libelled an identified person, for example, that $100 can provide accountability without identifying the anonymous author.

Comment2: This is an important difference, i.e., anonymous x unaccountable. Without choosing sides (yet), I would like to direct the list's attention to http://www.shipwright.com/rants/rant_15.html and look for the word "Vinnie". This should take you to a nice example of anonymous accountability -- and the related problem of "reputation" as a basic concept that is even able to reach where the law cannot.

Comment3: I think that the case of the deposit of $100 is interesting, but may not be of wide consequence in principle. I would see it as a case where an anonymous person appointed a known person as agent so as to render himself accountable up to the specified limit. The holder of the deposit must be a known person to enable the victim to enforce payment of the compensation out of the deposit. I do not think the fact that an anonymous person can expose himself voluntarily to liability undermines the consistency or usefulness of the definitions. Being unaccountable may be part of being anonymous, but this is not necessary, as 324946 has ingeniously demonstrated. Turning to the rant, the question relevant to our present purpose is a social or political one. Will people be willing to trade with anonymous entities on the basis that they cannot afford to default because of the effect on their reputation? If so, then knowing an identity in domain-space is not essential because resort to law (which depends on that nowledge) is unnecessary. In that case we can just all live together appily and electronically ever after. As that slightly sour comment may suggest, I think the answer to thequestion in the previous paragraph is "NO". Reputation is too frail a vessel to carry the load. Look in the newsgroups for the complaints, by no means always unjustified, against major software providers for releasing shockingly defective software to gain a market lead over opponents. Look how successful that tactic has been for some traders. Also consider the small trader, who may be ruined by an unjustified attack on his commercial reputation by an unreasonable but powerful customer. I think that for the protecxtion of the weak from exploitation or oppression by the strong, resort to independent dispute resolution methods backed by enforcement at the behest of society as a whole is an essential foundation for fair trade. If that is right (and it essentially a view about human nature), then the client in the MC system must be able to know from it whether or not the client can connect the server to a person in domain-space.

29. Discussion of the Slide document

Slide 3: In slide 3 it is written that the MC "eliminates the binding of identification with public-key" This means that we do not use the central procedure of X.509 and CAs -- as described in "Overview of Certification Systems: X.509, CA, PGP and SKIP": "In other words, the purpose of a Certificate Authority is to bind a public key to the common name of the certificate, and thus assure third parties that some measure of care was taken to ensure that this binding is valid. " So, slide 3 says MCs don't do that. How does MCs then certify the certificate owner if it doesn't use the cryptographic key? See (30) below.

Slide 4: As explained, under Exclusive Concepts, first line: "MC-DN -- no TTPs, no PKI, no key-escrow. Uses a crytographic hash with the public-key as one of the owners Distinguished Names, which can be used to publicly certify the owner. " This means that the owner is certified by a binding of hash{public-key + ..} with his identification. How does this certification works? In the same way that other certification works: by making it cryptographically possible to determine if the owner is he who he claims to be and cryptographically impossible to fake the owner.

30. Skywalker rides again

Simple e-mail certification: Suppose your name is Skywalker, your e-mail is E, your public-key is A, and the hash of your public-key (simply that in this case) is MC-DN = hash{A}. Then you can have at a CA (could also be in a PGP-"hashring", a smart-card, etc.) , the information (in a public-MC) that Skywalker is linked to MC-DN and has e-mail E. Now, Bob wants to contact you. He gets that info from the CA (or whatever) and contacts you directly over e-mail, asking for your public-key. You supply A and Bob verifies that MC-DN is indeed equal to hash{A} -- so he certifies you and sends you a message using the key A. Of course, methods are provided in MC and MCC that can make that all automatic, as an e-mail handshake. The same can happen in http/s. Since it is considered impossible to calculate A if one knows MC-DN (when cryptographic hash is used) then this means that no one could impersonate Skywalker. Also, if the CA does something wrong and mixes up your MC-DN, no harm is done because no one can can encrypt any message, with the MC-DN and the handshake with you would detect that the either the MC-DN was wrong or the Key A was wrong. Then we go to slide 13, the last. There we read in section "key-binding", first item, the MCs "Uses key-hash (MC-DN) to certify keys", which is what we have done. It also says that MCs "Enforces handshake with primary recipients: secure and fail-safe" which is what we have also done, when Bob asks Skywalker for his key and certifies it based on the CA certificate. Note that the CA certificate could have been a PGP-hahsring or even both, or neither. It could be the CD-ROM with the software that Skywalker is selling, or ... any other authentication channel. Note also that the MC-DN is *not* a key (nothing gets encrypted by it). o, TTP legislation and key-escrow are totally transparent. You distribute your own key. And it is certified.

When a CA issues a public-MC: All a CA does is guarantee procedures, not results. It does not guarantee any of the data fields, except the CA-dependent information: 1. the CA's own name and, 2. the CA's access and key (no relying partner paradox) Note that a CA-provided MC can be one from a series of authentication channels that provide reference on Skywalker. Others could be anonymous ads, word of mouth, etc. Each with its own reliability. Any user can choose how many and what types of different channels he needs, in order to satisfy his cost/risk ratio to answer the single question (in this anonymous case it is just one question): Is "MC-DN" and "Name" linked in a unique way?

31. E-mail certification and example of Skywalker's Meta-Certificates:

Skywalker prepares his own MCC, which provides a public-MC to be sent to a CA (just for archival purposes, no key-signing and no content-responsibility) and also prepares the following private-MC to be sent to anyone that wishes to certify him, both as simple as possible. Projected in text, both will read:

Public-MC:

Name = "Skywalker" ; this is just a name MC-DN= "A3B7669C ..8C" ; the result of the magic recipe

Private-MC:

Category = "anonymous" ; this is an alias certificate Name = "Skywalker" ; this is just a name Reference = "CA Name" ; the name of the CA RefAccess = "CA Server URL" ; how to access the CA E-mail= "skywalker@anywhere.net" public-key= "876AB567...90" ; Skywalker's public key HashOf = "Name + public-key" ; this is our magic hash recipe Validity = 13 Jun 1997 ; this is just for reference purposes MC-OwnSig = "234DC6B.........6A" ; Skywalker's signature of this MC

Note that Skywalker may be a very popular name in that CA and still, Skywalker would be uniquely identified by (Name, MC-DN). If Alice wants to contact him, it is certainly possible for Skywalker to send her a private-MC through an anonymous remailer (projection to e-mail) or through a pager (projection to a pager), or any other possible way, to Alice. Skywalker's private-MC sent to Alice gives the authentication channel, the "CA Name". In this case it is just one, but could be a number of different channels (to effectively eliminate spoofing, man-in-middle, etc.). Alice can then check if the calculations indicated in the private-MC really check with the information provided by the public-MC at the CA. If that is so, then it is the right Skywalker. Even though thousands of Skywalkers may exist. The set (Name,MC-DN) has identified Skywalker. Note that it is considered impossible for anyone to calculate the public-key knowing the MC-DN hash. So, from the MC-DN hash no one can generate the public-key that would produce the right MC-DN, which would allow that person to impersonate the set (Skywalker,MC-DN). This problem is composed with the usual impossible problem of calculating the right private key, knowing the public key. Further, the CA information is of no use to encrypt a message to Skywalker. This means several things. First, Skywalker can control the primary recipients of his public key. Second, Skywalker can have as many different private-MC/public-MC certificate pairs as he wishes, while keeping the same pair of keys -- he just has to change the recipe for the hash, which can be done automatically by a proper MC object. Third, using the first two points, Skywalker could send a different private-MC to each identified (though anonymous, if you wish) person that contacts him, each private-MC with a different MC-OwnSig, so he could guarantee that no one could be using his provided private-MCs without first contacting him (no second hand MCs). Fourth, Skywalker does not have to be registered in any TTP, is not subject to key-escrow and can be identified and contacted in a secure and private way. He can also digitally sign his messages and still remain anonymous. Now, would that be possible with X.509? No, because X.509 needs keys and DNs. Also, other problems arise from CA's policies, liabilities, absence of certificates that can be used with e-mail, with link from keys to hashes (is it SHA-1 or MD5? Does it use the key and name or just the key? How does it combine key and name?).

32. Love the idea of certified anonymous entities (but, by whom, a TTP?)

No, could be by a CA who is not a TTP (for example, a CA in US that is not a TTP in UK), could be by this list (example already discussed today), could be by an anonymous pager message, etc.

33. How does a server, e.g. one belonging to the Ford Motor Co., confirm its true identity i.e. that it really is Ford and not some imposter?

For Domain-Space, by a type of PGP's web-of-trust. It is the only way (see slides). For Image-Space, by several authentication channels which would be evaluated according to Ford's Trust Policy (see slides) and accepted according to the user's risk acceptance. A short list ;-) would be: e-mail responses, smart-cards, key floppy-disks, fixed passwords, one-time passwords, kerberos-type tickets, fax responses, phone calls with automatic or human response, caller-ID verifier, pager passwords, video identification, biometrics, challenge-response, satellite signals, GPS (Global Positioning System) data, radio wave data, etc.

34. How is key recovery possible under this approach?

By defining a command over a data set (an object, if you will) that will store, under your command, your keys in a secure server you choose, encrypted with a key that you scatter using another command (an object, if you will) over a series of media and servers.

35. Skywalker uncloaks his Identity

To change the anonymous Skywalker example of an identified, certified and signed entity, to a simple non-Anon example, edit the Category field in the MCC (the MCC provides both the public-MC and the private-MC) to read: "persona" and add Domain-Space reference(s) instead of the Image-Space reference provided by the CA. Note that I-S references, however multifarious, will add nothing to certification in D-S. (Anon authentication is done always in I-S. Why? Otherwise, it is not Anon any more, according to the definition.) Thus, Alice will be able to check Skywalker through the authentication channel(s) of Domain-Space (at least one) and link (MC-DN,Name,Persona), where the quality of being a Persona was added by the D-S. Before, Skywalker was an "empty" persona, so he was just (MC-DN,Name), with the implied full set (MC-DN,Name,Anonymous). Note that we could also have (MC-DN,Name,Machine), (MC-DN,Name,User), etc. When there is no ambiguity, we can drop the last Identification. (Here, MC-DN, Name, Persona, Machine and User are Identifications, as defined) So, Skywalker is the only Name=Skywalker that has MC-DN. Besides, Skywalker is also certified as a Persona. Still, Skywalker is the only Name=Skywalker that has MC-DN' (MC-DN' <> MC-DN). Besides, Skywalker is certified as anonymous. We could also have Skywalker with MC-DN'' and certified as a Machine. Or, Skywalker as another certified Persona with MC-DN'''. The important point is that the MC-DN is unique. Note that we could not have (x,Name,Anonymous) and (y,Name,Persona) and x = y. We could, however, have (x,a) and (y,b) with x <> y and a = b. The point is that the MC-DNs are supposed to be unique, that's why I used the denomination MC-DN: Meta-Certificate Distinguished Name. (also, so we would not ever call it a key, in TTP's heavens name!) ;-) More complicated examples, with allowed and forbidden tasks, multiple issuers, sequential issuers, remote tasks, delayed tasks, etc. can also be exemplified.

36. The MC-DN is a hash number taken with your public-key. How useful is it? Is it unique? Is it straight-forward to calculate?

Useless: The MC-DN is completely useless (as a DNcomponent). I can calculate this hash from the public key anytime I :want it, whether the public key is part of a PGP public key block or contained inside an X.509 certificate. There's no reason to have it as part of the DN. It buys absolutely nothing. It's fine to index off this hash if you want; this is what PGP public key servers do.

Useful: You're taking this too literally. The hash is taken from various components, not just the key + name. For example, you can add a section of DNA sequence or random noise, and have several CA's hold your hash (and in this case, hash is what you might start with :-)

How to calculate: The MC-DN is a hash (e.g., SHA-1) of your public-key and anything else you desire, in any way you desire. The "recipe" is given in the private MC, together with the public-key itself. The MC-DN itself is given in the public MC.

37. Authentication Channels as exemplified by the interaction between MC-DNs and CAs.

MC-DNs are Useless: In the Skywalker example, How does Bob know that he can trust the information from the CA? This :is the crucial issue w.r.t. CAs. If I were a bad guy impersonating Skywalker, I can advertise myself as Skywalker and provide E and A(and hash{A} if there were any reason to) to the CA. Now, when you ask the CA, you will get *my* info from the CA, you'll ask *me* for :my public-key, and verify that MC-DN is the hash of *my* key. What has all this bought you? Nada.

MC-DNs may come from a special CA: Trust the CA? You mean, the CA? You are kidding? they don't believe even in themselves. No, that was just what those words "based on the CA certificate" meant, for the sake of argument, as an example. Well, the CA may be Skywalker's mom' and then .. well, in that case... I guess you could take an exception. Or the CA may be Skywalker's real persona ... and in that case... oh, well... I guess our hero can trust himself. At last, a trusted CA! (or: if to every law there is an exception, then there must be at least one law without exception -- the exception to this law)

Channels: making it useful: True, but it's going to be hard for the bad guy to get his data into every possible CA *before* Skywalker does. The idea is that the person getting the data from the CA is taking the risk, the CA isn't making any promises. You need multiple CA's to get a low risk assesment.

Channels make it work: The problem with the special CA in the example above is ..... you don't know it is Skywalker's Mom or the Skywalker's CA! How do you it know it is safe? Using MCs, you can set up any desired number of authentication channels that correspond to your risk acceptance level. Besides the obvious fact that CA's cannot authenticate in Domain-Space - so they can never authenticate a person or corporation, a number of CAs can give you a very low risk factor if they are treated as different channels of information.

Channel surveillance: Also, there may some "new" CAs that the bad guy does not know of and some that are not used anymore. The fact that increasing the number of CAs can actually increase your chances of getting a correct answer is easy to see if you follow a simple rule: trip error on one mistake. This means that if you get one wrong answer, you have reason to be suspicious. Also, Skywalker can set up his friend R2D2 to do a "round-robin" visit to all CAs he can reach and verify if there is any false Skywalker walking around.

Channels everywhere: This is very important and I would like to emphasize this point, beginning when the channels are *different*, not just of the same type. Mitm attacks are hard to handle, as well as spoofing, but it is very hard to coordinate these attacks on more than two channels at the same time. The reasoning is like the calculation of error-correcting codes: you add redundancy and you improve reliability. For example, if one channel is Web directly off a cable-modem and the other is a fax, the two use entirely different communication channels that must agree on end results. If now you add an IR link to a next building, and so on, any attack will show up as a marked difference in at least one channel -- which will be easily seen and countermeasures can follow. To calculate, suppose the probability of a succesful spoofing is the same in each of three channels (cable-modem, fax, IR link) and is equal to 1%. Then, if we do a majority vote and take information that is equal in two channels to represent "true" information, the probability that two channels will be spoofed is 0.01%. If we take more channels and do a statistical analysis, we can considerably improve our odds. You can also add other "virtual" channels, by doing time-multiplexing and channel-hopping. In channel hopping, you send the information partially in each channel, in an apparently random way. This has been well-documented in the work with spread-spectrum techniques, which began with high-security military applications in open radiowaves. So, if we take now just two physical channels but multiply them by ten through channel hopping, the probability of a successful attack decreases now to a negligible value. How about just one physical channel? Also possible, because as you sophisticate the hopping algorithm and mix time- with message-hopping (message-hopping is when you mix for example two messages in contiguous time slots) then it is easy to imagine that the probability of spoofing will decrease with the increased complexity. This means that, as a conclusion on this topic-hop, you can have more than one channel even if you use one physical channel. It doesn't have to be slow either, because you can open simultaneous sessions and take care of software overhead just once.

38. More Channels. Bob asks Skywalker for his key and certifies it based on the CA certificate. How to believe this?

Thru the use of multiple channels. Man-in-the-middle is hard with 2 channels and practically impossible with more than 3. With just one channel it _is_ possible to do a spoof, and it's trivial if you happen to own the backbone. If you set up MC-CA's in multiple countries, and send your public key to each one via a different channel, it will be hard for someone to spoof your key. It can be especially difficult for governments to spoof your key if the MC-CA's are set up in places that have governments which don't get along too well. You can verify that the correct key is placed in each CA. After that, it's up to the recipient to get multiple instances of your key from the various CA's. I would think the same basic idea is useful to any key database system.

Comment: This point is very useful. If MC-CAs can be set up in a competing environment (peer service) and you can do a round-robin or statistical checking of all CAs routinely, then it should be easy to spot a false cert. This means that the MC-CAs themselves can do that and offer a type of coherence check. An interesting problem for competing businesses.

39. How can MCs be practically used with CAs?

The basic point here is that you need two flavors of MCs -- simultaneously -- public and private. Let's see the public MCs first. The public MCs can be any number you wish. Each one can have any number of authentication channels. The authentication channels now allow you to calculate risk (a risk analysis. If they can calculate the risk of you bumping your car and get a good number -- good enough so that you think it is a good cost and they think it is a good risk) and I am sure it is easy to follow the yellow brick road here. To be more specific, suppose you have m public MCs and each MC is designated by (MC)sub-m where sub-m is subindex m. Now, each MC will have n number of channels, so I indicate that by (MC)sub-m,sup-n. You can now write (keep it simple!) a weighted-average of each channel (n x m) trustworthiness and arrive at a merit (or risk, if you will) figure. The risk decision is yours. Not at all the picture with X.509's. Now, the private MC. There is just one, at least for each client. The private MC has the computational key (see previousm items) that will allow you to use the public MCs.

40. Can someone steal my private key on-line or in my machine?

The _private_ key should only be one machine, never used on a multiuser machine and never, ever transmitted! That's basic to any secure system. Even better, the private key should be computable from the pass phrase and never even stored on disk or non-volitile ram.

41. TTP questions

For the nth time, TTPs, key-escrow and the like are a political not technical problem, and will not be "solved" by new technical proposals: You are wrong. There are very reasonable (sorry, anarchists) arguments why TTPs and key-escrow are needed today, socially. Please see the Overview paper, especially the "biscotti paradigm". Our point is different. We recognize there is a valid social (public order) need for TTPs and key-escrow in **today's** X.509 and CA mess. That's why we are saying: forget that. Dismiss the central control syndrome. Dismiss the hierarchical model. Use a decentralized archetypal model that will *not* have any need (mind you, neither technical nor social) for TTPs and key-escrow. OK, we prove the social order is not at risk. We avoid the different ins and outs of the proposed legislation. Fine. Your country still wants to big brother you? Well, their case is much thinner. That reminds me of the tea tax in the then American Colony. No cause. A small problem. A large effect.

A TTP (trusted third party) originally meant an uninvolved third party who could be counted on to make objective, unbiased decisions and carry out steps detailed in a contract or other mutual agreement; as an escrow agent in a real estate transaction for example. It is now perverted forever to mean a stool pigeon who turns over ostensibly private information to Big Brother: The name TTP is as misused as well as the names CA or certificate. I alsopropose to call X.509 certificates "doubticates" and CAs "Confusion Abounds" as well as calling CRLs "Confusion Really made its limit Limitless" or, for short, "Confusion Really Limitless", even though some other people may suggest "Credits 'Re Losses".

42. How about a central and trusted government CA to certify keys? It could also certify my CRLs.

Comment 1: MCs do not even have a CA that has central control. Forget about hierarchical control. You get one-by-one certification with inheritance and channels. You can approach 100% user risk acceptance on 100% certified procedures, which X.509, PGP and other methods cannot do.

Comment 2: In Germany, the Individual Network Certification Authority did not accept PGP key for certifying unless they got the key revoke certificate for revoking certificate by revoking the key itself. After patching PGP to follow its own format description, they do not longer need those key revoke certificates, because they are able to submit certificate revokation certificates.

Comment 3: Now, that's a good one and I had a good laugh: certificate revocation certificates. Confusion has now made its masterpiece. If those keys were really revoked, why would they need a CRC? As a kind of epitaph? Or, maybe, the revoked key is actually a phantom that can be rather spooky or, spoofy? May be it lingers in someone's seldom used server and will show up at midnight? The conceptual errors abound. Just to comment on the CRC beasts you mentioned above, the CRLs are a conceptional (yes, I mean conceptional) error just by themselves. Mind you, unsurmountable.

43. Suppose you have got a anonymous certificate allowing you to have access to a special database. What do you have to do if this key pair is lost/stolen/compromised? How can MCs help?

Cut the life-line and recreate a key pair.. The life-line will enforce your threat model. If you think you are under high risk or that the bounty is envyable to some, you could have a lifeline of once per access. Immediate revocation. No MCs will live after the lifeline is cutoff, if that was your security policy because your threat model needs it.

44. MC-DNs are not unique.

The probability that you will find someone else -- during your liftetime and plus 1,000 years -- with the same 20 byte sequence as you, must be several orders of magnitude smaller than a reasonable life insurance risk. Suppose you have 5 billion Internet users on Earth (and nearby planetary bodies if you wish) and that each one is identified by the old fashioned hash key of today (we have just under 80 million users some say). Now, the 20 byte sequence will generate of course more possible keys than the number of atoms in one gram of helium at ambient temperature and pressure, to each and every person. That seems enough to guarantee that I get a unique MC-DN. Also, each person that contacts you can receive their own indivdual copy of your MC, each with a different recipe for the MC-DN. And no one makes you make it public. The principle is: security is constrained by the server and chosen by the client. If I constrain each client to have a unique MC, then each client must use different recipes. In high security applications, you will use this recipe as a type of persistent session key -- that you can easily change by getting a new MC -- that is private to you. Now, even if the recipe is public, one of the data used in the MC-DN could be a nonce, that the private MC sent by Skywalker provides you with. This nonce would be known to you and Skywalker. It could be also a public recipe using a shared secret you and Skywalker agreed by using another channel, with no mitm.

45. Though I think it is fairly clear what you mean by domain space and image space, you have never managed to describe how PGP certifies" in domain space while other systems do not. You can stamp your feet and hold your breath or say it as many times as you like. That does not make it so, and certainly does not *prove* it. : Well said. But maybe, if someone stomps his feet, holds his breath and say it as many times as he wishes -- then you may recognize him as an old friend that did just the same in 3rd grade, is called Skywalker and you will then accept him in your key-ring with his brand-new key! He will be part of your web-of-trust and you will be part of his. So, when one of your friends back from 3rd grade ask for a key to that old pal Skywalker that used to stomp his feet and hold his breath and say it as many times as he wished, you will just immediately pass over to him the new Skywalker's key. And then, one day, you get a message encrypted with your key from someone you never met. In this message, he explains to you that Skywalker is in his key-ring from college and that he just trusts webs-of-trust so much so as to know that you are you. This is PGP-style, no need for IDs (canbe forged), no need for notarized declarations (can be forged, colluded, reused, etc.) and other Image-Space identifiers that would require a leap-of-faith to reach Domain-Space. But if "someone stomps his feet, holds his breath and say it as many times as he wishes" -- then you may recognize him as an old friend, by doing Domain-Space authentication, without any ID.

46. Flames:

Flame 1: The original commentator could have at least taken a long pause. While it is nice and academically interesting to throw words at random and see if they make sense, our objective here is to discuss ideas in a causal way. This is not the place to put a million monkeys typing on a keyboard and see if they come up with something intelligible.

47. Can Certificates be taken by their face value?

Yes: My browser shows me that the certificate presented has a DN whose CN component matches the domain name I tried to connect to (this verifies that [according to the certificate] I got to the actual site I was trying to get to). The browser also shows me that the certificate was signed by Verisign. I know that the CA key used (by Verisign) in signing the certificate is correct because the key was already embedded in my browser when I received it (and we have agreed to assume that the browser was obtained through a reliable channel).

No: You can not assume a build in Root-CA key to be reliable. It might be revoked in the meantime. You have to check this. Furthermore you have to check the certificate of amazon.com seperatly. Netscape Extentions allow this, but VeriSign does not support this feature. (Others do) Furthermore you have to check the Root-CA certificate to be still valid. There is an implementation bug which prevents this to be done automagically.

No: More than 20 strong reasons are given in the Overview Paper. The problems are conceptional, conceptual and implementational.

Authenticode and other problems: You have to read the policy of the CA. What you can do, if you are fraud, is figthing against the company based on the information the CA logged while selling the certificate. The X.509 structure allows you to jail fraudulent behavior. Microsoft does the same with Authenticode. But in this case, VeriSign the only CA got the necessary technical information from Microsoft will revoke the certificate if the certificate holder misuses ActiveX. So VeriSign revoked the binding between the hacking guy and his signed programs and you are lost in law. Such a behavior is required by Microsoft to become an Authenticode CA. So CAs offer trust without security.

You can't enforce sanctions when you rely on forged identities: X.509 cert does not certify people - even though they wish to tell you that, please read their disclaimer at http://www.verisign.com/starnine/legal.html -- and the main reason is clear. You cannot expect naive "one-shot" authentication such as provided by Image-Space identifiers (as many as you want) to certify in Domain-Space. It would require a leap-of-faith and it can easily be forged. The only method today that certifies in Domain-Space is PGP and we have proved that last week on this list using the cafeteria example. Were you in?