"Anders Rundgren" <[EMAIL PROTECTED]> writes: > Mutual authentication is not rocket science but in order to work you > need OTPs or PKI. That is, it is time to let passwords RIP.
for the original stuff that was going to turn into this stuff called e-commerce ... we specified mutual authentication SSL ... before there was a thing in SSL for mutual authentication. however, it is evident that the design point for certificates & PKI based infrastructure is for stangers that have never communicated before. in this original mutual authentication deployment that we had specified ... it was between (merchant) webservers and the payment gateway. however, it quickly became evidently clear that there had to be prior contract between merchant webservers and their respective payment gateway. that the use of certificates in the SSL establishment was purely an artificial artifact of the existing SSL implementation. in actual fact, before the SSL sesssion was ever established ... the merchant webserver had a preconfigured set of data on what payment gateway they were going to contact and the payment gateways had preconfigured information on which merchants they would process for. Once the SSL session was established ... this preconfigured authentication was exercised w/o regard for any certificates. The use of certificates as authentication mechanism was purely a facade and an artificial artificate of the use of the existing SSL implemenation ... and in no ways represented the real (online) business authentication process. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 relying party, business parties have well established processes for maintaining information about their business relationships (some of this well established business relationship processes have evolved over hundreds of years). passwords are an authentication technology that have been managed using these relationship business management processes. it is possible to use the existing business relationship processes for managing other kinds of authentication material, including public keys. certificates are not intrinsicly a substitute for replacing all of the existing, well established, business relationship processes, nor are they a mandatory requirement as the only means of managing public key authentication material in well-established business relationships. the design point for PKI and certificates were the offline email paradigm of the early 80s, where a recipient would dial their (electronic) postoffice, exchange email, and then hangup. The recipient (relying party) was then possibly faced with processing first time email with a total stranger. the role of the certificate was analogous to the letters of credit from the sailing ship days, the relying party lacking any prior information of their own regarding the stranger and/or any timely, direct access to a certifying authority. this is the analogy to the early days of the payment card industry, where the plastic card was the credential and their were weekly mailed booklets to every merchant (relying party) of the list of revoked credentials. in the 70s, the payment card industry quickly moved into the modern, online world of real-time transactions (even between relying parties that were strangers that never had any prior contact). in the mid-90s when the suggestions were made that the payment card industry could move into modern times by converting to (offline, stale, static) certificates ... my observation that moving to certificates would actually represent regressing 30 years to an offline model ... rather than the real, modern, online model that they had been using for over 20 years. It is perfectly possible to take well established business processes used for managing relationships ... and "RIP" shared-secret authentication technology ... but substituting public key registration in lieu of shared-secret (pin/password) registration. businesses are not likely to regress to stale, static certificates for the management of timely and/or aggregated information ... like current account balance. From there is trivial step-by-step process to proove that stale, static certificates are redundant and superfluous between relying parties that have existing business relationships. http://www.garlic.com/~lynn/subpubkey.html#certless the original pk-init draft standard for kerberos specified only certificateless management of public keys, treating public keys as authentication material in lieu of shared-secrets and leveraging the existing extensive online management of roles and permissions ... that are typically implicit once authentication has been performed aka it is not usual that authentication is performed just for the sake of performing authentication acts ... authentication is normally performed within the context of permitting specific set of permissions (in the financial world, some of these permissions can be related to real-time, aggregated information like current account balance) http://www.garlic.com/~lynn/subpubkey.html#kerberos similarly it is possible to take another prevelant relationship management infrastructure, RADIUS and substitute digital signatures and the registration of public keys in lieu of shared-secrets ... and maximize the real-time, online management and administration of authentication and permissions within a synergistic whole environment. http://www.garlic.com/~lynn/subpubkey.html#radius in any sort of value infrastructure, if it is perceived advantageous to have real-time management, admnistration and access to permissions, authorization and other kinds of authentication information ... then in such an environment, it would seem not only redundant and superfluous but also extremely archaic to rely on the offline certificate paradigm designed for first-time communication between total strangers. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
