Re: Florida Supreme Court freezes certification
[EMAIL PROTECTED] wrote: #Except that the legal motion was filed by the Reps, not the Dems, #originally. They brought it on them-damn-selves. Idiots. No one asked the Florida Supreme Court to freeze the certification. My current opinion is that they should take the .2% error rate optical machines from the other counties and do another vote in the chad counties. The will of the people deserves a lower error rate, when the presidency hangs in the balance. I'd say that even if the politics were reversed.
Re: Aces high (long reply)
Mr. May: At 5:31 PM -0500 11/17/00, David Honig wrote: At 03:05 PM 11/17/00 -0500, Tim May wrote: years, many decades, to publish learned articles on chads, pregnant chads, And despite all the talk, chad pregnancy is still a problem in America today. You know all those chads are just going to end up on welfare. They burn real well. Just feed them into the incinerators. Pulpist!!! -- A quote from Petro's Archives: ** "Despite almost every experience I've ever had with federal authority, I keep imagining its competence." John Perry Barlow
RE: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000)
there are issues about authentication ... like conceptual frame-works of something you have, something you know, and something you are. it is possible to put together digital signature authentication technology/frame-works involving digital signature that are dependent on one or more pieces of 3-factor authentication. legal "signatures" as indication of intent have involved issues like counterfeit and understanding (and various regulations about font-sizes, wording, different expectations about prudent person, etc). a digital signature, once executed is a lot harder to counterfeit (compared to various written signatures) ... however there is much less direct correlation between intention and the act of executing a digital signature. digital signature in conjunction with various process that can proove that every digital signature executed was directly dependant on various combinations of 3-factor authentication (for each and every digital signature executed) attempts for a tighter correlation and demonstrate some degree of actual binding (between intention and signature execution). however, they also introduce new technology challenges ... there is now a significantly wider gap between the presentation of the information that a person may be agreeing to ... and the actual representation that is involved in executing digital signatures. paper documents also have had the advantage that the presentation of the information and the signature application is nearly identical technology much closer binding between the representation of what is being agreed to and the method of indicating that agreement. There are not a whole lot of cases where as the person is using a pen to sign a specific piece of paper ... that the pen can wonder off and sign a totally different piece of paper (like radar getting week-end passes signed in the MASH show). So the understanding issue pretty much stays the same in both environments (digital signature and paper signature) ... digital signatures (in conjunction with the appropriate authentication framework) can reduce the instances of counterfeit signatures being applied to documents ... but also opens up the instances where what a person is presented isn't necessarily what the person is signing. So one issue might be ... all other factors being equal ... is the magnitude of any counterfeit reduction significantly greater than the increase in the "what you see is what you sign" problem and the "did the person actually intend/confirm that particular signature" problem. "Paul Kierstead" [EMAIL PROTECTED] on 11/17/2000 06:09:02 AM Please respond to [EMAIL PROTECTED] To: "'Digital Bearer Settlement List'" [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: RE: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000) The Word example actually has other worrying problems not mentioned. A Word document contains a lot of hidden information, including other versions. It would be quite easy to sign a Word document that, when you viewed it, looks significantly different then it could be displayed without violating the signature. This is due to numerous problems, the most basic of which is that we often don't sign what we view but instead some binary that we _believe_ represents what we viewed but often does not. This is not just theoretical nor esoteric, but quite easy as the Word example shows. In effect we have absolutely no idea what we are signing most of the time even without comprimise of keys, programs and all that good stuff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of R. A. Hettinga Sent: Wednesday, November 15, 2000 10:51 PM To: [EMAIL PROTECTED]; Digital Bearer Settlement List; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000) At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote: Why Digital Signatures Are Not Signatures
Re: Bob's Bank. Hi, I'm Bob. Just slip it in this pocket here.
-- At 9:07 AM -0800 11/17/00, Marshall Clow wrote: 900 people -- $186M. That's $206K each. That's a lot of money to put into a 'bank'. Tim May: And a lot of money for "Christian Patriots." Not to belittle either Christians or Patriots, but folks like this typically have problems making the monthly payments on their double-wides. You have been reading too many commie/liberal/anti-gun rants. You are pretty similar in income and intellectual attainment to a great many people in the patriot movement. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 60/07D6jrqXCHQGb8lk3fFJwRERdNolY8aRjsmYR 4ey9x3MMMjUOYGqxtsKKKipXSDVjRFMwG06jKTd+e
Re: Public Key Infrastructure: An Artifact...
Bram Cohen wrote: On Sat, 18 Nov 2000, Ben Laurie wrote: [EMAIL PROTECTED] wrote: In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol. As opposed to the spurious revenue stream for Verisign? Like I said: how does that help? Moving spurious revenue streams around gets us nowhere. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Jim Bell Arrested
A family member says Jim Bell was arrested last night when he went out to the store. The person also said the feds were searching for e-mail Jim sent around August 18. I can't prove the family member is that and not a fisher.
Re: ssz.com network trouble
I did a traceroute (well, mswindoze tracert, anyway), and got a "destination unreachable" from a machine at realtime.net in Austin. SSZ has often been unreliable; I think it's connected by ISDN, and it's raining down in Texas. At 06:30 PM 11/18/00 -0600, Neil Johnson wrote: Is there something wrong with ssz.com. I haven't gotten any list mail and I can get to the site. Thanks. Neil M. Johnson [EMAIL PROTECTED] http://www.interl.net/~njohnson PGP Key Finger Print: 93C0 793F B66E A0C7 CEEA 3E92 6B99 2DCC Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Public Key Infrastructure: An Artifact...
Bram Cohen [EMAIL PROTECTED] writes: Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Are you sure that works? I would think the SSL client would do a connection to the URL the user typed, www.amazon.com, and check the name in the cert to see if it (approximately) matches. If some DNS redirection is done in the background so that amazon.com gets mapped to amazon.hackeddomain.com, the client will not be aware of this (will it?) and so it will still throw up a warning when it sees a cert for hackeddomain.com on a connection to amazon.com. Ob
Re: Public Key Infrastructure: An Artifact...
Bram Cohen [EMAIL PROTECTED] writes: Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Are you sure that works? I would think the SSL client would do a connection to the URL the user typed, www.amazon.com, and check the name in the cert to see if it (approximately) matches. If some DNS redirection is done in the background so that amazon.com gets mapped to amazon.hackeddomain.com, the client will not be aware of this (will it?) and so it will still throw up a warning when it sees a cert for hackeddomain.com on a connection to amazon.com. Ob
Re: ssz.com network trouble
I subscribed to cyberpass.net and am still not getting any messages. Is this related to ssz ? -Neil Neil M. Johnson [EMAIL PROTECTED] http://www.interl.net/~njohnson PGP Key Finger Print: 93C0 793F B66E A0C7 CEEA 3E92 6B99 2DCC - Original Message - From: "Bill Stewart" [EMAIL PROTECTED] To: "Neil Johnson" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, November 18, 2000 7:03 PM Subject: Re: ssz.com network trouble I did a traceroute (well, mswindoze tracert, anyway), and got a "destination unreachable" from a machine at realtime.net in Austin. SSZ has often been unreliable; I think it's connected by ISDN, and it's raining down in Texas. At 06:30 PM 11/18/00 -0600, Neil Johnson wrote: Is there something wrong with ssz.com. I haven't gotten any list mail and I can get to the site. Thanks. Neil M. Johnson [EMAIL PROTECTED] http://www.interl.net/~njohnson PGP Key Finger Print: 93C0 793F B66E A0C7 CEEA 3E92 6B99 2DCC Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Initiative - key to Become Successful Home Worker! -AYXK
Don't delay, don't lose Your Chance! Use Your FREEDOM of Choice! Get Clear Home Work! Start Perfect Own Internet Home Business! Make FREE money as partner! Boost your Internet Connection Speed! Speed up your computer! Go to: http://www.virtue.nu/garry/ http://www.geocities.com/garryusar/ * Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply with the word REMOVE in the subject line.
Drop the recounts
The recounts will take weeks? Fugeddaboutit. Go for a revote request using the 0.2% error rate machines. Get the revote: Gore wins by thousands. Don't get it: Gore viable next election cycle, Bush out. It took 36 re-votes to elect Thomas Jefferson. [Democratic spin]
Re: Schneier: Why Digital Signatures are not Signatures (was Re:CRYPTO-GRAM, November 15, 2000)
[EMAIL PROTECTED] wrote: there are issues about authentication ... like conceptual frame-works of something you have, something you know, and something you are. No, no! Don't go there! I am fond of the things that I am and do not want to encourage people to steal bits of me. Two ways is enough for me, unless you can think of a third way that means I get to keep my fingers and eyes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Public Key Infrastructure: An Artifact...
On Sat, 18 Nov 2000, Ben Laurie wrote: Bram Cohen wrote: And if you build a protocol which is a pain to use, noone will use it. What, like SSL, for example? SSL is not a pain to use, and it isn't effective against man in the middle attacks, since an attacker could simply make the end user connection be done via unencrypted http and most end users wouldn't notice. It is, however, quite effective against passive attacks, which is all that's really important. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
note also that current SSL infrastructure is vulnerable to things like domain name hijacking; aka, at least part of SSL protocol is to make sure that you really are talking to the host that you think you are talking to ... i.e. the SSL certificate contains host/domain name (all this, in theory because of weaknesses in the domain name infrastructure) ... and when SSL goes to check something in the certificate ... it is checking the hostname/domainname against the hostname/domain name that the browser is using. However, SSL-certificate issuing CAs have to rely on the domain name authoritative infrastructure with regard to issuing SSL-certificates domain name ownership issues ... this is the same authoratative infrastructure that supposedly can't be relied on and justifies having a the whole SSL-certificate infrastructure to begin with. In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. Now, if domain name infrastructure is going to use public key registration as part of beefing up its integrity ... that would medicate much of the justification for the SSL-certicate infrastructure. Furthermore, if a higher integrity domain name infrastructure included public keys in the domain name record ... clients could request a real-time, trusted copy of the public key as a adjunct to host-name lookup. This would further eliminate the requirement for any certificate involvement in the majority of the existing SSL transaction operation (i.e. client gets the public key at the same time hostname resolution is done ... the client can trust a real-time host/domain name because of the improvement in the domain name infrastructure integrity ... and at the same time it can trust a real-time publickey for the same host/domain). Bram Cohen [EMAIL PROTECTED] on 11/18/2000 11:15:38 AM To: Ben Laurie [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Public Key Infrastructure: An Artifact... On Sat, 18 Nov 2000, Ben Laurie wrote: Bram Cohen wrote: And if you build a protocol which is a pain to use, noone will use it. What, like SSL, for example? SSL is not a pain to use, and it isn't effective against man in the middle attacks, since an attacker could simply make the end user connection be done via unencrypted http and most end users wouldn't notice. It is, however, quite effective against passive attacks, which is all that's really important. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote: note also that current SSL infrastructure is vulnerable to things like domain name hijacking; aka, at least part of SSL protocol is to make sure that you really are talking to the host that you think you are talking to ... i.e. the SSL certificate contains host/domain name (all this, in theory because of weaknesses in the domain name infrastructure) ... and when SSL goes to check something in the certificate ... it is checking the hostname/domainname against the hostname/domain name that the browser is using. However, SSL-certificate issuing CAs have to rely on the domain name authoritative infrastructure with regard to issuing SSL-certificates domain name ownership issues ... this is the same authoratative infrastructure that supposedly can't be relied on and justifies having a the whole SSL-certificate infrastructure to begin with. To be fair, this sort of attack is much more involved and must be planned much farther in advance. In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. Now, if domain name infrastructure is going to use public key registration as part of beefing up its integrity ... that would medicate much of the justification for the SSL-certicate infrastructure. This would remove one of the more serious barriers to running an SSL site - the Verisign protection money. The problem with all of these things is that they are still based on creating an association between a domain name and a key, when in fact what you want is an association between some abstract concept of a counterparty which exists in an end user's mind (like, say, amazon) and the ownership of a machine that user's browser is talking to. Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
[EMAIL PROTECTED] wrote: note also that current SSL infrastructure is vulnerable to things like domain name hijacking; aka, at least part of SSL protocol is to make sure that you really are talking to the host that you think you are talking to ... i.e. the SSL certificate contains host/domain name (all this, in theory because of weaknesses in the domain name infrastructure) ... and when SSL goes to check something in the certificate ... it is checking the hostname/domainname against the hostname/domain name that the browser is using. However, SSL-certificate issuing CAs have to rely on the domain name authoritative infrastructure with regard to issuing SSL-certificates domain name ownership issues ... this is the same authoratative infrastructure that supposedly can't be relied on and justifies having a the whole SSL-certificate infrastructure to begin with. In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol. Now, if domain name infrastructure is going to use public key registration as part of beefing up its integrity ... that would medicate much of the justification for the SSL-certicate infrastructure. Medicate? What? Furthermore, if a higher integrity domain name infrastructure included public keys in the domain name record ... clients could request a real-time, trusted copy of the public key as a adjunct to host-name lookup. This would further eliminate the requirement for any certificate involvement in the majority of the existing SSL transaction operation (i.e. client gets the public key at the same time hostname resolution is done ... the client can trust a real-time host/domain name because of the improvement in the domain name infrastructure integrity ... and at the same time it can trust a real-time publickey for the same host/domain). And the benefit of that (apart from lock-in) would be what? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Public Key Infrastructure: An Artifact...
Bram Cohen wrote: On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote: note also that current SSL infrastructure is vulnerable to things like domain name hijacking; aka, at least part of SSL protocol is to make sure that you really are talking to the host that you think you are talking to ... i.e. the SSL certificate contains host/domain name (all this, in theory because of weaknesses in the domain name infrastructure) ... and when SSL goes to check something in the certificate ... it is checking the hostname/domainname against the hostname/domain name that the browser is using. However, SSL-certificate issuing CAs have to rely on the domain name authoritative infrastructure with regard to issuing SSL-certificates domain name ownership issues ... this is the same authoratative infrastructure that supposedly can't be relied on and justifies having a the whole SSL-certificate infrastructure to begin with. To be fair, this sort of attack is much more involved and must be planned much farther in advance. In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. Now, if domain name infrastructure is going to use public key registration as part of beefing up its integrity ... that would medicate much of the justification for the SSL-certicate infrastructure. This would remove one of the more serious barriers to running an SSL site - the Verisign protection money. The problem with all of these things is that they are still based on creating an association between a domain name and a key, when in fact what you want is an association between some abstract concept of a counterparty which exists in an end user's mind (like, say, amazon) and the ownership of a machine that user's browser is talking to. Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Yes, and Mallory can't read the data - so what was the point? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Public Key Infrastructure: An Artifact...
On Sat, 18 Nov 2000, Ben Laurie wrote: Bram Cohen wrote: Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Yes, and Mallory can't read the data - so what was the point? Yes he can - he's presenting the key for hackeddomain.com, which he stole, so he's quite capable of reading requests sent for it. -Bram Cohen
Re: Public Key Infrastructure: An Artifact...
Bram Cohen wrote: On Sat, 18 Nov 2000, Ben Laurie wrote: Bram Cohen wrote: Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Yes, and Mallory can't read the data - so what was the point? Yes he can - he's presenting the key for hackeddomain.com, which he stole, so he's quite capable of reading requests sent for it. Apologies, yes, you are correct, I misunderstood. But isn't this what Lynn was suggesting in the first place? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Public Key Infrastructure: An Artifact...
The problem with all of these things is that they are still based on creating an association between a domain name and a key, when in fact what you want is an association between some abstract concept of a counterparty which exists in an end user's mind (like, say, amazon) and the ownership of a machine that user's browser is talking to. Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. -Bram Cohen I don't understand this last paragraph at all. If you put a proxy on amazon.hackeddomain.com and I connect through the proxy to the real amazon.com, where is the threat? If the SSL connection is established with the proxy, then the X.509 certificate on that host does not match www.amazon.com and the connection would not verify. If the connection is proxied to the real www.amazon.com the SSL connection will verify, and because it is protected end to end the proxy will not be able to do anything other than disconnect the connection at an arbitrary time. There is no man in the middle attack here. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * [EMAIL PROTECTED]
Re: Public Key Infrastructure: An Artifact...
On Sat, 18 Nov 2000, Ben Laurie wrote: Bram Cohen wrote: Unless that problem is fixed, man in the middle is hardly made more difficult - for example, Mallory could break into some random machine on the net and steal it's public key, then hijack local DNS and when someone goes to amazon.com redirect them to amazon.hackeddomain.com, and then proxy to amazon.com - now even SSL says the connection is safe. Yes, and Mallory can't read the data - so what was the point? Yes he can - he's presenting the key for hackeddomain.com, which he stole, so he's quite capable of reading requests sent for it. No he can't. What hackeddomain.com is sending is the certificate for hackeddomain.com which does not contain the host name www.amazon.com. Therefore, it won't be accepted by the client. If hackeddomain.com acts as a proxy, then the certificate that is received by the client is the real one from www.amazon.com and so the session is protected. You can't have it both ways. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * [EMAIL PROTECTED]
