Re: CFP: PKI research workshop
At 01:59 PM 1/14/02 -0800, Eric Rescorla wrote: Saying that SSL without certificates is fine as long as you don't have active attacks is kind of like saying that leaving your front door open is fine as long as noone tries to break in. No, its more. SSL sans certs is like using envelopes to write to Dear Abby. You have no authentication on who Dear Abby really is but your communications are private. Since the entity who claims to be Dear Abby also gives a communications address, writing to Dear Abby at that address is sufficient. (Modulo MIM attacks) [Moderator's note: Except that's precisely the point: Modulo MIM attacks is like saying we're all immortal, modulo death. The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] When you call a phone number listed with an advert, and give them your credit card number, you have less confidentiality (you're speaking plaintext), but its the same model. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Tue, 15 Jan 2002, D. A. Honig wrote: [Moderator's note: Except that's precisely the point: Modulo MIM attacks is like saying we're all immortal, modulo death. The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] It requires sophistication to do MIM on a large scale. Active realtime manipulation of traffic on the global scale is currently beyond the scope of TLAs (but they're probably rather good at passive listening by now). Especially, if the initial key exchange is cached, as there's temporal constraints on the window of vulnerability. It's not a minor point, and hence needs repeating. Plus, web of trust mechanisms can always be added later. Rolling out crypto on a massive scale (MUA-MTA, MTA-MTA, IM, P2P) is where's it's at. [Moderator's note: This is simply wrong in a commerce situation. I cannot emphasize that strongly enough. There are tools to assist in doing MIM attacks out there, and doing it globally isn't needed -- doing it in front of one of amazon.com's ssl servers is what you need to do, and there are few large installations out there without even a single vulnerable machine. You need authentication to trust an encrypted connection, and if you use a connection in commerce you need to trust it. Even if your one transaction is low value a large site puts through huge numbers of those low value transactions. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Here you're talking about reputation of nyms, which doesn't require third parties or certs, just well-kept secret keys of a PK pair. If the remote entity keeps using the same PK keys, you can reasonably update reputation based on that alone. (They're essentially signing their behaviors.) [Moderator's note: I fully agree. I was disputing only the notion that unauthenticated connections were sufficient. Authentication does not require certificates or third parties -- see the way SSH handles keys for example. --Perry] Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] Since a signed cert is useful for recovering ZERO dollars from the signer, if you've been defrauded by some entity, the end result is the same if a MIM defrauds you. A *trusted* signer would solve the confidentiality loss problem but not the financial liability problem. But given that signers will sign *anything* (and why not, they have no financial liability and little useful reputation to lose) this is a small difference. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Ben Laurie [EMAIL PROTECTED] writes: Michael Sierchio wrote: Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. And most (all?) commercial CAs then disclaim any responsibility for having actually checked that right correctly... While this is true, I'd point out that all the security software you're using disclaims any responsibility for not having gaping security holes. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Eric Rescorla writes: Ben Laurie [EMAIL PROTECTED] writes: Michael Sierchio wrote: Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. And most (all?) commercial CAs then disclaim any responsibility for having actually checked that right correctly... While this is true, I'd point out that all the security software you're using disclaims any responsibility for not having gaping security holes. If an automaker disclaimed liability for a vehicle, and a negligent design or manufacture resulted in injury or loss, it is my understanding that the liability disclaimer notwithstanding, the automaker would be held responsible. Why do we believe that the same would not be the case for software? Paul Ward - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[EMAIL PROTECTED] writes: Eric Rescorla writes: Ben Laurie [EMAIL PROTECTED] writes: And most (all?) commercial CAs then disclaim any responsibility for having actually checked that right correctly... While this is true, I'd point out that all the security software you're using disclaims any responsibility for not having gaping security holes. If an automaker disclaimed liability for a vehicle, and a negligent design or manufacture resulted in injury or loss, it is my understanding that the liability disclaimer notwithstanding, the automaker would be held responsible. Why do we believe that the same would not be the case for software? In that case, why should the liability also apply to CAs, despite their disclaimers? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[EMAIL PROTECTED] writes: Eric Rescorla writes: [EMAIL PROTECTED] writes: If an automaker disclaimed liability for a vehicle, and a negligent design or manufacture resulted in injury or loss, it is my understanding that the liability disclaimer notwithstanding, the automaker would be held responsible. Why do we believe that the same would not be the case for software? In that case, why should the liability also apply to CAs, despite their disclaimers? Do you mean why should, or why shouldn't? If the latter, then, sure, I believe it should. People running around in business selling products and services and then disclaiming any liability with regard to their performance _for_their_intended_task_ is, IMHO, wrong. Right. My point is this: Security people often argue that PKI is worthless on the grounds that the CAs disclaim all liability. This argument leads to the conclusion that security is essentially worthless since scurity software almost invariably comes with a disclaimer of all liability. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[EMAIL PROTECTED] wrote: If an automaker disclaimed liability for a vehicle, and a negligent design or manufacture resulted in injury or loss, it is my understanding that the liability disclaimer notwithstanding, the automaker would be held responsible. Why do we believe that the same would not be the case for software? Because insufficient case law exists -- some lawyers are bright enough to see pools of liability with software, esp. known vulnerabilities used in DDOS, etc. -- and we technologists are not a litigious bunch. What do you call someone who had a C average in law school? Your honor. That's probably the other problem. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Eric Rescorla wrote: Ben Laurie [EMAIL PROTECTED] writes: Michael Sierchio wrote: Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. And most (all?) commercial CAs then disclaim any responsibility for having actually checked that right correctly... While this is true, I'd point out that all the security software you're using disclaims any responsibility for not having gaping security holes. I have the source to all the security software I'm using... in fact, I wrote quite a lot of it :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Does a user of ssl services care to know absolutely that they are communicating verifiably with whom they believe they have contacted, or does the user care to know absolutely that their communication is completely private? I believe that the latter is most important; transparency through certificate presentation is kept deliberately expensive and is, as has been noted, often disclaimed by CAs, and is compromisable. It's an artificial system of site security perpetuated by the interests of commercial browsers. Why can't self-verification be promoted? Why can't an nslookup call be built into certificate presentations? Yeah I know there's no money in it and certs are one of the few things that actually makes money on the net, but sometimes the built-in dumbing of the commercial internet user by their browser goes too far. The pure truth of mathematical encryption is sold and packaged as a certificate to the internet user, when in fact its power and utility is free of charge, and it is only disclaimed with respect to future or unknown developments. Stef Caunter [EMAIL PROTECTED] ## $ find /self -ctime +1 ## - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
[EMAIL PROTECTED] wrote: ... People running around in business selling products and services and then disclaiming any liability with regard to their performance _for_their_intended_task_ is, IMHO, wrong. IMHO this presents an unsophisticated notion of right versus wrong. By way of analogy: Suppose you go skiing in Utah. A rut left by a previous skier causes you to fall and break your leg, or worse. Now everybody involved has been using the ski area _in_the_intended_manner_ yet something bad happened. So who is liable? The ski area could have groomed that trail, but they didn't. They could have enforced a speed limit, but they didn't. They could at least have bought insurance to cover you, but they didn't. They simply disclaimed all liability for your injury. Not only is this disclaimer a matter of contract (a condition of sale of the lift ticket) it is codified in Utah state law. Other states are similar. If you don't like it, don't ski. Returning to PKI in particular and software defects in particular: Let's not make this a Right-versus-Wrong issue. There are intricate and subtle issues here. Most of these issues are negotiable. In particular, you can presumably get somebody to insure your whole operation, for a price. In the grand scheme of things, it doesn't matter very much whether you (the PKI buyer/user) obtain the insurance directly, or whether the other party (the PKI maker/vendor) obtains the insurance and passes the cost on to you. The insurer doesn't much care; the risk is about the same either way. The fact is that today most people choose to self-insure for PKI defects. If you don't like it, you have many options: -- Call up some PKI vendor(s) and negotiate for better warranty terms. Let us know what this does to the price. -- Call up http://www.napslo.org/ or some such and get your own insurance. Let us know the price. -- Write your own PKI. Then defray costs, if desired, by becoming a vendor. -- Et cetera. In general, there is a vast gray area between Right and Wrong. Most things in my life can be described as not perfect, but way better than nothing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 10:49 AM 1/12/02 -0800, Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. More demos: You can create your own cert with TinySSL, a lightweight ( 100Kbyte) server for Wintel, http://www.ritlabs.com/tinyweb/tinyssl.html and amuse your friends if they bother to read the info there. Using trademarks (RSA, Verisign, etc.) in the fields would escape most. Or, as the TinySSL docs advise, you can get a free cert from Thawte --which *in fact* certifies only that you can receive email at the address you gave them. As others have written, great for enabling SSL's confidentiality, nothing else. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
- Original Message - From: Eric Rescorla [EMAIL PROTECTED] To: Stef Caunter [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; SPKI Mailing List [EMAIL PROTECTED] Sent: Monday, January 14, 2002 12:44 PM Subject: Re: CFP: PKI research workshop Stef Caunter [EMAIL PROTECTED] writes: Does a user of ssl services care to know absolutely that they are communicating verifiably with whom they believe they have contacted, or does the user care to know absolutely that their communication is completely private? These are inextricably connected. If you want to know that your communications are private in the face of active attack you need to know who you're talking to as well. They may be connected, but save and except in the case of active man-in-the-middle attack I maintain that ssl's confidentiality, which is free, is what sells certificates. I use a free Thawte email cert for confidential communication; my identity is verified through their notarization system, again free. I believe that the latter is most important; transparency through certificate presentation is kept deliberately expensive and is, as has been noted, often disclaimed by CAs, and is compromisable. It's an artificial system of site security perpetuated by the interests of commercial browsers. How exactly does the difficulty of getting certificates help browser manufacturers? Browsers have CA root trust hard-coded into them. All commerce sites rely on their use and code with their use in mind. The commercial browser manufacturers also sell certificates. It is clearly difficult to engage in encrypted commerce without a major client browser development kit and a CA provided cert. The appearance of ease-of-use with a commercial certificate and commercial browser implies _greatly_ that thing which is explicitly _disclaimed_ by these people. Why can't self-verification be promoted? Why can't an nslookup call be built into certificate presentations? What are you talking about? An nslookup call wouldn't help anything. Why not? A self-generated certificate correlating to an ns and whois record pointing to an active business with a human to answer inquiries seems reasonable and no more disclaimable than CA evasiveness. The essential problem is establishing that the public key you receive over the network actually belongs to the person you think it does. In the absence of a prior arrangement, the only way we know how to do this is to have that binding vouched for by a third-party. Yes. Trust can be earned and vouched for by other third parties. Trust points are a commonly used method on the big auction sites. The Thawte Web of Trust works without the blessing of a financial transaction. I'm interested; why do we feel we have to point at something we bought to facilitate ssl transactions? Commercial browser and commercial security interests often promulgate the anxiety they claim to alleviate. SC -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Stef Caunter [EMAIL PROTECTED] writes: Stef Caunter [EMAIL PROTECTED] writes: Does a user of ssl services care to know absolutely that they are communicating verifiably with whom they believe they have contacted, or does the user care to know absolutely that their communication is completely private? These are inextricably connected. If you want to know that your communications are private in the face of active attack you need to know who you're talking to as well. They may be connected, but save and except in the case of active man-in-the-middle attack I maintain that ssl's confidentiality, which is free, is what sells certificates. This is confused. What sells certificates is security. Users aren't sophisticated enough to understand the difference between confidentiality and authentication, but they've been told by the browser manufacturers (rightly) that in order to have security they need to have certificates. Saying that SSL without certificates is fine as long as you don't have active attacks is kind of like saying that leaving your front door open is fine as long as noone tries to break in. I use a free Thawte email cert for confidential communication; my identity is verified through their notarization system, again free. This is essentially the PGP model. It doesn't really work acceptably for large scale e-commerce. I believe that the latter is most important; transparency through certificate presentation is kept deliberately expensive and is, as has been noted, often disclaimed by CAs, and is compromisable. It's an artificial system of site security perpetuated by the interests of commercial browsers. How exactly does the difficulty of getting certificates help browser manufacturers? Browsers have CA root trust hard-coded into them. All commerce sites rely on their use and code with their use in mind. The commercial browser manufacturers also sell certificates. Since when? As far as I know, Microsoft and Netscape just send you to VeriSign. It is clearly difficult to engage in encrypted commerce without a major client browser development kit and a CA provided cert. It certainly isn't true that you need a major client browser development kit to engage in e-commerce. You can do just fine with ApacheSSL or mod_ssl. You do generally need a certificate. Why can't self-verification be promoted? Why can't an nslookup call be built into certificate presentations? What are you talking about? An nslookup call wouldn't help anything. Why not? A self-generated certificate correlating to an ns and whois record pointing to an active business with a human to answer inquiries seems reasonable and no more disclaimable than CA evasiveness. Both DNS and whois can be spoofed by an active attacker. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 09:44 AM 1/14/2002 -0800, Eric Rescorla wrote:
Stef Caunter [EMAIL PROTECTED] writes:
Does a user of ssl services care to know absolutely that they are
communicating verifiably with whom they believe they have contacted, or does
the user care to know absolutely that their communication is completely
private?
These are inextricably connected. If you want to know that
your communications are private in the face of active attack
you need to know who you're talking to as well.
Of course you do. That's why https://store.palm.com/ is such a problem. You thought
you were talking to (and wanted to talk to) Palm Computing, just like the logos and
page layout said you were. You're not. You're talking to a MITM. Palm hired them to
run the store? The certificates don't say that.
[snip]
Why can't self-verification be promoted? Why can't an nslookup call be built
into certificate presentations?
What are you talking about? An nslookup call wouldn't help anything.
The essential problem is establishing that the public key you receive
over the network actually belongs to the person you think it does.
In the absence of a prior arrangement, the only way we know how
to do this is to have that binding vouched for by a third-party.
Actually, Eric, the third party might confuse that for you. The function it performs
with respect to naming is not totally unlike the function of early anonymizers. The
TTP chooses a name to bind to the public key that might have only a tenuous relation
to the name by which you know the keyholder. As a result, when you do a name
comparison between the certificate Subject and what you know about this person, the
person you think it does, you may have to make a guess about whether the match is
correct.
Here we spend all this effort to reduce the probability of error, in the cryptography,
to values like 2^{-128} and then make the security decision depend just as much on a
guess with a much greater probability of error. From the point of view of error
probability, we should have left out the cryptographic part entirely.
- Carl
P.S. the workshop where we should (and probably will) be discussing this is
http://www.cs.dartmouth.edu/~pki02/ and there are still two weeks before papers are
due.
++
|Carl Ellison Intel E: [EMAIL PROTECTED] |
|2111 NE 25th Ave M/S JF3-212 T: +1-503-264-2900 |
|Hillsboro OR 97124 F: +1-503-264-6225 |
|PGP Key ID: 0xFE5AF240 C: +1-503-819-6618 |
| 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240|
++
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Carl Ellison [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 09:44 AM 1/14/2002 -0800, Eric Rescorla wrote: Stef Caunter [EMAIL PROTECTED] writes: Does a user of ssl services care to know absolutely that they are communicating verifiably with whom they believe they have contacted, or does the user care to know absolutely that their communication is completely private? These are inextricably connected. If you want to know that your communications are private in the face of active attack you need to know who you're talking to as well. Of course you do. That's why https://store.palm.com/ is such a problem. You thought you were talking to (and wanted to talk to) Palm Computing, just like the logos and page layout said you were. You're not. You're talking to a MITM. Palm hired them to run the store? The certificates don't say that. The certificates say EXACTLY that. They say that this entity is authorized to use the domain name store.palm.com. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 02:47 PM 1/14/2002 -0800, Eric Rescorla wrote: Meanwhile, the information that the user really looks at to make a security decision (the Palm logo and the little padlock) aren't related at all. No possible security system can protect people who trust whatever logo happens to be transmitted to them in web pages. That is certainly true today, but that is precisely how users decide whether or not to give up their credit card numbers or more sensitive information. It's a good thing that the user is absolved of liability in case the credit card is stolen. I disagree that it's not possible to secure logos. It's a MMOP (mere matter of programming). :) - Carl ++ |Carl Ellison Intel E: [EMAIL PROTECTED] | |2111 NE 25th Ave M/S JF3-212 T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-6225 | |PGP Key ID: 0xFE5AF240 C: +1-503-819-6618 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240| ++ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Carl Ellison [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 02:47 PM 1/14/2002 -0800, Eric Rescorla wrote: Meanwhile, the information that the user really looks at to make a security decision (the Palm logo and the little padlock) aren't related at all. No possible security system can protect people who trust whatever logo happens to be transmitted to them in web pages. That is certainly true today, but that is precisely how users decide whether or not to give up their credit card numbers or more sensitive information. It's a good thing that the user is absolved of liability in case the credit card is stolen. I disagree that it's not possible to secure logos. It's a MMOP (mere matter of programming). :) I didn't say that it wasn't possible to secure logos. I said that you couldn't protect people who trusted logos that were transmitted to them in Web pages. This is not the same thing. The point is that such logos are transmitted in-band and are part of the web page. Therefore, they are not cryptographically verified. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
At 05:45 PM 12/26/2001 -0500, Perry E. Metzger wrote: Phillip Hallam-Baker [EMAIL PROTECTED] writes: Methinks you complain too much. PKI is in widespread use, it is just not that noticeable when you use it. This is how it should be. SSL is widely used to secure internet payment transactions. HTTPS SSL does not use PKI. SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. (If you don't believe me about the assurance levels, read a Verisign cert practice statement sometime.) If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. +--+ |Carl M. Ellison [EMAIL PROTECTED] http://world.std.com/~cme | |PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Carl Ellison [EMAIL PROTECTED] writes: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? No. It means that your credit card info goes to people who have been authorized to use the domain name store.palm.com. The certificate reflects that. This appears to be a case of outsourcing. Check the certificate. Is your claim that Modus Media is NOT authorized to operate store.palm.com? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Michael Sierchio [EMAIL PROTECTED] writes: Carl Ellison wrote: If that's not good enough for you, go to https://store.palm.com/ where you have an SSL secured page. SSL prevents a man in the middle attack, right? This means your credit card info goes to Palm Computing, right? Check the certificate. To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. Yes, but it only takes one of the hundreds of CAs to fail to make this check and the whole system fails. C.f. Verisign signing a fake MicroSoft cert last year -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
to be fair ... most commercial CA's have to verify with the domain name infrastructure as to the owner of the domain name ... before issuing a SSL domain name server cert. Note however, one of the justifications for having SSL domain name server cert is because of concerns with regard to domain name infrastructure integrity issues and things like domain name hikjacking. Note however, that if the domain name infrastructure has had a domain name hijack before the SSL server cert is applied for ... when the CA goes to the domain name infrastructure to verify the domain name ownership ... it will verify and a SSL server cert can be issued to the wrong entity (aka the issuing of a SSL server cert is subject to some of the same integrity exposures as concerns that gave rise to having SSL server certs in the first place). Furthermore, some of the proposals to address domain name infrastructure integrity issues so that CAs can trust their verification as to domain name ownership ... also eliminates justifications for needing SSL server certs random refs: http://www.garlic.com/~lynn/subtopic.html#sslcerts [EMAIL PROTECTED] on 1/12/2002 12:31 pm wrote: To be fair, most commercial CA's require evidence of right to use a FQDN in an SSL server cert. But your point is apt. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Russ Neson writes: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. It's not clear what you mean by the limited threat model in encrypting web forms, but one correction is necessary: known plaintext is not an issue. See the sci.crypt thread Known plaintext considered harmless from June, 2001 (available by advanced search at groups.google.com). Especially note the perceptive comments by David Wagner and David Hopwood. There is no need to be concerned that encrypted web forms contain known plaintext: no plausible threat model can exploit that information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
one of the largest financial networks ... slightly different kind http://www.garlic.com/~lynn/2001n.html#22 again financial ... discussion of additional kinds of risks/threats Sound Practices for the Management and Supervision of Operational Risk http://www.bis.org/publ/bcbs86.htm Intro ... The purpose of this paper, prepared by the Risk Management Group of the Basel Committee on Banking Supervision (the Committee), is to further the Committee's dialogue with the industry on the development of Sound Practices for the Management and Supervision of Operational Risk. Comments on the issues outlined in this paper would be welcome, and should be submitted to relevant national supervisory authorities and central banks and may also be sent to the Secretariat of the Basel Committee on Banking Supervision at the Bank for International Settlements, CH-4002 Basel, Switzerland by 31 March 2002. Comments may be submitted via e-mail: [EMAIL PROTECTED] or by fax: + 41 61 280 9100. Comments on this paper will not be posted on the BIS website. [EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote: to which I would add: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
PAIIN crypto taxonomy (was Re: CFP: PKI research workshop)
The PAIIN model (privacy, authentication, identification, integrity, non-repudiation) is inadequate to represent the uses of cryptography. Besides the distinction between privacy and confidentiality, I'd like to point out some additional uses of cryptography which either don't fit at all or are poorly represented in this model: Anonymity - the ability to communicate without messages being attributed to the sender (e.g. remailers). Confidential verification -- the ability to verify information without disclosing it (e.g. zero knowledge proofs). Fragmentation -- dividing control over information among several parties. Invisibility -- the ability to communicate or store information without being detected. This includes stegonography, low probability of observation communication techniques such as low power spread spectrum, and measures against traffic analysis such as link encryption. Proof of trespass -- The ability to demonstrate that anyone having access to data knew they were doing so without authorization, (e.g. for trade secret and criminal evidence law). Remote randomization -- the ability for separated parties to create fair and trusted random quantities. Resource taxing -- techniques to prove a minimum expenditure of computing resources e.g. hash-cash. Time delay -- making information available but not immediately. Transmission assurance -- anti-jam and anti censorship technology. Use control -- the whole digital rights management scene. I'm not suggesting this is a complete list or the best breakdown, but I hope is shows that the cryptographic imagination goes beyond PAIIN. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Lynn, I think you should specify confidentiality as another issue to be addressed. Perhaps you include confidentiality in your privacy or security subsections, but I've found that many people think (and mean) different things when they use these two terms. For example, is privacy necessarily privacy of communicated data from eavesdroppers, or is it the privacy of personal information (perhaps the privacy of the authentication information) so an eavesdropper does not know who is communicating? Unfortunately your garlic.com URL (security.htm) does not work and returns an HTTP 404 error. -derek [EMAIL PROTECTED] writes: sometimes the principles of security are referred to as PAIN or sometims PAIIN see http://www.garlic.com/~lynn/security.htm and click on PAIN PAIIN in the acronym section of the glossary. Doing a threat model ... would include not only end-to-end issues but what aspects of PAIIN are being addressed. privacy, authentication, identification, integrity, non-repudiation (PAIIN) (see also authentication, identification, integrity, non-repudiation, privacy, security) an aspect of security can be integrity and and aspect of integrity can be dependability leading to things like: http://www.hdcc.cs.cmu.edu/may01/index.html which is then related back to my posting on sunday (with regard to integrity) http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop [EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote: to which I would add: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
well PAIN is out of some standards organization (as is 3-factor authentication) i agree that privacy and confidentiality is sometimes thot of as different but others argue that it reduces to the effectively the same requirements ... even tho different people have different connotations with the two terms. i had fumble fingered 3-4 URLs yesterday and the posting to correct them seems to have gotten suspended for some time in the ether note however the url for the security taxonomy and glossary had been typed correctly in a posting made earlier in the day ... i.e. http://www.garlic.com/~lynn/secure.htm [EMAIL PROTECTED] on 1/2/2002 7:37 am wrote: Lynn, I think you should specify confidentiality as another issue to be addressed. Perhaps you include confidentiality in your privacy or security subsections, but I've found that many people think (and mean) different things when they use these two terms. For example, is privacy necessarily privacy of communicated data from eavesdroppers, or is it the privacy of personal information (perhaps the privacy of the authentication information) so an eavesdropper does not know who is communicating? Unfortunately your garlic.com URL (security.htm) does not work and returns an HTTP 404 error. -derek - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
aka ... lots of people seem to equate privacy with personal privacy (as well as legislative specification) ... while confidentiality has more of a non-personal connotation there seems to be 3-4 postings from yesterday that are still lost in the ether ... they are recorded at http://www.garlic.com/~lynn/aadsm9.htm http://www.garlic.com/~lynn/aadsm10.htm from http://www.garlc.com/~lynn/secure.htm confidentiality (1) The assurance that information is not disclosed to inappropriate entities or processes. (2) The property that information is not made available or disclosed to unauthorized entities. (3) The prevention of the unauthorized disclosure of information. (4) The concept of holding sensitive data in confidence, limited to an appropriate set of individuals or organizations. [AJP] Assurance that information is not disclosed to inappropriate entities or processes. [FCv1] The concept of holding sensitive data in confidence, limited to an appropriate set of individuals or organizations. [NCSC/TG004] The prevention of the unauthorized disclosure of information. [ITSEC][NIAP] The principle that keeps information from being disclosed to anyone not authorized to access it. Synonymous with secrecy. [AFSEC] The property that information is not made available or disclosed to unauthorized entities. [JTC1/SC27/N734] The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. [TNI] The property that sensitive information is not disclosed to unauthorized individuals, entities or processes. [FIPS140] (see also assurance, data confidentiality, data confidentiality service, privacy, privacy programs, security) privacy (1) The ability of an individual or organization to control the collection, storage, sharing, and dissemination of personal and organizational information. (2) The right to insist on adequate security of, and to define authorized users of, information or systems. Note: The concept of privacy cannot be very precise, and its use should be avoided in specifications except as a means to require security, because privacy relates to 'rights' that depend on legislation. [AJP] (1) the ability of an individual or organization to control the collection, storage, sharing, and dissemination of personal and organizational information. (2) The right to insist on adequate security of, and to define authorized users of, information or systems. Note: The concept of privacy cannot be very precise and its use should be avoided in specifications except as a means to require security, because privacy relates to 'rights' that depend on legislation. [TNI] (I) The right of an entity (normally a person), acting in its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share information about itself with others. (O) 'The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.' (D) ISDs SHOULD NOT use this term as a synonym for 'data confidentiality' or 'data confidentiality service', which are different concepts. Privacy is a reason for security rather than a kind of security. For example, a system that stores personal data needs to protect the data to prevent harm, embarrassment, inconvenience, or unfairness to any person about whom data is maintained, and to protect the person's privacy. For that reason, the system may need to provide data confidentiality service. [RFC2828] (see also confidentiality, private communication technology, private key, security, quality of protection) (includes Privacy Enhanced Mail, data privacy, pretty good privacy, privacy programs, privacy, authentication, identification, integrity, non-repudiation, privacy, authentication, identification, non-repudiation, virtual private network) [EMAIL PROTECTED] on 1/2/2002 9:18 am wrote: well PAIN is out of some standards organization (as is 3-factor authentication) i agree that privacy and confidentiality is sometimes thot of as different but others argue that it reduces to the effectively the same requirements ... even tho different people have different connotations with the two terms. i had fumble fingered 3-4 URLs yesterday and the posting to correct them seems to have gotten suspended for some time in the ether note however the url for the security taxonomy and glossary had been typed correctly in a posting made earlier in the day ... i.e. http://www.garlic.com/~lynn/secure.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Andrew Odlyzko writes: 1. Cryptography does not fit human life styles easily. 2. Novel technologies take a long time to diffuse through society. to which I would add: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | If you argue with someone 521 Pleasant Valley Rd. | +1 315 268 1925 voice | who is not rational, he will Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | always win, in his own mind. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
somewhat as an aside ... the requirement(s) given the X9A10 financial standards working group for the development of the X9.59 standard was * to preserve the integrity of the financial infrastructure for all retial electronic payments without the use of encryption ALL didn't just mean internet or just mean credit it met ALL ... all environments ... all types of transactions, etc. Without the use of encryption didn't mean that information hiding wasn't precluded (say for privacy reasons) but weren't required to preserve the integrity of the financial infrastructure (aka that complete clear-text could be made available and it wasn't possible to do a fraudulent transaction based on everybody in the world potentially having the cleartext of that payment transaction). Implied in the requirement was that it had to also be extremely lightweight in order to be applicable to some of the existing electronic payments environments. Again ALL met ALL ... including a large number of existing electronic environments. Frequently from scratch protocol definitions are faster to do if you don't have to take into account any existing infrastructure (and/or only addressing an extremely small subset of the total end-to-end problem).. To meet the requirements we eventually settled on a very lightweight, end-to-end authentication definition (strong authentication of every transaction had to flow completely through from the consumer all the way through to the consumer's financial infrastructure). x9.59 references: http://www.garlic.com/~lynn/index.html#x959 [EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote: to which I would add: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
sometimes the principles of security are referred to as PAIN or sometims PAIIN see http://www.garlic.com/~lynn/security.htm and click on PAIN PAIIN in the acronym section of the glossary. Doing a threat model ... would include not only end-to-end issues but what aspects of PAIIN are being addressed. privacy, authentication, identification, integrity, non-repudiation (PAIIN) (see also authentication, identification, integrity, non-repudiation, privacy, security) an aspect of security can be integrity and and aspect of integrity can be dependability leading to things like: http://www.hdcc.cs.cmu.edu/may01/index.html which is then related back to my posting on sunday (with regard to integrity) http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop [EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote: to which I would add: 3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
another aspect that overlaps PKIs and quality is the difference between application code and service code turning an application into a service can be hard possibly writing 4-10 times as much code as in the base application infrastructure and very high-quality code dealing with potentially very complex failure modes. Related thread (buffer overflow) has been running in the sci.crypt newsgroups. partial reference: http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow http://www.garlic.com/~lynn/2001n.html#90 Buffer overflow also an older thread regarding assurance in application and digital signature authentication http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, x9.59, etc [EMAIL PROTECTED] at 12?29/2001 3:22 pm wrote: Now, an interesting thing might be regarding rapid uptake of general security. One could contend that majority of the market believes that good, strong security should be an attribute of the basic infrastructure ... somewhat like the issue of automobile quality in the '70s, not going to pay any more for it ... but would migrate to a manufactor that had significantly better quality. You then have the 1) vendors that don't see quality as worth while since they won't be able to charge more 2) new vendors that would like to sell quality as a stand-alone attribute ... not actually having to manufactor automobiles but somehow convince customers that they can sell quality independent of any product, and 3) vendors that feel that they can eventually gain market share by providing better quality. Substitute security and/or PKI in place of quality. Part of the issue is that security (and strong authentication) should be an attribute of the basic infrastructure ... not something that exists by itself in a vacuum. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
somewhat as an aside the gift cards (and other flavors) that you see at large percentage of retail check-out counters in the US are effectively digital cash ... although the current incarnation results in a different card at every retailer. however, they are online, magstripe-based digital cash utilizing the same ubquituous point-of-sale infrastructure as debit credit (it is just that the transaction routing goes to different online transaction processing than credit debit). The issue of whether or not it would be possible to use any card at any merchant is more of a business rule issue than a technology issue. note from a higher assurance standpoint ... the x9.59 work is applicable to all electronic transactions whether they are credit, debit, e-check, OR (online) digital cash ... AND x9.59 transactions could flow over both existing ubiquituous point-of-sale network and/or a ubiquituous internet network (or any other kind of network). random refs: http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/index.html#aads [EMAIL PROTECTED] on 12/28/2001 4:50 pm wrote: A local financial branch implementation and a digital cash implementation might have a number of similar useability attributes aka from the standpoint of how local funds do you have immediately available aka funds are transferred into you local PDA as digital cash for immediate use or funds are transferred into the local financial institution for immediate use. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: CFP: PKI research workshop
Arnold G. Reinhold [EMAIL PROTECTED] writes: The EWR monorail had been shut down for the better part of a year to correct a pesky track corrosion problem (it's hard to get all the bugs out of a system that is not widely used). Thus making it a perfect analogy for PKI [0]. Peter. [0] Before people flame me for this, what's currently widely-used is what's in X.509v1 modulo CRL support. Anything else, you're on your own. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
everyday life has a lot of cryptography ... for instance ... there is quite a bit of cryptography involved in every debit transaction (every time you get money from ATM machine or use point-of-sale terminal). a lot of PKI revolves around the business process of strong authentication where some aspects of cryptography happens to be used. A subset of this saw extremely rapid uptake with regard to SSL and online shopping (again quite a bit of cryptography in use, one might make a case that cryptography should be like electronic dsitributors, everybody may have one ... but very few could actually build one from scratch or even know thay actually have one). One might be tempted to make the observation that uptake rate is much faster if it is filling a new need as opposed to trying to change existing operation. However, PKI industry seems to have tried to make public key cryptography and certificates an end in themselves. First off, certificates are a solution to strong authentication in an offline environment (aka early '80s offline email paradigm) which doesn't have a very good match to most of the business processes that are in use today. A PIN debit transaction involves the relying-party (the consumer's bank both authenticating and authorizing the transaction authentication based on something you have and something you know ... and authorization on a combination of authentication, available funds, any previous transactions today, the aggregate value of any current day transactions, etc). Digital signature can improve the integrity of the existing PIN-debit based operation and also expand the use to open/insecure network (i.e. the existing PIN-debit is predicated on closed, secure network). This is what NACHA (national cllearing house association ... aka typically regional and national financial industry organizations that provide infrastructure for bank-to-bank wholesale financial transfers) did in the debit demonstration basically upgrading PIN-based cyrptography for authentication to digital-signature cryptography for authentication (where a shared secret paradigm ... aka PIN-base was replaced with a non-shared secret paradigm). http://www.garlic.com/~lynn/index.html#aads There was no certificate necessary ... and, in fact, certificates aren't really about cryptography, there are more about a specific kind of offline business process (which is having difficulty finding a niche in an increasingly online world). Furthermore, not only is the offline-paradigm certificate model having a difficulty finding a niche in an online world ... the idea of a purely authentication business process is possibly having trouble finding its niche ... referencing prior posting that most business tend to perform authentication ... a cost overhead ... as part of some useful, productive business process (not purely an end in itself) http://www.garlic.com/~lynn/aadsm9.htm#cfppki7 One might envision a Monty Python Department of Authentication. Citizens are asked to visit their local Department of Authentication every day, state their name, and provide certificate/credential for proof of their claimed identity. The Department of Authentication doesn't actually record that they've prooved any identity and citizens aren't actually mandated to show up. However, if the citizens do show up everyday to their local Department of Authentication, it makes the DoA employees feel that they are providing a useful service in the scheme of the universe (as well as certificates/credentials that are voluntarily verified everyday are better than ones that aren't ... something like pet rocks). Now, an interesting thing might be regarding rapid uptake of general security. One could contend that majority of the market believes that good, strong security should be an attribute of the basic infrastructure ... somewhat like the issue of automobile quality in the '70s, not going to pay any more for it ... but would migrate to a manufactor that had significantly better quality. You then have the 1) vendors that don't see quality as worth while since they won't be able to charge more 2) new vendors that would like to sell quality as a stand-alone attribute ... not actually having to manufactor automobiles but somehow convince customers that they can sell quality independent of any product, and 3) vendors that feel that they can eventually gain market share by providing better quality. Substitute security and/or PKI in place of quality. Part of the issue is that security (and strong authentication) should be an attribute of the basic infrastructure ... not something that exists by itself in a vacuum. [EMAIL PROTECTED] on 12/28/2001 6:54 wrote: Several of the comments about the slow uptake of PKI touch on what seem to be two basic factors that are responsible for this phenomenon: 1. Cryptography does not fit human life styles easily. As an example, truly secure systems would stop secretaries from forging their boss's
Re: CFP: PKI research workshop
Let us see. Monorails are commonplace in airports these days. Web cams for online chat are used by millions of teenagers SST ? What is that Phill -Original Message- From: Peter Gutmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 27 December 2001 21:42 Subject: Re: CFP: PKI research workshop As I never tire of saying, PKI is the ATM of security. Naah, it's the monorail/videophone/SST of security. Looks great at the World Fair, but a bit difficult to turn into a reality outside the fairgrounds. Peter (who would like to say that observation was original, but it was actually stolen from Scott Guthery). - The SPKI Mailing List Unsubscribe by sending unsubscribe spki to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Thu, 27 Dec 2001 [EMAIL PROTECTED] wrote: given that authentication is being performed as part of some business process or function ... then it is normally trivial to show it is easier to have authentication (even digital signature authentication) integrated into such business processes and correspondingly easy to show that certificate-based operations are redundant, superfulous and extraneous (modulo the issue of toy demos are cheaper than modifying production business operations). The only case in which the PKI solution is not redundant is in offline clearing. But getting your point-of-transaction online is easier than paying attention to PKI. I happen to like offline clearing -- it opens up the possibility of new transaction types and doing transactions in places you couldn't before. But the practical issue is, everybody who's interested in electronic transactions of any kind is also interested in getting online, and when PKI's were deployed in developing areas (south africa) they got dumped just as soon as the area was developed enough for communications to support online clearing. On the principle of people refusing to adopt something until it relieves pain, maybe we won't see a real PKI deployed until we need to serve markets where speed-of-light delays make online clearing impractical. Mars, for example, is 3 to 22 light-minutes away. I don't imagine someone using an ATM on Mars is going to want to wait 12 to 88 minutes for online clearing (more if the protocol is talky or the bandwidth is busy...). So a martian colony might be the first practical application of PKI and/or digital cash, assuming the colonists want to do business with Earth companies. But a colony looks pretty distant right now: we haven't even got an outpost there yet. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
SST is the SuperSonic Transport; I think the term was specific to US attempts to build something like the Concorde, but it may have been more generic. Among other problems (making it work, sonic booms, economics in general), use of fast airplanes in non-military airspace was limited by the capabilities of the air-traffic control systems, which couldn't really handle airplanes that fast. It's much easier to build supersonic airplanes for the military, where you're not concerned about price per passenger-mile. Except for airports and amusement parks, the only place I've seen a monorail is in Seattle. (I'm counting Las Vegas as an amusement park :-) Airports similarly don't follow normal economic rules, because they can often scam money out of government authorities, who will often do stuff because it Looks Cool. There may be economic niches where monorails make sense (streets that are too narrow to add pillars for conventional elevated railways, perhaps), but they're pretty limited. Until recently I was the Regional ATM Specialist for one of the offshoots of The Phone Company that did the PicturePhones at the World's Fair back in the 60s :-) Web cams are widely available, but they're still not how most people make their phone calls, and it did take 30-40 years before they finally became economical. ATM also has a fairly wide economic niche, though routers have caught up with the big end of the performance curve, and it always was too complex to win at the desktop end. PKIs are quite simple and low cost to implement - the problems are finding a way to make them widely useful. Unfortunately, that hasn't matched most PKI companies' business plans that promised World Domination to their VCs :-) And even among the people who adopt crypto because it Looks Cool, the last time I looked through the Web Of Trust on the PGP keyservers, most keys were either unsigned or only signed by a couple of people, not enough to build a big connected graph. Bill At 07:34 PM 12/28/2001 +, Phillip Hallam-Baker wrote: Let us see. Monorails are commonplace in airports these days. Web cams for online chat are used by millions of teenagers SST ? What is that Phill -Original Message- From: Peter Gutmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 27 December 2001 21:42 Subject: Re: CFP: PKI research workshop As I never tire of saying, PKI is the ATM of security. Naah, it's the monorail/videophone/SST of security. Looks great at the World Fair, but a bit difficult to turn into a reality outside the fairgrounds. Peter (who would like to say that observation was original, but it was actually stolen from Scott Guthery). - The SPKI Mailing List Unsubscribe by sending unsubscribe spki to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: CFP: PKI research workshop
1) SST = supersonic transport (see Concorde, see Concorde on government life support, see Concorde in pretty orange and yellow.) 2) monorail = one rail, not elevated, or driver-less. The only running monorail I know of is in Seattle; it was left over after the 1962 Worlds Fair. All the airport people-movers I have seen run on two rails or on a roadway. 3) Videophone != Webcam (see Picturephone) See also magnetic bubbles, cold fusion, Charles Atlas and Ginger. PKI is a great marketing gimmick. No doubt about it. Put that logo on your home page and all the hoi polloi feel warm and fuzzy. Flashing neon signs work better than drab old hand-lettered ones. But how much risk does it reduce? What is the insurance premium with it and what is it without it? How much underwriting is premised on PKI? Is there one instance where an insurance premium has been reduced by more than the cost of the PKI implementation and the ongoing cost of its administration? STP does a great business. So does Mary Kay. I don't knock 'em. But I do understand what kind of oil they are. Cheers, Scott -Original Message- From: Phillip Hallam-Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 2:34 PM To: Peter Gutmann; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: CFP: PKI research workshop Let us see. Monorails are commonplace in airports these days. Web cams for online chat are used by millions of teenagers SST ? What is that Phill -Original Message- From: Peter Gutmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 27 December 2001 21:42 Subject: Re: CFP: PKI research workshop As I never tire of saying, PKI is the ATM of security. Naah, it's the monorail/videophone/SST of security. Looks great at the World Fair, but a bit difficult to turn into a reality outside the fairgrounds. Peter (who would like to say that observation was original, but it was actually stolen from Scott Guthery). - The SPKI Mailing List Unsubscribe by sending unsubscribe spki to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
both atm debit network and domain name infrastructure care capable of local caching so that timelyness is within seconds to minutes (or a few hrs as parameter within the needs of the infrastructure). the offline world for certificates is the analogy of the letters of credit from the days of the sailing ships. near real time with managed caching (with relying parties forced to deal with stale credentials manufactored months or years in the past). part of the issue in clearing is who has the liability at any particular instance; in the case of debit network caching there are very specific procedures and processes. Are you suggesting that the certification industry will assume liability in the case of offline clearing associated with mars colonilization? the process tends to be authentication, authorization, and finally settlement and clearing. sometimes authorization, settlement and clearing can be batched. if you are really talking about the bank account balance resides on the earth and the access is from mars offline authentication (clearing really needs to know whether the money actually exists or not regardless of whether or not you are dealing with the owner of the account) doesn't get you clearing and real clearing needs to know that the money really exists (not just that a person is authenticated) ... and if the account balance is on earth and it takes 30 minutes elapsed time to establish it ... then that it what it takes. More realistic is account balance caching at some near real-time location on mars ... say within the parameters of the ATM withdrawal limit. At one point in the PKI evolution there was the proposal that there could be certificates analogous to the '70s signing limit checks .,... an attempt to create certificates that not only provided authentication information but also some hypothetical useful approximation to authorization information (aka not quite reqressing totally to the pre-70s credit card model). The issue in the signing limit checks was when they found people writing 200 $5000 (limit) checks to get a million. What has been seen since that time is near real-time purchasing department operation (including business purchase cards that leverage the credit card system) to provide real-time aggregation ... as opposed to sinlge event operation. In the ATM machine withdrawal case, there are typically both single widthrawal limits as well as daily aggregate withdrawal limits (aka the PKI proposal for credit cards turned out to be a business process regression to pre-70s and the PKI proposal for business checks turned out to be a business process reqression to pre'80s). Typically what you might have in a ATM withdrawal case with foreign ATM machine (not your local bank) is that the owner of the ATM machine is given a guarentee of funds from your financial institution prior to the ATM machine releases paper money. Your bank then effectively debits your account for the equivalent amount of funds. Then typically sometime that evening, there is a settlement operation where there is funds transfer from your bank to the financial institution that owns the ATM. An offline, stale certificate only (slightly) addresses the issue of authentication say an identification certificate ... which might not even provide a binding between you and any particular bank or bank account. Some sort of binding between you, your bank, and your bank account is needed just for the authentication phase of what you are talking about. There is still the authorization phase needed so that the owner of the ATM machine believes that it can receive something (in return for spitting out paper bills). That effectively has to find that there are actually sufficient funds in your account. So a more realistic scenario would be that there is possibly dual account, one local and one on earth ... with funds floating back and forth as needed in evening settlements. If you are on Mars there is some local financial branch with local record of funds that you have immediately available and which can authorize that amount of money. A local financial branch implementation and a digital cash implementation might have a number of similar useability attributes aka from the standpoint of how local funds do you have immediately available aka funds are transferred into you local PDA as digital cash for immediate use or funds are transferred into the local financial institution for immediate use. ray dillinger [EMAIL PROTECTED] on 12/28/2001 2:29 pm wrote: The only case in which the PKI solution is not redundant is in offline clearing. But getting your point-of-transaction online is easier than paying attention to PKI. I happen to like offline clearing -- it opens up the possibility of new transaction types and doing transactions in places you couldn't before. But the practical issue is, everybody who's interested in electronic transactions of any kind is
Re: CFP: PKI research workshop
Several of the comments about the slow uptake of PKI touch on what seem to be two basic factors that are responsible for this phenomenon: 1. Cryptography does not fit human life styles easily. As an example, truly secure systems would stop secretaries from forging their boss's signatures, and this would bring all large beaucratic organizations to a standstill. 2. Novel technologies take a long time to diffuse through society. Internet time is a myth. As just one example, a news story I just read was about the great success of online bill paying. This is all very well and good, but weren't we supposed to have that a long time ago? As a matter of fact, didn't Microsoft try to buy up Intuit back in 1994 largely in order not to be deprived of the possibility of controlling online payments? (I have two papers on this subject, one a short one, The myth of Internet time that appeared in the April 2001 issue of Technology Review, and a longer, more detailed one, The slow evolution of electronic publishing, published in 1997, that argue that consumer adoption rates are not noticeably faster now than in the pre-Internet days. Both are available on my home page.) Andrew Odlyzko -Please note new address- Andrew Odlyzko University of Minnesota Digital Technology Center 1200 Washington Avenue South Minneapolis, MN 55415 [EMAIL PROTECTED] email 612-624-9510 voice phone 612-625-2002 fax http://www.dtc.umn.edu/~odlyzko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
for the most part HTTPS SSL is certificate manufactoring (a term we coined a couple years ago) infrastructure typically implies the administrative and management which would require (at a minimum) CRLs for a certificate-based PKI. the interesting thing about the use of SSL domain name server certificates is that they supposedly are addressing an integrity issue in the domain name infrastructure i.e. SSL checks that the domain name listed in the SSL domain name server certificate is the same as the domain name clicked/typed in for contacting the server. The issue is that the domain name could be hijacked and instead of going to the real IP-address it gets rerouted to a fraudulent IP-address. however, if you track back the trust infrastructure for the SSL domain name server certificate the process is somebody applies for a SSL domain name server certifificate with a certification authority. The standard operating procedure for certification authorities is that they typically have to verify the information that they are certifying (in this case domain name ownership) with the authoritative agency for the information (in this case the domain name infrastructure). Now since there could be an integrity problem in the domain name infrastructure with respect to domain name hijacking ... there in fact could be a domain name hijacking prior to the application for a certificate which results in the issuing of a valid SSL domain name server certificate to the wrong entity. One of the suggestions for addressing the domain name infrastructure integrity issue is for public keys to be registered at the same time as the domain name and then further communication with the domain name infrastructure be with digitally signed messages ... as part of the process for thwarting domain name hijacking. Note however, since the domain name infrastructure is the registration authority for the public key as well as the relying party receiving the signed messages certificates are redundant, superfulous, and extraneous even tho it still could be considered a (certificate-less) publick key infrastructure with significant administrative and management support. The other interesting aspect is that the existing domain name infrastructure is set up for (presumably) trusted, (near) real-time distribution (and updating) of almost any kind of information; not just the (nearly) trusted binding of domain name to IP-address. Given that public keys are also registered with domain names at the same time as domain name and ip-address then a trusted domain name infrastructure could be relied upon to implement a (certificate-less) near real-time public key infrastructure (with full administrative and management functions already in existance) aka the domain name infrastructure could optionally distribute public key in the same response that it distributes ip-address .. eliminating the requirement for a certificate-based PKI for trusted public key distribution. This is somewhat a catch-22 that one of the solutions to addressing a basic SSL domain name certificate integrity problem (i.e. a CA has a broken trust chain if there is an integrity issue with the authoritative agency responsible for the information that a certification authority must certificate) could also be the solution eliminating any requirement for SSL domain name certificates. As an aside, having the public key at the same time as the ip-address for setting up the base TCP session could also be used to simplify the normal SSL session setup (since there is no certificate distribution that has to occur). random additional discussion: http://www.garlic.com/~lynn/subtopic.html#sslcerts there is also the claim that 99.9 percent of client authentication in the internet world today is radius-based; typically userid/password (although radius supports multiple authentication processes specifiable at an individual userid/account level). There has been work done on an authentication process for radius involving digital signature where a public key is registered in place of a password. This would also represent a (certificate-less) public key infrastructure with full administrative and management support. random raidus discussion http://www.garlic.com/~lynn/subtopic.html#radius for pointer to radius standards documents: http://www.garlic.com/~lynn/rfcietff.htm click on Term (term-RFC#) and then click on RADIUS in the Acronym fastpath section remote authentication dial in user service (RADIUS ) see also authentication , network access server , network services 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 also of some interest are the AAA rfcs: Authentication, Authorization and Accounting see also accounting , authentication , authorization 3127 2989 2977 2906 2905 2904 2903 perry e. metzger [EMAIL PROTECTED] on 12/26/2001 3:45 pm wrote: HTTPS SSL does not use PKI. SSL at
Re: CFP: PKI research workshop
Nelson Minar wrote: Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this. I used to be puzzled by this. Then a couple of years ago I went through the process of getting a client-side certificate to access my student records at MIT. MIT is the only place I've ever seen to require client-side certs for authentication, bless 'em. It took me 30 minutes to establish a client side certificate, just so I could view a web page with my own data on it. *thirty minutes*. And I know a lot about cryptography. How would someone who'd never heard of a public key do? This was on Netscape 4.0 on Linux. Maybe MSIE things have improved since then, but I doubt it. (Anyone know?) I've never found it particularly hard to generate a client cert in either Netscape or IE - but the time consuming part is the meatspace component - verifying your identity to the CA/RA so they'll sign the certificate. Of course, going through all of this to access a single page is silly. The two useful aspect of client certs (IMNSHO) are firstly that they allow single sign-on with access control in a way that does not require all systems to communicate with some central authority and secondly they give a way to bind an identity (or simply a set of permissions/privileges/capabilities/whatevers) to a private key. Of course, if your threat model means you must check a certificate's validity immediately, then the first advantage is mostly gone. However, you almost always need the second property, AFAICS, to do anything useful with PKC. If you have some kind of entity that binds a private key to some other stuff, then that is a certificate, IMO. Equating certificates with X.509 is missing the point. As for the certificateless model - all this really does is move the binding from something you can carry around with you to something that has to be done by a central authority. It is not clear to me why this is such a marvellous improvement. Unless you happen to want to own the central authority, of course, which, unlike certificates and CAs, is far harder to replicate privately and therefore, presumably, potentially even more profitable than Verisign's cash cow. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
it isn't that you move it to a central authority you move it to an authority that typically is already established in association with authorization ... aka in normal business operation, a business relationship is established that typically consists of creating an account record that has various privileges associated with that account/entity. For authentication purposes a public key can be bound to that account and/or set of privileges. This goes on in the world today and would continue to regardless of whether x.509 identity certificates were issued or not. given that businesses have to play the registration function for authorization privileges ... aka normal procedure doesn't allow somebody to walk into a random bank and withdraw funds from a random account ... regardless of who they are ... aka indentity doesn't magically enable a person to withdraw funds from an arbritrary account ... ability to withdraw funds typically is a privilege associated with whether or not some entity is authorized to perform that function for a specific account. As such, the financial institution has to register lots of information for the account ... also registering a public key is consistent with the existing business processes, liability, administrative and management infrastructure. In effect, large numbers of business processes already exist for registration, administration, and management of authentication information and having a certificate in the loop doesn't eliminate those business processes (whether or not I had a certificate there still would have to be something registered that some attribute of me has authorization to do certain things). Doing business flow and informatioin management optimization just demonstrates that given existing business infrastructures for registration, administration and management which also includes certificates it is usually trivially possible to demonstrate that the actual certificates are redundant, superfulous and extraneous ... aka directly registering the public key and providing direct binding between the authentication process and the authorization process eliminating a possibly huge number of extraneous and unnecessary business entities and business processes associated with certificate-based operation. There doesn't have to be any single central authority in a certificateless model. There can be all sorts of authorities for all sorts of infomation which could be also hypothesized for a certificate-based certification and authentication model. However, the certificateless exercise typically trivially demonstrates that any certificate-based solution duplicates existing business processes which aren't going to be eliminated. Therefor, it is then possible to demonstrate business optimization where the duplicate (certificate) business processes can be eliminated as extraneous, redundant, and superfulous. [EMAIL PROTECTED] on 12/27/2001 7:16 am wrote: As for the certificateless model - all this really does is move the binding from something you can carry around with you to something that has to be done by a central authority. It is not clear to me why this is such a marvellous improvement. Unless you happen to want to own the central authority, of course, which, unlike certificates and CAs, is far harder to replicate privately and therefore, presumably, potentially even more profitable than Verisign's cash cow. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
As I never tire of saying, PKI is the ATM of security. Naah, it's the monorail/videophone/SST of security. Looks great at the World Fair, but a bit difficult to turn into a reality outside the fairgrounds. Peter (who would like to say that observation was original, but it was actually stolen from Scott Guthery). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Nelson Minar [EMAIL PROTECTED] writes: The thing that makes me the most sad is that the PKI situation only seems to be getting worse, not better. The reason for this is that as we work on PKI deployment, we discover more and more (previously unknown) problems which need to be solved. If you look at PKI in 1978 it was pretty simple (certificates in a public file), then in the 1980's it got more complex with directories and CRLs and whatnot, and after that an ongoing stream of further issues which need to be addressed were discovered as systems were finally deployed. It's just getting harder and harder as we discover more and more problems when we try and actually implement the thing. Even what we know now is only the tip of the iceberg compared to what we're going to discover further down the track, and that's only identifying the *problems* to be solved, not providing solutions. PKI is like an erection: The more you think about it, the harder it gets. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
It seems to me that a very similar argument can be made regarding the need (or lack there of) for a national identity card. Organizations that require biometric identity can simply record that information in their own databases. The business most widely cited as needing national ID cards, the airlines, already maintain elaborate customer databases for their frequent flyer programs. Adding biometrics, with mileage points or faster check-in as incentive, would be easy enough. Your frequent flyer application would authorize the airline to compare your identifying data with security databases at other airlines, credit bureaus, the government, etc. If photo matching software is unable to validate two photos of you from different databases, both would be displayed next time you check in. If the clerk decides they match, that would be recorded. If the discrepancy is major, you would be taken aside and the matter investigated. Over time, the confidence in any individual's record would grow as more use is made of it. There is still the problem of protecting the database from alteration, but that applies to whatever database would be used to issue national ID cards as well. Even if high speed data lines are not available at all gates, reservations are normally made well in advance, so a passenger list with biometrics could be prepared overnight and delivered to each gate in printed form (for photos) or on a CD-RW. Last minute reservations could be handled by slower data links or the maker would simply be subject to a higher level of scrutiny. Passport numbers could be requested at the time of an international reservation and checked with the issuing government well before flight. Government's that don't cooperate would have their citizens subject to additional scrutiny. During times of heightened alert, additional cross checking can be implemented. None of this is particularly hard and all the issues of of forged, revoked, stolen or cursorily examined ID cards go away. So do the issues of abuse where petty officials confiscate your ID card leaving you helpless. Arnold Reinhold At 8:22 AM -0700 12/27/01, [EMAIL PROTECTED] wrote: it isn't that you move it to a central authority you move it to an authority that typically is already established in association with authorization ... aka in normal business operation, a business relationship is established that typically consists of creating an account record that has various privileges associated with that account/entity. For authentication purposes a public key can be bound to that account and/or set of privileges. This goes on in the world today and would continue to regardless of whether x.509 identity certificates were issued or not. given that businesses have to play the registration function for authorization privileges ... aka normal procedure doesn't allow somebody to walk into a random bank and withdraw funds from a random account ... regardless of who they are ... aka indentity doesn't magically enable a person to withdraw funds from an arbritrary account ... ability to withdraw funds typically is a privilege associated with whether or not some entity is authorized to perform that function for a specific account. As such, the financial institution has to register lots of information for the account ... also registering a public key is consistent with the existing business processes, liability, administrative and management infrastructure. In effect, large numbers of business processes already exist for registration, administration, and management of authentication information and having a certificate in the loop doesn't eliminate those business processes (whether or not I had a certificate there still would have to be something registered that some attribute of me has authorization to do certain things). Doing business flow and informatioin management optimization just demonstrates that given existing business infrastructures for registration, administration and management which also includes certificates it is usually trivially possible to demonstrate that the actual certificates are redundant, superfulous and extraneous ... aka directly registering the public key and providing direct binding between the authentication process and the authorization process eliminating a possibly huge number of extraneous and unnecessary business entities and business processes associated with certificate-based operation. There doesn't have to be any single central authority in a certificateless model. There can be all sorts of authorities for all sorts of infomation which could be also hypothesized for a certificate-based certification and authentication model. However, the certificateless exercise typically trivially demonstrates that any certificate-based solution duplicates existing business processes which aren't going to be eliminated. Therefor, it is then possible to demonstrate business optimization
Re: CFP: PKI research workshop
As I never tire of saying, PKI is the ATM of security. Meaning that has a certain niche relevance, but is claimed by proponents to be the answer to every need, and is the current magic word for shaking the money tree. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Ray, if you look at PKI as a financial mechanism (like credit cards), then I see two major problems: 1. the PKI vendors aren't financial institutions, so they aren't in a position to assume risk and make money from that 2. the current PKI thinking (e.g., with rebuttable presumption of non-repudiation) is anti-consumer, when viewed as a financial mechanism, and I can't imagine that succeeding even if the vendors were banks. - Carl ++ |Carl Ellison Intel E: [EMAIL PROTECTED] | |2111 NE 25th Ave M/S JF3-212 T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-6225 | |PGP Key ID: 0xFE5AF240 C: +1-503-819-6618 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240| ++ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
note that the certificate-based PKI is an offline model it is the credit card model pre-1970. the certificate-based PKI tends to bear a lot of other resumblance to pre-1970 offline credit-card model the CRLs invention is very similar to the paper booklets that were mailed out to merchants every month of invalid credit card numbers (the credit-card industry however had a significant advantage having a very strong relying-party registration function so that there was high probability of relying-parties getting the paper booklets of invalid numbers). in the '70s, the credit card industry switched from an offline infrastructures (aka similar to the certificate-based PKIs which were effectively developed to address the offline email infrastructure of the early 1980s) to an online infrastructure ... where every transaction was executed online. A certificate-based PKI for credit cards would be like regressing 30 years to the offline infrastructure (although using more convoluted and complex technology). The issue is why would the payment card industry want to regress 30 years to an offline model with certificate-based PKI? The financial industry has passed an online payment definition that does use digital signature technology w/o all the complexity and short-comings of a certificate-based PKI (that would set-back/regress the infrastructure 30+ years to the offline model) which is X9.59. Baiscally X9.59 defines a retail payment object that is valid for ALL electronic online financial transactions (internet, non-internet, point-of-sale, debit, credit, ACH, etc) which basically requires a digital signature and does not require a certificate-based PKI. The simplest analogy is that digital signature technology upgrades the PIN-based infrastructure found in current debit transactions and expands it to all electronic financial transactions. There have been some financial pilots using certificate-based PKI operations but in all cases it is relatively trivial to show that the certificate is redundant, superfulous and extraneous in an online world. The certificates were effectively relying-party-only certificates (basically containing an account number and a public key) in part to meet liability and privacy requirements. Since only an account number was used and the transactions /or other operations were all online ... they all referenced the account in order to execute the requested operation. It is trivial to show that given online operation executioin (including things like logging in for vaious kinds of things related to online banking and/or other financial or securities industry transactions) that is superfulous to have the certificate. The certificate makes sense in an offline environment where there is no prior business relationship between the entities. Given online situations involving parties with prior relationships, certificates make no sense. misc. x9.59 references: http://www.garlic.com/~lynn/indec.html#x959 misc certificate-less digital signature references (including pointers to the NACHA/debit network implementation ... and a private key hardware token description allowing the same private/public key to be used in an arbritrary large number of different public operations): http://www.garlic.com/~lynn/index.html#aads random client digital signature authentication refs: http://www.garlic.com/~lynn/subtopic.html#radius misc. discussion of certificate-based SSL domain name operation: http://www.garlic.com/~lynn/subtopic.html#sslcerts ray dillinger [EMAIL PROTECTED] on 12/26/2001 12:03 pm wrote: Yep. So far, that's true. Financial stuff is the only killer app in sight for a PKI, and the financial services sector is conservative and heavily regulated. There is a substantial barrier to entry: just try to imagine running off a few thousand PKI-backed credit cards and going into business competing against mastercard/visa/amex. Vendor acceptance is slow and the regulatory hurdles are high. Odds are, however, that each and every one of them is going to want their own PKI -- where P stands for Private, or Proprietary, rather than Public. A Public Key Infrastructure happens when the chaotic situation which that brings about gets consolidated and standardized, so don't look for that for at least a decade. Basically we have no chance of getting a Public Key Infrastructure in place right now because we don't have enough different Private Key Infrastructures in place for it to have started to hurt yet. People won't go for the PKI until they are in some kind of pain that it relieves. And if financial services businesses are involved, they will do it in such a way that no PKI vendor ever makes a profit they could possibly have made themselves. Look for them to be buying regulations that say PKI is part of financial services and can only be provided by licensed financial services corporations sometime in the next few years. Like I said, don't get
Re: CFP: PKI research workshop
possibly not the ATM you were thinking of certificate-less digital signature authentication by NACHA/ATM/debit networks http://www.garlic.com/~lynn/index.html#aads specific web page: http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm financial industry standard for digital signature authenticated electronic payment transactions for all payments (x9.59): http://www.garlic.com/~lynn/index.html#x959 misc discussions regarding privacy and certificate-less digital signature authentication http://www.garlic.com/~lynn/subtopic.html#privacy matt crawford [EMAIL PROTECTED] on 12/26/2001 8:20 am wrote: As I never tire of saying, PKI is the ATM of security. Meaning that has a certain niche relevance, but is claimed by proponents to be the answer to every need, and is the current magic word for shaking the money tree. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
again, why would the financial industry be interested in regressing (at least) 30 years to a certificate-based offline model? they do authentication of transactions that they also need to do authorization for in a model that has prior business relationship between the parties. certificate-based PKI were targeted at offline email genre of the early '80s and analogous to the offline credit-card model pre-70s. in addition to the x9.59 for all electronic payment transactions ... it is possible to extend online authentication where the institution possibly isn't also responsible for the authorization (and/or access privileges) things like FAST projects in FSTC: http://www.fstc.org/projects/fastaggregation.cfm ray dillinger [EMAIL PROTECTED] on 12/26/2001 12:31 pm wrote: In fact, that may be exactly it. PKI, as espoused by vendors, once established, will become an indispensable monopoly, like ATT before the breakup. Investors love the fantasy of buying a kajillion shares for cheap today and then having them be shares in an indispensable monopoly next year, so they are inclined to believe. The problem is that none of the vendors are offering anything that someone who has significant volume (like a financial-services company might) cannot provide for themselves. The FS companies can easily wait to adopt, because the margins offered by PKI are fairly small and the initial investment required is fairly large. Perhaps the margins will remain too small until royalty payments can be eliminated entirely (until any patents expire) and the FS companies can roll their own. Whether or not the margins are too small, The FS companies can wait that long easily. But the PKI vendor cannot wait. S/he will be out of business in three or four years if nobody adopts. The patents will be for sale then much cheaper than the royalty payments s/he is offering, and the FS negotiator across the table knows it. The PKI vendor therefore is going to get the worst end of the deal every time s/he goes to financial services vendors, because s/he is not dealing from a position of strength, and had best learn the harsh lesson sooner rather than later. A PKI will happen, eventually, but nobody is going to get into a position where the financial-services sector depends on them and has to pay them. That's as fundamental in business as the second law of thermodynamics in physics, and chasing the dream of becoming an indispensable monopoly to the financial services sector promises to be as frustrating to the seekers as the quest for a perpetual motion device. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
Methinks you complain too much. PKI is in widespread use, it is just not that noticeable when you use it. This is how it should be. SSL is widely used to secure internet payment transactions. S/MIME use is significant and growing. The financial industry is not looking at offline PKI models in general. This is not surprising since they use very few offline systems. Hence certificate/CRL based models which were first promoted for use with email are tending to be replaced by online systems such as OCSP and ultimately XKMS which allows the certificate to be dispensed with entirely if required. What we are not seeing is demand for naming semantics of the form 'the person who fred call's jim'. As for what PKI vendors have been up to, the sucessful ones have been supporting private label certification hierarchies from the start. Phill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
on Wed, Dec 26, 2001 at 07:45:13AM -0800, Carl Ellison ([EMAIL PROTECTED]) wrote: Ray, if you look at PKI as a financial mechanism (like credit cards), then I see two major problems: 1.the PKI vendors aren't financial institutions, so they aren't in a position to assume risk and make money from that 2.the current PKI thinking (e.g., with rebuttable presumption of non-repudiation) is anti-consumer, when viewed as a financial mechanism, and I can't imagine that succeeding even if the vendors were banks. I disagree with this premise. I also see PKI being as strongly pro-vender. With consumers legally, and banks contractually, sheltered from the bulk of credit card fraud risks, the burden falls on merchants. I would expect that a merchant-based initiative to produce a non-refutable electronic payment system would see some favor. With current retail numbers in the toilet, any opportunity to shave losses should meet some favor. A number of merchants have their own credit payment systems, and might be the source of such an initiative. The next battleground becomes rights to public privacy in the face of such systems. I'm curious as to systems which might use various forms of one-time keys or tokens to validate transactions, there was some discussion of this 1-2 years back, with a system proposed by AmEx IIRC, but little followup. Peace. -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html msg01333/pgp0.pgp Description: PGP signature
Re: CFP: PKI research workshop
Phillip Hallam-Baker [EMAIL PROTECTED] writes: Methinks you complain too much. PKI is in widespread use, it is just not that noticeable when you use it. This is how it should be. SSL is widely used to secure internet payment transactions. HTTPS SSL does not use PKI. SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. (If you don't believe me about the assurance levels, read a Verisign cert practice statement sometime.) Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this. Were it not for historical accident no one would care about PKI in this context. S/MIME use is significant and growing. I get PGP encrypted mail a few times a week. I've never received a request from any counterparty to set myself up to receive S/MIME. Your mileage may vary. The financial industry is not looking at offline PKI models in general. When I was still doing security consulting, nearly every firm I worked for had installed Entrust or something similar -- and none of them used the systems for anything. PKI and the Emperor's New Clothes have a bunch in common. As for what PKI vendors have been up to, the sucessful ones have been supporting private label certification hierarchies from the start. The PKI vendors are, I think, largely surprised by what has happened. They were expecting things like lots of mutual authentication using PKI to be in place, and in fact, there's almost none in use at all. I think many of the PKI vendors haven't been doing too well -- some of them that I used to have dealings with barely exist any longer. The one business that seems to make money is charging a toll for running an e-commerce site. I wonder who they might be. Of course, none of this should be surprising in the least. Commerce and the PKI model have nearly nothing to do with each other. Some of us were writing about this years ago. -- Perry E. Metzger[EMAIL PROTECTED] -- NetBSD Development, Support CDs. http://www.wasabisystems.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
HTTPS SSL does not use PKI. SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. To be fair, Verisign *is* a PKI. It's not the one a lot of us want, but it is in wide usage. Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this. I used to be puzzled by this. Then a couple of years ago I went through the process of getting a client-side certificate to access my student records at MIT. MIT is the only place I've ever seen to require client-side certs for authentication, bless 'em. It took me 30 minutes to establish a client side certificate, just so I could view a web page with my own data on it. *thirty minutes*. And I know a lot about cryptography. How would someone who'd never heard of a public key do? This was on Netscape 4.0 on Linux. Maybe MSIE things have improved since then, but I doubt it. (Anyone know?) PKI and the Emperor's New Clothes have a bunch in common. It's very important to look at this truth and think about why. Part of it is usability: Netscape could have made it easier for me. But a lot of it is design. PKI is complicated: chains of authority are complicated to understand, security technology is awkward for naive users to use properly, and trying to do anything with revocation or real time properties is a nightmare. The thing that makes me the most sad is that the PKI situation only seems to be getting worse, not better. Now it looks like it's going to be Passport that cracks the nut of client authentication, not PKI. And the spoils go to the victor. Three years from now when you're paying a monopolist a monthly fee for the priviledge of verifying your identity, think hard about why. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
PHB: PKI is in widespread use, it is just not that noticeable when you use it. This is how it should be. SSL is widely used to secure internet payment transactions. PM: HTTPS SSL does not use PKI. Could someone define PKI (beyond just what it stands for, Public Key Infrastructure)? It looks like you are all talking past each other by using the term to mean different things. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
