Certificate proposal
-----BEGIN PGP SIGNED MESSAGE----- X.509 certificates are not totally bad. Their structure contains lessons for anyone designing a certificate structure. [Raw X.509 does not imply a hierarchy, I believe. Steve Kent & Co. do.] However, there are also some serious problems with X.509 certs, aside from their use of ASN.1. Perhaps the biggest problem is the use of a name -- a text string (or some abortion like the DN which can be reduced to a text string) -- as the anchor point. This anchor point needs to be unique. Since it is just a text string, that means that the certificate authority needs to guarantee uniqueness. However, it is also supposed to stand for a unique individual. Since it is not that individual's DNA sequence -- it is not testable. There has to be machinery set up outside the certificate definition for binding this text string to its individual. ------------------------------ PGP certificates have the same problem. In that case, it is an e-mail address and name (by tradition) as the text string. That needs to be bound to some physical body. If it is an e-mail name, there is some binding enforced by whatever access mechanisms protect access to that e-mail account. However, that binding is weak and also outside the certificate definition. ------------------------------ Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something. Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature). What remains is a need for attributes to be bound to a key. For example, someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair, is balding and wears a pony tail, by signing a message to that effect. Someone else might sign a message stating that the person who owns the private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend money from bank account number 07123 of Provident Savings in Columbia MD. That latter signator needs to be verified as authorized to make such an assertion -- and you end up with a certification chain -- but it is not hierarchical like X.509 and it is not web-of-trust -- it is relational. It is not a chain binding key to person but key's person to attribute or permission. It goes directly to what we need to accomplish without the middleman -- without stopping at a person in the middle. I realize that if you want to revoke a key, then it might help to have bindings be to something other than the key. That way, you can change keys out from under the binding. However, every method I've examined for accomplishing that has security weaknesses. The best method I've found yet has a very long signature key -- used only rarely (e.g., when acquiring an attribute-certificate worth a great deal; and signing more transient keys) -- and never normally revoked (or, if revoked, causing a widespread re-establishment of bindings -- like when you lose your wallet today). ------------------------------ Current certificates are going down a fundamentally wrong path. They are trying to bind keys to people and let Society somehow bind attributes to people -- but the latter binding is too weak to permit keys to be bound to attributes or permissions. The community will discover this, soon, but the farther we play along the X.509 path (especially, but also the PGP path), the more inertia there will be to overcome in trying to fix this problem. I would therefore suggest that the PGP development process address this issue now and continue the established habit of taking the lead into sanity. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHAK8FQXJENzYr45AQFsdAP+JswAq/H4JIDE3+VlMsi87PBPCNBA7jg7 0ftkd8v7vrSSNda5aF+HVB7oKHylA/Lb90bvjMK7CKOJJ7aTzRP9IsAiz1i48FAR LAeD59v5SAKmAhaTMMYSRyKFRRXEaqIdEoJW3XKQBJ57b8R38vWKjR/11eTtCKjV joH4c5hhWmY= =ayYh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- (...WAY behind in cypherpunks mail...) Carl Ellison <cme@TIS.COM> writes:
Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something.
I don't understand this whole discussion. A certificate is a signed binding of a key and a unique name, right? If the proposal here is that the unique name be a hash of the key, you are suggesting a signed binding of a key with its hash! What is the point of a certificate which binds a key to its hash? What is such a certificate asserting? It seems to be saying nothing at all. Anybody can already tell if a hash is right, for all the good that does you. It's like a notarized statement that 2+2=4. I don't see the point. As Carl goes on to say:
Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature).
If in fact this is just a suggestion that we not have certificates, that may have some value. But as a literal suggestion that certificates bind a key hash to a key, that just doesn't make sense to me. The thing to keep in mind is, why do we want certificates? Why not just use unsigned keys? If I encrypt a message for Carl based on some key I found lying around somewhere which someone told me is his, and I send it to his mailbox, and I get a reply back, how secure is that? We all know that you don't get the full security of the encryption if you do this. Man in the middle attacks might not be easy to do in such a situation but they are certainly possible. It is such attacks that certificates (including PGP key signatures) are designed to prevent. I'd like to see some grounding of this discussion in terms of the role of certificates, and ways to prevent man in the middle attacks. I certainly have no love for facist worldwide ID cards and hierarchical, organization based naming schemes, but just using any old key because it seems to work OK most of the time isn't going to fly IMO. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBMHQw5BnMLJtOy9MBAQEDFQIAxvq8EC5zBMvUYGjwMUb2LDy/kt0gP19Z S8BY+fxswuQCIqyet6WqddtVNyBE6QlO7XTTOX5RtZvMLHLN0YVp3A== =Bq7+ -----END PGP SIGNATURE-----
I strongly support what Carl Ellison is saying. I've been meaning to write up something on it for so long that I must accept I'll never do it. So here instead is a quick example.
I don't understand this whole discussion.
The idea is to make the public key the centre of the architecture instead of being an attribute of some other centre (e.g. distinguished name). Consider the IPSEC case. The current situation is: 1. We go through some process, let's call it Process A, where we determine that we want to talk to IP address 192.9.8.7. 2. We go through another process where we obtain the public key of 192.9.8.7. 3. We then try to decide, based on one or more certificates, whether we trust the public key to be the correct public key for 192.9.8.7. Now consider the key-centric version. 1. Process A returns a public key which denotes the destination we want to talk to. 2. We then go through a process to obtain the IP address that belongs to that public key. We probably won't use the public key as an index to get that information. We probably use the information that was input to Process A. In fact this information may fall out as a byproduct of Process A. [However if we needed to make a scalable distributed database of RSA public keys then I have a design to do this - available on application.] 3. We don't need to trust any certificates or anything else at this stage. The fact that the IP address belongs to the Public Key is signed by the Public Key itself. The same thing happens with e-mail. If "Process A" gives us an e-mail address to send to then we worry about whether we have the right public key to go with it. If Process A gives us a Public Key then we can have certainty about the associated e-mail address because the association is signed by the Public Key. And a big win that just falls out of this is that I can have a continuous exchange of information with one IP destination even if it keeps changing its actual IP address (mobile computing) or I can have an e-mail conversation with a person who keeps changing their e-mail address. The things you want just fall out instead of requiring clever software solutions.
A certificate is a signed binding of a key and a unique name, right?
In the key-centric world a certificate binds some attribute as a property of a publc key. So an X.509 certificate would say "The owner of this public key [i.e. person who knows the corresponding private key] owns the following point in the X.500 namespace", rather than that "the person identified by this DN owns the following publc key". Experience has shown that the latter interpretation is a mine-field. It really doesn't work. The idea of a key-centric architecture is the proverbial "idea whose time has come". There are echoes of it in MOSS and in STT. But it really calls out for a group to work out a complete architecture. If someone wants to start such a discussion I'll make sure I make time to be part of the process. Bob Smart
Hal wrote:
The thing to keep in mind is, why do we want certificates? Why not just use unsigned keys? If I encrypt a message for Carl based on some key I found lying around somewhere which someone told me is his, and I send it to his mailbox, and I get a reply back, how secure is that? We all know that you don't get the full security of the encryption if you do this. Man in the middle attacks might not be easy to do in such a situation but they are certainly possible. It is such attacks that certificates (including PGP key signatures) are designed to prevent.
I think Carl's point is that when you write an e-mail to Carl, you probably don't care that it reaches the "real" Carl Ellison, because you don't have a binding between the name "Carl Ellison" and the physical person. A binding between a name and a key is useless if there is no binding between the name and the person. Since this is the case, why not forget about the binding between the name and the key (or turn it into a local one as I suggested in the previous post) and go straight to the binding between the key and the person? On the other hand, if you do have a binding between the name and the person, then most likely you met Carl at some point in the past and he told you his name was Carl Elison. In that case it would have been just as easy for him to give you his public key instead. Wei Dai
Hal wrote:
-----BEGIN PGP SIGNED MESSAGE-----
(...WAY behind in cypherpunks mail...)
Carl Ellison <cme@TIS.COM> writes:
Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something.
I don't understand this whole discussion. A certificate is a signed binding of a key and a unique name, right? If the proposal here is that the unique name be a hash of the key, you are suggesting a signed binding of a key with its hash! What is the point of a certificate which binds a key to its hash? What is such a certificate asserting? It seems to be saying nothing at all. Anybody can already tell if a hash is right, for all the good that does you. It's like a notarized statement that 2+2=4. I don't see the point. As Carl goes on to say:
Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature).
If in fact this is just a suggestion that we not have certificates, that may have some value. But as a literal suggestion that certificates bind a key hash to a key, that just doesn't make sense to me.
The thing to keep in mind is, why do we want certificates? Why not just use unsigned keys? If I encrypt a message for Carl based on some key I found lying around somewhere which someone told me is his, and I send it to his mailbox, and I get a reply back, how secure is that? We all know that you don't get the full security of the encryption if you do this. Man in the middle attacks might not be easy to do in such a situation but they are certainly possible. It is such attacks that certificates (including PGP key signatures) are designed to prevent.
I'd like to see some grounding of this discussion in terms of the role of certificates, and ways to prevent man in the middle attacks. I certainly have no love for facist worldwide ID cards and hierarchical, organization based naming schemes, but just using any old key because it seems to work OK most of the time isn't going to fly IMO.
I think the old idea of a certificate just binding a name and a key is turning out to not be very useful. That is why Netscape Navigator 2.0 will support x509 version 3 certificates. They allow arbitrary attributes to be signed into a certificate. In this new world, you can think of a certificate as a way of binding a key with various arbitrary attributes, one of which may be(but is not required to be) a name. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Jeff Weinstein wrote: | I think the old idea of a certificate just binding a name and | a key is turning out to not be very useful. That is why Netscape | Navigator 2.0 will support x509 version 3 certificates. They allow | arbitrary attributes to be signed into a certificate. In this new | world, you can think of a certificate as a way of binding a key with | various arbitrary attributes, one of which may be(but is not | required to be) a name. I'm a bit behind on the X.509 discussion, but does version 3 resist the attack Ross Anderson mentions in his 'Robustness Principles' paper in Crypto '95? (The paper can be found in ftp.cl.cam.ac.uk:/users/rja14/robustness.ps.Z The wcf.ps.Z is his 'Why Cryptosystems Fail' paper, and both are well worth reading.) Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be?
Um, just a wild guess, but... your credit card number maybe? (Well, okay, its hash.) -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
Tom Weinstein wrote:
In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be?
Um, just a wild guess, but... your credit card number maybe? (Well, okay, its hash.)
The hash of just the card number isn't good enough. If you collected a bunch of certificates (they are public) then you could start guessing valid card numbers and trying to match the hashes with your database. The Mastercard SEPP proposal uses a salted hash, where the salt is a shared secret between the bank and the user. --Jeff
-- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
There are too many Weinsteins hanging out here lately... :-) -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Hal wrote:
Jeff Weinstein <jsw@netscape.com> writes:
I think the old idea of a certificate just binding a name and a key is turning out to not be very useful. That is why Netscape Navigator 2.0 will support x509 version 3 certificates. They allow arbitrary attributes to be signed into a certificate. In this new world, you can think of a certificate as a way of binding a key with various arbitrary attributes, one of which may be(but is not required to be) a name.
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be?
It would be some value that would allow the credit card authorization agency to match it up with the submitted credit card number. In the case of MasterCard's SEPP they are using a salted hash of the Account Number, where the salt value is unique per account, is secret, and is shared between the bank and the card holder. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Hal wrote:
tomw@orac.engr.sgi.com (Tom Weinstein) writes:
In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be?
Um, just a wild guess, but... your credit card number maybe? (Well, okay, its hash.)
I may not have been clear: the certificate I was referring to was the one from Egghead, the one which I will use to make sure that I have a valid key for Egghead. Such a certificate would of course not have my credit card number; it would probably have some information related to Egghead. My rhetorical point was that information would most plausibly be a NAME by which I would refer to Egghead. I am still trying to understand how these proposals to take names out of the picture will apply to a commonplace situation like this one.
I don't think that we need to get rid of names entirely. It all depends on the intended use. In this case it would be reasonable for the certificate to have the name in it. It would also probably be signed by a bank or card association CA, which was set up specificly to sign merchant certificates. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
In article <DG0EzA.Gs5@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
tomw@orac.engr.sgi.com (Tom Weinstein) writes:
Um, just a wild guess, but... your credit card number maybe? (Well, okay, its hash.)
I may not have been clear: the certificate I was referring to was the one from Egghead, the one which I will use to make sure that I have a valid key for Egghead. Such a certificate would of course not have my credit card number; it would probably have some information related to Egghead. My rhetorical point was that information would most plausibly be a NAME by which I would refer to Egghead. I am still trying to understand how these proposals to take names out of the picture will apply to a commonplace situation like this one.
Yes, it seems I misunderstood you. There would have to be some binding between the key of the merchant and some identifying information that would allow the user to verify the merchant's identity. This could take the form of a True Name for the merchant and a trusted CA. Another approach would take the form of an FQDN, an IP address and a trusted CA. In this case the software would have to verify that the FQDN and IP address match the URL and DNS lookup, respectively. Unfortunately, this also requires that any time the IP address changes that the merchant get a new certificate. Also, the CA must be checked to verify that the certificate hasn't been revoked, or you run the risk of an attacker getting the old IP address. Does anyone see any other options? -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
Jeff Weinstein <jsw@netscape.com> writes:
I think the old idea of a certificate just binding a name and a key is turning out to not be very useful. That is why Netscape Navigator 2.0 will support x509 version 3 certificates. They allow arbitrary attributes to be signed into a certificate. In this new world, you can think of a certificate as a way of binding a key with various arbitrary attributes, one of which may be(but is not required to be) a name.
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be? Hal
-----BEGIN PGP SIGNED MESSAGE-----
From: Raph Levien <raph@CS.Berkeley.EDU> Date: Mon, 02 Oct 1995 10:13:08 -0700
I am extremely glad to hear Carl propose this. Let me propose something just a bit more concrete (Carl might not like it because it contains just a hint of ASN.1, but what the hell).
I'll hold my nose while reading :-).
I propose that the unique name be the MD5 hash of the MOSS public key, as formatted according to the MOSS specification (ASCII and all). PGP keys can easily be converted into MOSS ones, so it's pretty easy. The hash should be expressed as 32 hex digits, so that it can easily be typed in or spoken. The only ambiguity in this proposal is where to put the newlines, if any. For concreteness, I propose that there be no newlines in the public key value.
I see no problem using a hash. I might use SHA rather than MD5. MD5 is a wee bit too short. But, for what we're doing, MD5 is just fine -- and as a hash of a public key, the cost of finding alternatives is high enough that MD5's shortness probably isn't a problem. However, why convert PGP keys to MOSS and then hash? Hash the PGP key straight. You're right that my proposal was not concrete at all. To make it concrete, you'd want to specify the signed message which takes the place of a certificate. I tried this once before, roughly, but I never gave it the effort it deserves. Let me call this non-certificate a blurk (waiting for a real name). ------------------------------ For example, you need to identify: the signee (a public key or hash of a key) the public key needs to be identified as to type (RSA, D-H, DSA, ...) and the package using it can also be identified (e.g., PGP, MOSS, ...) the signer (a public key or hash of a key -- as used in the blurk which grants authority to the signer) a text string (or paragraph) giving the attribute being attested to -- and possibly giving validity dates, etc. the signature (in some algorithm) [You might want to allow for multiple signatures in different algorithms and/or different packages -- to keep the signee from having to send out dozens of blurks or storing dozens in a database.] ------------------------------ The entire thing could be a signed cleartext message: signer's key; [signee's key; text] signature (of []) Alternatively, you could modify the PGP UserID field (or make something very similar) with raw text (not treated as an ID on the key) and a sig on the text and signed key. Signing a cleartext message has some appeal. As for how this would be used -- my guess from looking at X.509 is that it's meant for machine parsing and understanding (although I know of no programs which follow them beyond sig checking). A cleartext signed message requires human reading and filing. However, that's fine. After all, it is a human who decides whether to act or not. If there is a computer deciding whether to act based on the blurk, the signed text could include SMTP-style tagged text lines for the program to go find. Looking forward to more concrete elaborations.... - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHBgrVQXJENzYr45AQG7wgP+MzX/uQsIw5G4YjaRFzPFGV1z6MV5RV5g xvH6/wv6XLyeZ3DTn/akiwiFO5nl8aSUEq5F7huMByiYctXjlI/05l5KFUxpjNY5 QpQH8hRAIO8PnrItyK0Fg3uFbDzfloSuhhCoJIFlrkAxEXj1CoMKWkN6hlEz1jmy fY2ceAz6KPo= =Jdrm -----END PGP SIGNATURE-----
tomw@orac.engr.sgi.com (Tom Weinstein) writes:
In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
OK, so suppose I want to send my credit card number to Egghead Software. I get one of these new-fangled certificates from somebody, in which VeriSign has certified that key 0x12345678 has hash 0x54321. I think we can agree that by itself this is not useful. So, it will also bind in some attribute. What will that attribute be?
Um, just a wild guess, but... your credit card number maybe? (Well, okay, its hash.)
I may not have been clear: the certificate I was referring to was the one from Egghead, the one which I will use to make sure that I have a valid key for Egghead. Such a certificate would of course not have my credit card number; it would probably have some information related to Egghead. My rhetorical point was that information would most plausibly be a NAME by which I would refer to Egghead. I am still trying to understand how these proposals to take names out of the picture will apply to a commonplace situation like this one. Hal
-----BEGIN PGP SIGNED MESSAGE----- Hello Hal <hfinney@shell.portal.com> and cypherpunks@toad.com Hal writes:
In article <DG06FE.IA8@sgi.sgi.com>, Hal <hfinney@shell.portal.com> writes:
OK, so suppose I want to send my credit card number to Egghead Software. ... [previous reply elided]
What you are missing is that you should not say "I want to send my credit card number to Egghead Software" you should say "I want to send my credit card number to 12 34 56 78 9A BC DE F0"
I may not have been clear: the certificate I was referring to was the one from Egghead, the one which I will use to make sure that I have a valid key for Egghead. Such a certificate would of course not have my credit card number; it would probably have some information related to Egghead.
The certificates you'd want are: * informal correspondence from your friends that 12 34 56 78 9A BC DE F0 makes good widgets/gadgets/whatzits. * a Consumers Association report saying that 12 34 56 78 9A BC DE F0's widgets don't have sharp edges like 13 25 36 47 58 69 7A 8B's do and that 43 65 87 09 41 61 BA ED's are less efficient (eg "Choice" magazine). * possibly a certificate from the bank that 12 34 56 78 9A BC DE F0 is a merchant (if using traditional CCs). * or a certificate from a guarantor company saying that if 12 34 56 78 9A BC DE F0 doesn't deliver they'll return your money.
My rhetorical point was that information would most plausibly be a NAME by which I would refer to Egghead. I am still trying to understand how these proposals to take names out of the picture will apply to a commonplace situation like this one.
Yeah, I just can't imagine myself at a party introducing myself "Hi, I'm 08 04 26 6D 01 CD AB 8A 25 A9 E2 86 AD 13 C1 BA". Then again I never was good at parties... To start a new sub-thread: what if the man in the middle is actually a behaviour-modifying parasite? At that stage even a physical meeting won't do you much good (the parasite may be otherwise asymptomatic). It's probably more likely than having 30 FBI agents assigned to your case... Hope I'm making sense... (well, they say that hope dies last, no?) Jiri - -- If you want an answer, please mail to <jirib@cs.monash.edu.au>. On sweeney, I may delete without reading! PGP 463A14D5 (but it's at home so it'll take a day or two) PGP EF0607F9 (but it's at uni so don't rely on it too much) -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMHxzWSxV6mvvBgf5AQHXawP/Xls4gWUwhTFoX9w4TYaKvqbK8MF+dxgS JPmIWdfiEijbRb/qOLzU+7NJqZ3OqcR+Ylc8uBcQPhYJgOwDSta1BYm0OrYhb+PY 6ILXeulp/2T5Y061KrbkFgJ3Z5AcsFTCBad2pHQeIzdlIixv2JPT+qbb5iEkDkgA ebEioYxWgP0= =pFkN -----END PGP SIGNATURE-----
Jiri "Super Trouper" Baum writes:
To start a new sub-thread: what if the man in the middle is actually a behaviour-modifying parasite? At that stage even a physical meeting won't do you much good (the parasite may be otherwise asymptomatic).
Descartes figured there was a benevolent God to bail him out. I believe otherwise. But I manage to go about my business even while wallowing in a state of Futplexian doubt. -Futplex <futplex@pseudonym.com>
participants (10)
-
Adam Shostack -
Bob Smart -
Carl Ellison -
futplex＠pseudonym.com -
Hal -
Jeff Weinstein -
Jiri Baum -
Raph Levien -
tomw＠orac.engr.sgi.com -
Wei Dai