Re: [isdf] RE: Palladium (TCP/MS)
No. You can trace back to the fact that the signed data was at the same ^ a hash of place as the private key, at the same time. I've seen people *who operate CAs* lose sight of the fact that it's the hash that's signed, not the full data. OK, if you want to be pedantic. ;) However, let's remember that although a hash collision is *possible* to generate, ... My point was not about hash collisions, but rather that the dongle that holds the key often has no idea at all about the meaning of what was signed. And if it's an intruder who caused the signing, there may be no record of the cleartext. If it was a certificate, you can't revoke it because you don't know its serial number or anything else[*] about it. Matt [*] Well, if NameConstraints were implemented you could put a bound on the Subject. That's not much comfort.
Re: [isdf] RE: Palladium (TCP/MS)
On Sat, 2002-10-26 at 03:26, [EMAIL PROTECTED] wrote: On Fri, 25 Oct 2002 13:17:29 +1200, Franck Martin said: Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an This is, of course, assuming you are willing or able to use an exchange server. Not all the world uses the same proprietary package (which happens to be what originally STARTED this thread). I was answering a specific point about outlook web mail, to help one user. We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... You might want to stop, take a deep breath, and ask yourself exactly what problems a global PKI will solve (you might want to go read the chapter on PKI in Schneier's Secrets and Lies if you haven't already). Now let's see: You may want to think about SPAM. Certificates for web access and protocols is well defined and working. I agree with you about all the cert usage possibilities. They are all valid. I will check the refrence you gave, but I have also read Peter Gutmann tutorial on security. I think the only question of a PKI in our case, is to initiate communication between two people who never met. If you have to do an handsake before the message is sent, I think it is overkill and may not work, however tmda.sourceforge.net proposes exactly that. The question of a global PKI is to remove anonymity. You can trace back to a real person (legal person) from the certificate. Who can offer that? What has to be done? This is my question... I don't beleive (personnal view) that the web of trust is fully good. This is interesting and I'm curious about it but someone can proxy someone, etc.. so that When I'm trying to know who I'm dealing with I'm lost in a web of front companies to name an analogy. If signed e-mails become standard, I may decide to accept only signed e-mail, because I will be able to know who it is, and take action... Think about SPAM and viruses that impersonate other people... The other application would be with IPsec, to initiate an IPSEC channel between 2 computers that do not know each other.. At USD300 a certificate per year, IPSEC will made a few VERY rich... May I put an analogy between the evolution of software cost to the evolution of IP protocols cost: From Free to low cost (https) to major cost (IPsec, e-mail) and unavoidable. This is not an easy subject I realise that...
Re: [isdf] RE: Palladium (TCP/MS)
On Sat, 26 Oct 2002 09:38:50 +1200, Franck Martin said: The question of a global PKI is to remove anonymity. You can trace back to a real person (legal person) from the certificate. Who can offer No. You can trace back to the fact that the signed data was at the same place as the private key, at the same time. It most certainly does *not* prove that a given person intentionally signed it. I want you to think about how many people have had things mailed out because they've gotten an email-based worm - and then think about the fact that the FBI *seriously* considered something called Green Lantern. Then think about how lax security has to be on the average to have Green Lantern actually work. The designers of Curious Yellow (http://blanu.net/curious_yellow.html) have some thoughts regarding worms and PKI, which you might want to read - and consider that said worms do nothing that an attacker can't do on a one-off basis. I'll bet there's at least a dozen different ways to code a malicious webpage that contains Javascript that will download a file, sign it on the victim's PC, and upload it back to the server. No, I don't know of any, but anybody who watches Bugtraq probably goes *yawn* at the discovery of *another* browser hole or cross-site scripting exploit (and note that the latter can possibly be abused as well...) An amazing number of people never even notice they're mailing out tons of attachments. But let's assume the user actually notices, and realizes their key may be compromised (and the average user will *NOT* correlate worm with compromised key) You get lots of bonus points for designing a PKI that's able to issue a new key and a CRL for the old one every time somebody gets bit by Klez or *any other* worm that mails out attachments - unless you can *prove* the attachment wasn't your key, you need a new one. The 4 Mirapoints on our mail hub are fast closing in on *5 million* trapped viruses. And we're one relatively small site, with only 60K mailboxes. Extrapolate to 600 million mail users. That makes for massive churn on the CRL... There's a subtle difference between the average PKI and credit cards too - if I *lose* my credit card, it's easy to cancel - but a lot of fraud doesn't surface till I get my bill weeks later. That's OK, because I can protest the fraudulent transactions and agree to pay the legitimate part of the bill. The average PKI has a hard time dealing with this sort of thing - even if it's able to deal with we got hacked 3 weeks ago and just found out, there's very fundemental issues with what to do with the 95% of transactions since then. Any sane PKI scheme will insist that everything in the last 3 weeks be invalid and needs to be redone. Good luck doing THAT, especially if the goods and money have already been exchanged in the 95% good transactions that? What has to be done? This is my question... First off, you need a PKI that *guarantees* that this never happens: http://www.cert.org/advisories/CA-2001-04.html Then you need to consider that we're averaging a CERT advisory *A WEEK* so far this century. Right now, saying it has a digital signature, therefor the person signed it is like saying we didn't see the driver, but because this pickup truck hit somebody, the owner did the hit and run when the defense has a dozen witnesses that will testify that the defendant habitually left the keys in the ignition -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09197/pgp0.pgp Description: PGP signature
Re: [isdf] RE: Palladium (TCP/MS)
On Mon, 28 Oct 2002 12:35:52 CST, Matt Crawford said: The question of a global PKI is to remove anonymity. You can trace back to a real person (legal person) from the certificate. Who can offer No. You can trace back to the fact that the signed data was at the same ^ a hash of place as the private key, at the same time. It most certainly does *not* prove that a given person intentionally signed it. I've seen people *who operate CAs* lose sight of the fact that it's the hash that's signed, not the full data. OK, if you want to be pedantic. ;) However, let's remember that although a hash collision is *possible* to generate, you'd need on the order of 50K-100K Pentium-4 class boxes for a *year* to generate *one* hash collision(*). Well within the capacities of distributed.net, but hardly the method of attack I'd choose when there's a plethora of easier ways. If things ever actually get secure enough that the distinction between signing the data and a hash thereof actually matters for a real-world threat model, I'll declare victory and retire. ;) /Valdis (*) That's for just a collision. You want a collision where both hashed items make sense as data, that will cost extra. A *lot* extra... msg09199/pgp0.pgp Description: PGP signature
RE: [isdf] RE: Palladium (TCP/MS)
Title: RE: [isdf] RE: Palladium (TCP/MS) I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]]Sent: Friday, 25 October 2002 12:27 To: 'Franck Martin '; ''Gary Lawrence Murphy' 'Cc: ''TOMSON ERIC' '; ''[EMAIL PROTECTED]' '; ''[EMAIL PROTECTED]' 'Subject: RE: [isdf] RE: Palladium (TCP/MS) MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
RE: [isdf] RE: Palladium (TCP/MS)
Title: Message As this thread is becoming more and more technical, may I suggest to limit it from now on to the IETF list and then to stop cc:ing the ISDF list... -Original Message-From: Franck Martin [mailto:[EMAIL PROTECTED]] I agree with you, I found many more applications that do not support s/mime cf SSL-Certificates HOWTO on www.tldp.org. However, you can sign messages in s/mime clear text, which works the same as PGP by encapsulating the message in clear inside a signature... but some systems will still not be able to handle properly this mime signature... Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an option that says clients support s/mime. If it is enabled, the s/mime message is send as it to the client, if it is not enabled then the signature is removed (but the user does not know he has received a signed message). s/mime still need more work, on the implementation level... We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... Cheers. Original Message-From: Cirillo CWO2 Michael R [mailto:[EMAIL PROTECTED]] MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't "know" S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period.
Re: [isdf] RE: Palladium (TCP/MS)
F == Franck Martin [EMAIL PROTECTED] writes: F ...Anyone who sends me e-mail can be identified. Anything I F send can be traced to me. People wouldn't be forced to F participate, but if they remain anonymous, I might choose to F block them. I certainly wouldn't accept file attachments from F them. I know you hate this idea, but I think the Internet needs F a fingerprint. Isn't that PGP? -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
Re: [isdf] RE: Palladium (TCP/MS)
On Fri, 25 Oct 2002 13:17:29 +1200, Franck Martin said: Note that you can set your exchange server to convert s/mime messages automatically... On my exchange 5.5 in the Internet connector there is an This is, of course, assuming you are willing or able to use an exchange server. Not all the world uses the same proprietary package (which happens to be what originally STARTED this thread). We are in chicken-egg situation, that will be solved with a global PKI (my opinion)... You might want to stop, take a deep breath, and ask yourself exactly what problems a global PKI will solve (you might want to go read the chapter on PKI in Schneier's Secrets and Lies if you haven't already). Now let's see: If it's within my organization, a cert signed by my local CA is fine. I trust the guys upstairs from me to sign my organization's user's certs more than I trust some top-level CA to sign a certificate-signing-cert for some group I've never heard of. If it's an organization that we've got ongoing business with, it's easy enough to exchange certs and cross-sign them (a la PGP). Now we get to the hard case - initiating contact with a group I've never been in contact with before. Now, if all you care about is establishing an encrypted tunnel, a self-signed cert works *just fine*. So there's only two cases to worry about here: 1) A PKI *does* allow you to (somewhat) verify that the server at the other end is who it claims to be, and that you haven't been redirected by nefarious means (DNS cache poisoning, domain hijacking, etc) and that the server you are talking to really *IS* the www.example.com that you wanted. Note that the most popular application that uses SSL is IE, and that (A) IE is well-known for a lot of ways to hijack things (and that if you've been redirected via Javascript XSS, and you THINK you're talking to foo1.com, but really talking to foo2.com, then a cert for foo2.com will show no problems unless you actually click on the check cert details button and see it's issued to foo2.com. (B) few users seem to actually care. 2) Even if you've successfully connected to www.joes-junkyard-parts.com, and the certificate checks out, and all that, it tells you *NOTHING* about their business other than the fact that they qualified for a cert from some CA. It doesn't tell you if they're just in it for the credit card fraud, or if they will actually ship the parts, or whether they are in the habit of leaving all the credit cards out for anonymous FTP I suspect that the *real* reason there's no PKI yet is because there's no really motivating reason to have anything other than a cert for the company webserver (in most cases). And I suspect that this is unlikely to change until the legal climate regarding digital signatures has changed a lot. Not only does there need to be some legislation about it, but *also* some case law testing what the legislation does and doesn't mean - the biggest challenge will be defining the liability of a company if a private key is hacked/stolen and used to sign things without permission. As Schneier points out, the fact that it's signed *ONLY* proves that the data and the private key were at the same place at the same time, and says nothing about whether it's an *authorized* signature -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09183/pgp0.pgp Description: PGP signature
RE: [isdf] RE: Palladium (TCP/MS)
Don't forget that the web-of-trust of OpenPGP is really a citizen approach and you don't have to rely on a specific entity. ISOC should organize more keysigning party ;-) (ok some at IETF) adulau On Fri, 25 Oct 2002, Franck Martin wrote: This is called PGP and S/MIME. Both are valid IETF RFC. From an industry point of view, S/MIME seems to be the one that will survive in the long run, because it is implemented in nearly all mail clients and follows the certificates used in SSL/TLS which is widely adopted (IPSec to name only one). However, none of them is widely implemented for e-mail purposes because of problems to build a global PKI (in short). I still haven't found a company that will give/sell me a certificate that allows me to sign my organisational e-mails certificates. ISOC is working on it... Cheers. -Original Message- From: Gary Lawrence Murphy [mailto:garym;canada.com] Sent: Friday, 25 October 2002 11:19 To: Franck Martin Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [isdf] RE: Palladium (TCP/MS) Isn't that PGP? ___ Isdf mailing list [EMAIL PROTECTED] http://www.isoc.org/mailman/listinfo/isdf -- --Alexandre Dulaunoy -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=getsearch=0x44E6CBCD People who fight may lose.People who do not fight have already lost. Bertolt Brecht
RE: [isdf] RE: Palladium (TCP/MS)
Title: RE: [isdf] RE: Palladium (TCP/MS) MS promises S/MIME support in their next release, which would be Dec or Mar or Jun or... Currently, Outlook Web Access doesn't know S/MIME, so certificate use is not possible. It is possible to read a signed email and to retrieve the attachment, but it requires Notepad or reconfig of the app to which the PKCS #7 is associated. Not hard. Encrypted emails are unreadable period. -Original Message- From: Franck Martin To: 'Gary Lawrence Murphy' Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Sent: 10/24/02 7:31 PM Subject: RE: [isdf] RE: Palladium (TCP/MS) This is called PGP and S/MIME. Both are valid IETF RFC. From an industry point of view, S/MIME seems to be the one that will survive in the long run, because it is implemented in nearly all mail clients and follows the certificates used in SSL/TLS which is widely adopted (IPSec to name only one). However, none of them is widely implemented for e-mail purposes because of problems to build a global PKI (in short). I still haven't found a company that will give/sell me a certificate that allows me to sign my organisational e-mails certificates. ISOC is working on it... Cheers. -Original Message- From: Gary Lawrence Murphy [mailto:[EMAIL PROTECTED]] Sent: Friday, 25 October 2002 11:19 To: Franck Martin Cc: 'TOMSON ERIC'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: [isdf] RE: Palladium (TCP/MS) Isn't that PGP?
Re: [isdf] Re: Palladium (TCP/MS)
At 08:40 AM 10/22/2002 -0600, Vernon Schryver wrote: Again, other big organizations (specifically including Cisco) are not above embracing-and-extending out of ignorance, provincialism, and failures to bother to do interoperability testing (possible causes of the Microsoft PPP hassles) if not malice. Do not attribute to malice that what comes from management decisions. Robert Moskowitz Senior Technical Director ICSA Labs (248) 968-9809 Fax: (248) 968-2824 [EMAIL PROTECTED] There's no limit to what can be accomplished if it doesn't matter who gets the credit
