Re: Maybe It's Snake Oil All the Way Down
Ian Grigg <iang@systemics.com> writes:
It's also very much oriented to x.509 and similar certificate/PKI models, which means it is difficult to use in web of trust (I know this because we started on the path of adding web of trust and text signing features to x.509 before going back to OpenPGP), financial and nymous applications whereby trust is bootstrapped a different way.
That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft that uses shared secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2.
Has anyone read Ferguson and Schneier's _Practical Cryptography_ ? Does it address this issue of how an outsider decides how to "make or buy"? I just read the reviews on Amazon, they are ... entertaining!
They spend a nontrivial portion of the book reinventing SSL/SSHv2. I guess they lean towards the roll-your-own side of the argument :-). I'm firmly in the opposite camp (see "Lessons Learned in Implementing and Deploying Crypto Software", links off my home page at http://www.cs.auckland.ac.nz/~pgut001/). I think that providing an abstract description of a fairly complex security protocol *in a book targeted at security novices* and then hoping that they manage to implement it correctly is asking for trouble. OTOH it's fun going through the thought processes involved in designing the protocol. I just wish they'd applied the process to SSL or SSHv2 instead, so that at the end of it they could tell the reader to go out and grab an implementation that someone else has got right for them. Peter. [0] The vendor of one widely-used MTA once told me that 90% of the certs they saw used in STARTTLS applications were non-big name CA-issued ones (self- signed, etc etc).
That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft
On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote: that uses
shared secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2.
the pk-init draft for kerberos allows public keys .... allowing both cert & cert-less implementation <blatant aads-promotion> the scenario allows for public key registration in lieu of shared secret registration. the scenario is that r/o access, divulging, sniffing, etc doesn't result in compromise. in the token form .... http://www.garlic.com/~lynn/index.html#aadsstraw http://www.asuretee.com/ the key-pair is gen'ed in the chip and never leaves the chip. as part of 3-factor authentication * something you have * something you know * something you are the chip in the token purely provides "something you have" authentication ... and the digital signature done by the token is purely to prove that you have that particular token. It doesn't prove who you are, it just proves that you have a specific (extremely difficult to counterfeit) token as part of "something you have" authentication. if the token is augmented with a pin/password for its correct operation, then there can be 2-factor authentication. It doesn't involved shared-secrets since the pin/password is purely between the person and the hardware token. The business process validates that the token is of the type requiring PIN and/or biometric for correct operation. The ecdsa digital signature authentication protocol for kerberos, radius, x9.59 for all retail financial transactions, or ssh can be identical regardless of the integrity level. The ecdsa digital signature authentication protocol can be ubiquitous regardless of the authentication integrity level required. The business process to meet integrity requirements then can require sofware key-pair or hardware token key-pair, the level of integrity of the hardware token, and/or the operational characteristics of the hardware token (no-pin, pin, biometrics, etc) w/o changing the protocol. If the protocol is independent of the business process integrity issue then either the business and/or the end-user may be able to having personal choice about the level of integrity required. Furthermore, the person might even have personal choice whether they need a unique token per security environment, a single token for all security environment, and/or a small number of tokens selectively applied to different security environments the digital signature has nothing at all to do directly with the person, it is purely related to demonstrating the possession of the token (as part of something you have authentication) and possibly the integrity level of the token. The issue of the authentication protocol is getting the bits and bytes for transmission correct but doesn't normally say what it means ... i.e. secret, shared-secret, one factor authentication, two-factor authentication, something you have authentication, something you know authentication, etc. ... although frequently the protocol is envisioned to be a specific implementation of a specific kind of authentication and trust/integrity level. recent token discussions http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH? http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH? http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation older token discussions http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001g.html#1 distributed authentication http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure? http://www.garlic.com/~lynn/2001k.html#61 I-net banking security http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ? http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites? http://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government </blatent aads promotion> -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
--
That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft that uses shared secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2.
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start? What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache. As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Y/QLPHyeZqXrSgYZI9nQsjsk7krbgSGfCZ0BLpOt 4gqWFWtV3GiEwWupSGyR895BQo0u2e4MmlgtpP/po
"James A. Donald" <jamesd@echeque.com> writes:
That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft that uses shared secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2.
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache. http://www.modssl.org/docs/2.8/ssl_howto.html#auth-simple
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?
The issue is where does the authentication material come from. <blatant aads promotion> Basically, certificates were solution targeted for offline email from the early '80s. you dail-up, connect, exchange email, hang-up. then you read. some random person that you never, ever dealt with before sends you something. they claim to be somebody .... the certificate is signed by somebody you trust .... is offered as proof that they are who they claimed to be. the other approach in the online world &/or with previous relations, is have a table of authentication material. the payment (debit/credit) card world went from non-electronic, offline to electronic and online (and skipped the step altogether that certificates represent ... the electornic and offline). note that even the certificate-based infrastructure are dependent on this method .... basically the certificate-enabled infrastructures have local table of "CA" public keys (i.e. those public keys that they've previously decided to trust) ... then certificates are validated with "CA" public keys and the current message/document is validate with public key from certificate. The primary difference between cert-based infrastructure and certless-based infrastructure is that the cert-based infrastructure there CAs have the database of all public keys and create these small R/O copies of their database records called certificates and spray them all over for use in offline environments. Then relying parties just have abbreviated CA-only public key tables and can't access the full tables maintained at the CAs. In the certless-based infrastructure the relying parties either maintain their own full tables of all public keys and/or have direct online access to the full tables. There is no need for these little R/O, static, stale, redundant and superfluous copies of somebody else offline database entry (called certificates) since there can be direct, online access to the original copy. generalized case can be hooking the web server to either radius or kerberos for handling the authentication process. both radius and kerberos support shared-secrets recorded in database as authentication. the radius example at http://www.asuretee.com/ shows example of radius recording public key in lieu of shared-secret and performing ecdsa digital signature authentication. pkinit for kerberos also allows for public key recorded in lieu of shared-secret and digital signature authentication. misc. radius public key authentication posts http://www.garlic.com/subpubkey.html#radius misc. kerberos public key authentication pots http://www.garlic.com/subpubkey.html#kerberos futher discussion specifically regarding static, stale, redundant, superfluous certificates. http://www.garlic.com/~lynn/subpubkey.html#rpo slightly related discussions regarding SSL merchant comfort certificates: http://www.garlic.com/~lynn/subpubkey.html#sslcerts </blatant aads promotion> -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
You must not have looked very hard. :) I would start by taking Apache, openssl, and the mod_ssl package. For example, at http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 we see the question "How can I authenticate clients based on certificates when I know all my clients?" and it's answer. Similar questions are also answered. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
some generic reasons for hooking radius (or one of the AAA technologies) into your webserver for authentication are: 1) supports a variety of authentication mechanisms on an account by account basis. day one, none of the users actually need to see any difference (single administrative interface supporting all the client authentication options that might be in use). existing userid/password, challenge/response and in the referenced asuretee url, ecdsa digital signature. 2) single administrative interface for both client authentication options as well as all of their authorization and privilege options. 3) client database is accessable in real-time by the webserver, real-time updates can occur to both authentication information as well as authorization, permission and privilege information using single consistent administrative operation 4) there is no disconnect between client administration and static, stale, redundant and superfluous certificates that are a subset of a r/o administrative database entry. (RADIUS) Updates can take place in real time and immediately reflected. The certificate story (as mentioned previously, created for offline, disconnected environment) basically would do something like a) invalidate the old certificate, b) issue new CRLs, c) possibly update a OCSP LDAP, d) update the master database permissions entry for that client, e) generate a certificate that represents a subset of the master information, f) distribute it to the client and f) then have the client install the new certificate. This of course becomes unnecessary if the certificate doesn't actually contain any information and the webserver accesses the authorization and permissions from an online database. However, as has repeatedly been pointed out before, if the certificate doesn't contain any information and the webserver is accessing an online database for authorizations and permissions ... then the webserver can access the online database for the authentication material also. The certificate then is static, stale, redundant and superfluous and you are back to a single online, real-time comprehensive administrative facility (like radius) that supports client/account specifics for authentication, authorization, permissions, accounting, privileges, etc. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
On Tue, Jun 03, 2003 at 03:04:54PM -0700, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
Start by looking up the OpenSSL wrappers for your favourite high-level "scripting" language. There exists wrappers for Perl, Python, tcl, Ruby, etc. Some popular languages have several. Many of these programming language environments come with HTTP server implementations, and many of the OpenSSL wrappers hook into said HTTP server code to add HTTPS, and a number demonstrate how to do client-side certificates. My M2Crypto adds HTTPS to the popular web application server Zope (www.zope.org) and has some code to hook client-side certificates into Zope's own user authentication machinery. (By faking HTTP basic authentication, just like Apache's SSL do.) Once you have that, you can choose to serve whatever content you want.
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him..
It seems HMAC'ing cookies are getting popular for this purpose. OpenACS, another popular web application server uses this: http://openacs.org/doc/openacs-4/security-design.html My Python crypto kit has an implementation of the scheme described here: http://www.pdos.lcs.mit.edu/cookies/pubs/webauth.html I'll be interested to hear this list's view on such schemes. From my app-plumber's perspective, such a technique for is good enough provided it is 'secure' enough. People understand passwords. Private keys, certificates, smart cards, etc., are more difficult. (I recall a paper on PGP UI useability testing called "Why Johnny cannot encrypt" or something like that.)
As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?
Actually, this is the crypto-wielding-open-source-hacker-wannabe's wet dream: So what you need now to track (or generate strong) passwords is a GUI "password safe"! (Like the one offered on (the old?) Counterpane site.) Again, Perl, Python, Ruby, yada yada, you name it, people are going to implement them for free. ;-) Especially since there are usually 3-5 GUI toolkits and 2-4 database toolkits for these language environments. Enough combinations to suit everyone. -- Ng Pheng Siong <ngps@netmemetic.com> http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
-- On 3 Jun 2003 at 15:04, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?
Or to say the same thing in different words -- why can't HTTPS be more like SSH? Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG QtiFX0Q654gHh54NAMlLGE1FGDveixyzL0ZnAOVS 4hprBkT1zeYk/HdBOXiquwvz5vLUwF/21wW1Jf411 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
"James A. Donald" <jamesd@echeque.com> writes:
-- On 3 Jun 2003 at 15:04, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?
Or to say the same thing in different words -- why can't HTTPS be more like SSH? Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com?
Because HTTPS is designed to let you talk to people you've never talked before, which is an inherently harder problem than allowing you to talk to people you have. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
-- James A. Donald
Or to say the same thing in different words -- why can't HTTPS be more like SSH? Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com?
Eric Rescorla
Because HTTPS is designed to let you talk to people you've never talked before, which is an inherently harder problem than allowing you to talk to people you have.
In attempting to solve the hard problem, it fails to make provision for solving the easy problem. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bZy6QJLI0fL6IOhhS8lxNx/EUctBs0cj1se8YRt5 4LvAbyVinp/3mbNkE+8/qx6UYDSxykTEFMpTXzsoD
In attempting to solve the hard problem, it fails to make provision for solving the easy problem.
That's a deployment issue, not a technical issue. D-H key exchange, for example, would be just fine. It just so happens that the SSL creators had a particular business goal in mind: e-commerce, with a "certificate" re-assuring the nervous customer that they were handing their credit card to jcrew.com, not, jscrew.com. Yes, SSL was invented to solve a particular problem. They did a reasonable job at it. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
"James A. Donald" <jamesd@echeque.com> writes:
-- James A. Donald
Or to say the same thing in different words -- why can't HTTPS be more like SSH? Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com?
Eric Rescorla
Because HTTPS is designed to let you talk to people you've never talked before, which is an inherently harder problem than allowing you to talk to people you have.
In attempting to solve the hard problem, it fails to make provision for solving the easy problem.
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- James A. Donald
Or to say the same thing in different words -- why can't HTTPS be more like SSH? Why are we seeing a snow storm of scam mails trying to get us to login to e-g0ld.com?
Eric Rescorla
Because HTTPS is designed to let you talk to people you've never talked before, which is an inherently harder problem than allowing you to talk to people you have.
James A. Donald:
In attempting to solve the hard problem, it fails to make provision for solving the easy problem.
Eric Rescorla
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful.
Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /UOLlqGTeq9SAB5W/aJJuwULFBNMCVzKJnIRlhES 48E3I0Yo+68OTvTwztxirTXc41yFVicJtskuBB/dU
"James A. Donald" <jamesd@echeque.com> writes:
Eric Rescorla
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful.
Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers
The only solutions to that problem involve getting rid of passwords and credit card numbers. SSL does that job about as well as we know how. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
At 10:09 PM 6/4/2003, James A. Donald wrote:
Eric Rescorla
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful.
Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers
I don't think this problem is easier to solve (or at least I sure don't know how to solve it). It seems to me that you could tell a user every time they go to a new site that it's a new site, and hope that users would recognize that e-g0ld.com shouldn't be "new", since they've been there before. However, people go to a large enough number of sites that they'd be seeing the "new" alert all the time, which leads me to believe that it wouldn't be taken seriously. Fundamentally, making sure that people's perception of the identity of a web site matches the true identity of the web site has a technical component that is, at most, a small fraction of the problem and solution. Most of it is the social question of what it means for the identity to match and the UI problem of determining the user's intent (hard one, that), and/or allowing the user to easily and reliably match their intent against the "reality" of the true "identity". Any problem that has as a component the fact that the glyphs for "lower-case L" and "one" look pretty similar isn't going to be easy to solve technologically. - Tim
-- James A. Donald:
Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers
On 6 Jun 2003 at 15:04, Tim Dierks wrote:
I don't think this problem is easier to solve (or at least I sure don't know how to solve it).
It is a hard problem with many well known solutions, none of which have to my knowledge been implemented in HTTPS. For example one can use SPEKE, in which case setting up the account involves sharing (or issuing) a password, but logging in to the account does not require one to reveal the password to the site where one is logging in. In this case the fake website would gain no useful information by luring the user to login to it. The most HTTPS like solution would be to generate a keyfile containing a self signed private key on one's computer, and whenever one hit the website, it would do the HTTPS handshake to log you in to that website's account for the public key corresponding to your private key, however HTTPS does not seem to directly support this model. In this case the bogus web site could log you in, but this would not leak any information that would enable the operators of the bogus web site to login to the real web site. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /JhekrYM+sQCMQKXhiWzhB3RnOv6PZROgxYwprXj 4LHJfuGlcn7fO4tcfo20/t0cdEy/HyK++XiBVvMFy --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote:
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful.
there are actually two scenarios .... one is to pre-cache it (so that its transmission never actually has to happen) and the other is to compress it to zero bytes. detailed discussion of certificate pre-caching and certificate zero byte compression: http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 the typical use for HTTPS for e-commerce is to hide the account number on its way to the financial institution. for the most part the merchant is primarily interested in the response from the consumer's financial institution on whether or not the merchant gets paid. If it weren't for the associated business processes, the merchant could get by with never knowing anything at all about the consumer (the merchant just passes the account number on ... and gets back what they are really interested in .... the notification from the bank that they will get paid). So a HTTPS type solution is that the consumer pre-caches their bank's certificate (when they establish a bank account). .... and they transmit the account number "hidden" using the bank's public key. This happens to pass thru the merchants processing .... but for purposes of the authorization, the merchant never really has to see it. The protocol would require minor issues of replay attacks .... and be able to be done in a single round trip .... w/o all the SSL protocol chatter. Actually, is isn't so much pre-caching their bank's certificate .... as loading their bank's public key into a table .... analogous to the way CA public keys are loading into tables (aka using out-of-band processing .... the convention that they may be self-signed and encoded in a certificate format is an anomoly of available software and in no way implies a PKI). The primary purpose of HTTPS hasn't been to have a secure channel with the merchant, the primary purpose of the HTTPS is to try and hide the consumer's account number as it makes its way to the consumer's financial institution. The other solution is the X9.59 standard (preserve the integrity of the financial infrastructure for all electronic retail payments, not just internet, not just POS, not just credit, ALL; credit, debit, stored value, etc) that creates authenticated transactions and account numbers that can only be used in authenticated transaction. The consumer's public key is registered in their bank account (out of band process, again no PKI). X9.59 transactions are signed and transmitted. Since the account number can only be used in authenticated transactions .... it changes from needing encryption to hide the value as part of a shared-secret paradigm to purely a paradigm that supports integrity and authentication. As in the above, scenario, the merchant passes the value thru on its way to the consumer's financial institution; and is focused on getting the approved/disapproved answer back about whether they will be paid. As in the bank HTTPS scenario where the bank's pubilc key is pre-cached at the consumer, the pre-caching of the consumer's public key is pre-cached at the bank .... involves no PKI business processes (although their may be some similarities that the transport of the public key involves encoding in a certificate defined format). misc. x9.59 refs: http://www.garlic.com/~lynn/index.html#x959 Both pre-caching solutions are between the business entities that are directly involved; the consumer and the consumer's financial institution based on having an established business relationship. The invention of PKI was primarily to address the issue of an event between two parties that had no prior business relationship and possibly weren't going to have any future business relationship and that they would conclude their business relying on some mutual trust in the integrity of a 3rd party w/o actually having to resort to an online environment. The e-commerce scenario is that there is real-time, online transaction with the trusted 3rd party (the consumer's financial institution) involving prior business relationship. This negates the basic original assumptions about the environment that PKIs are targeted at addressing. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
participants (7)
-
Anne & Lynn Wheeler -
Eric Rescorla -
James A. Donald -
Ng Pheng Siong -
pgut001＠cs.auckland.ac.nz -
Rich Salz -
Tim Dierks