Re: Historical PKI resources
as an aside ... note X9.59 which can be implemented with public/private key digital signature ... but doesn't dictate certificates (it is possible to implement with or without certificates; x.509 or not). W/o certificates, do public key management using existing business processes in place for passwords and PINs ... i.e. in conjunction with the database/file that is also referenced for authorization (either logging-on or financial transactions). random refs: http://www.garlic.com/~lynn/ from x9a10 mailing list The X9.59 DSTU period starts Feb. 1, 2001 and runs through Jan. 31, 2003 The X9.59 DSTU standards document should appear in the next standards publication catalogue: DSTU X9.59-2001, Electronic Commerce For the Financial Services Industry: Account-Based Secure Payment Objects X9.59 defines a secure payment object for use in authenticated financial transactions. It relies on existing X9F security standards for payment object authentication. It supports secure payments involving virtual (e.g. Internet) or face-to-face transactions. It applies to card-based (e.g. smart card) financial transactions as well as other forms of electronic financial transactions (e.g. e-check). Rich Salz [EMAIL PROTECTED] on 01/08/2001 05:39:22 PM To: [EMAIL PROTECTED] cc:(bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Historical PKI resources Here's the BibTeX entry for the paper that apparently "started it all".. The D-H paper is the public start of public-key crypto. The scientific American article by Gardner explained, pre-patent-issuance, RSA to the world. The start of PKI is an MIT Master's Thesis that created certificates. Sorry, no references to any of the above. Should not be hard to find. The adoption by X.509 for use as authentication in X.500 got us common technology, and is probably the only reason anyone will ever have to learn ASN.1 and DER. :) The old IETF PEM project gave us "---BEGIN" lines :) and showed empirically that global X.500 deployment is a non-starter. RSA's version, which became the IETF's S/MIME showed how to do it practically. I'll stop now before I get too cynical. :) /r$
Re: Historical PKI resources
the x9.59 standard is authentication as well as certificate neurtral. aads is pki no certificate ... i.e. it has a public key infrastructure with respect to public key management ... it just that its public key management attempts to take advantage of extensive existing "binding" business processes rather than inventing new ones. Now it may not be PKI, for PKI==X.509, but it is not "no infrastructure" (although they have been some claims that no "new" infrastructure is equated to "no infrastructure", aka existing password, PIN, mother-maiden-name, SSN, etc infrastructures don't actually exist). Rich Salz [EMAIL PROTECTED] on 01/09/2001 04:20:44 PM To: Lynn Wheeler/CA/FDMS/FDC@FDC cc: [EMAIL PROTECTED] Subject: Re: Historical PKI resources Well gee, thanks I guess, but since your baby is explicitly PK no I, it's pretty irrelevant, no? (Anyone else reminded of the old turk/armenian 'bot on Usenet? :) /r$
Re: A proposal for secure videoconferencing and video messaging over the Internet
we've had some of this discussion related to X9.59, namely that SSL verifies that the URL used and the certificate DNS info somewhat correspond. one problem is that many people don't necessarily arrive at a web site by actually typing the URL ... so provided URLs are one method of attack. The other is that certificate DNS information is typically verified by the certification authority contacting the DNS authority. Issues with DNS hijacking (i do dns hijack of xyz.com and then apply for certificate for xyz.com) and other exploits can be addressed with DNS public-key (aka reliable DNS infrastructure) which could make SSL certificates superfulous and redundant (i.e. one explaination is that SSL certificates exist because DNS is unreliable ... but since the certification is dependent on reliable DNS ... and a reliable DNS can be achieved with addition of public keys to the DNS information ... then it becames possible ot obtain public keys directly from the reliable DNS authority at the same time the other DNS information is obtained). the other part, is X9.59 requires that electronic payments transactions are electronically signed so only a specific payment might be subverted (supplying the wrong "pay-to" value) ... but additional payments could not be done with the information. Note however, the wrong "pay-to" value still needs to be a valid merchant identifiier in the payment infrastructure. The issue then becomes that the URL was supplied to the browser by a trusted method a reliable DNS is available with some sort of public key authentication (whether with public key directly from reliable DNS or circuitous route via a certificate which came from a certification authority which verified with a reliable DNS). misc. URLs: http://www.garlic.com/~lynn/aepay4.htm http://www.garlic.com/~lynn/ there are still some misc.; issues where the wrong "pay-to" field is supplied for a signed payment transaction (say a hacked web site). pieces for this opportunity include are at the international/iso level for a global merchant identifier (effectively a "pay-to" value). A trade-group could be setup that provided a merchant-id/publickey binding. Even simpler yet, since a reliable DNS is already a requirement, it would be possible to register both a public key (to address issues like DNS hijacking) and a merchant-id. The DNS information, merchant public key, and optional merchant-id (i.e. "pay-to" in a payment transaction) could then be provided as part of a standard DNS operation (further illustrating certificates as being superfulous and redundant in AADS-like public key environments). There are still some open issues regarding trusted path for supplying URL information and trusted browsers. Obviously trusted browswer can include things like does the transaction the user "sees" being the same as the transaction the user authorizes/signs but then even simple aspects of existing SSL are also dependent on trusted browser (i.e. the browser actually checks for valid binding, sets up a private SSL session, etc). To be fair, the sort of attack I described could work against SSL too. Certificates can confirm that www.example.com is who you are contacting, but certificates can't stop them from making their web site look just like www.example.net's and duping people into giving payment information to the wrong people. I think it would work especially well against a videoconferencing system though, because there is a certain trust inherent in face-to-face communications.
Re: Financial Standards Work group?
of course there is an ANSI Financial Standards body (X9) which is also chair of the ISO Financial Standards group. The electronic commerce payments working group (X9A10) has a draft standard for all electronic retail payments (debit, credit, pre-paid, electronic cash, etc) .. X9.59. misc. ref http://www.x9.org/ http://www.x9.org/main_organization.html http://www.x9.org/subcomms/x9a/general/public/general.html http://www.tc68.org/ http://www.x9.org/n20.html http://www.garlic.com/~lynn/ http://www.garlic.com/~lynn/99.html#224 http://www.garlic.com/~lynn/8583flow.htm http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt of course my rfc index is also at: http://www.garlic.com/~lynn/rfcietff.htm as well as ietf, payments, security, X9F, and financial glossaries
Re: Smartcard anonymity patents
current magstripe cards in US have names ... whether they are used or not ... allow relying party to cross-check name on card with forms of identification hopefully containing the same name. One economic model has chipcards in europe for offline transactions as being more cost effective ... versus magstripe in US doing online transactions ... i.e. telco cost difference in europe vis-a-vis US offset the cost difference between chipcards and magstripe cards. However, much of the world is transitioning to cost-effective online infrastructure ... changing some of the chip/telco cost tradeoffs that had been made in the past. The play that chipcards do have (even in the face of declining online costs) is 1) chip costs decreasing and 2) migration to more more non-face-to-face. electronic transactions. chipcards can provide a higher level of integrity and lower risk fraud compared to magstripe (even in online transactions ... and especially in non-face-to-face online). The cost/benefit play for chips in such an environment is the increased cost of chips vis-a-vis any reduced fraud risk from using chipcards (compared to existing magstripe fraud risk). It is possible in X9.59 digitally signed financial transactions ... to enhance privacy by removing the requirement for name/address/etc in authenticating the transaction ... but neutral from the standpoint of anonymity; i.e. the rest of the infrastructure business process determines whether the overall transaction is anonymous (body of the transaction doesn't contain identification information ... but the business processes could associate identity as part of processing the transaction). In a payment card scenario ... X9.59 would provide a tight authenticating binding between the payment transaction and the account; whether or not the bank provides a binding between the account and a person becomes a business process outside of authenticating the transaction. The identical transaction protocol works also in the Business-Employee scenario ... there can be a tight binding between a transaction something like an employee serial number. Then it is up to the business what processes are used for doing a tight between the employee serial number and the employee.
Re: Killer PKI Applications
your comments don't appear to be inconsistent with Jane Winn's writings on PKIs for instance her paper:: Hedgehog and Fox: PKI and Plublic Private Sector Risk Management The Hedgehog and the Fox: Distinguishing Public and Private Sector Approaches to Managing Risk for Internet Transactions, 51 ABA Administrative Law Review 955 (1999) This article argues that much recent and proposed electronic commerce legislation is based on flawed assumptions regarding risk management and the practical utility of current electronic commerce technologies. Such flawed legislation would produce a loss allocation system that would undermine incentives that currently exist to improve the technological infrastructure of Internet commerce. This paper was presented at a conference at American University in March 1999. http://www.smu.edu/~jwinn/hedgehogfox.htm or other papers at her site: http://www.smu.edu/~jwinn/ Greg Broiles [EMAIL PROTECTED] on 01/12/2000 01:47:04 AM To: Lynn Wheeler/CA/FDMS/FDC@FDC, "Bill la Forge" [EMAIL PROTECTED] cc: "bram" [EMAIL PROTECTED], "Peter Cassidy" [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications . While this would certainly be an interesting goal to achieve, I think it's worth remembering that current software industry practice is for the software publishers themselves to disclaim all or almost all warranties regarding the performance of their software or its lack of errors .. so you're asking CA's to guarantee something that publishers themselves don't, at present.
Re: Killer PKI Applications
digital signature enhanced radius (for ISP access authentication, i.e. replacing the password with public key in the authentication database and replacing the password with digital signature on authentication transactions) and in-coming address spoof filtering at ISPs (similar to intranet address spoof filtering for packets coming in from the internet, the ISPs would do address spoof filtering on packets coming into the internet from their customers) would go a long way for addressing a lot attacks (w/o requiring PKI). then for things like denial-of-service attacks (w/o address spoofing) ... account-based infrastructures would still use account-based public key transactions. In the case of boundary pre-filtering for things like denial-of-service attacks ... there is still trade-off with ASN.1 decoding public key ops that are still computationally intensive ... can be greater than TPC-C (for most of the current e-commerce transactions there would still have account-based authentication processing ... boundary pre-filtering represents duplication of effort could lead to faster resource exhaustion). It is likely then that a lot of the non-addresses-spoofed attacks would be from compromised machines (given ISP authentication incoming packet address spoof filtering by ISPs). Part of the issue is that almost all current e-commerce is transactional account-based paradigm (because of requirements for information timeleness and/or information aggregation). Part of the PKI design point/advantage is targeted to peer-to-peer, anarchy, offline, lacking any account infrastructures. Work on compromised machine exploits still has quite of bit of work to do and PKI might play in program execution authentication ... say next generation of virus checkers also check for valid program/executable digital signatures. Even then there is a design trade-off between having the visus checker include a (account) table of acceptable public-keys vis-a-vis each program having an appended certificate in addition to the digital signature ... and the virus checker only having a table of CA public keys. Does the user want to pass approval on only the list of trusted CAs or does the user want to pass approval on each individual developer's public key? Once the user decides not to trust the CA as to whether programs from individual vendors are to be accepted ... then the user creates their own table of acceptable public keys (not relying on the CA/PKI trust infrastructure). bram [EMAIL PROTECTED] on 01/11/2000 10:41:32 AM To: Lynn Wheeler/CA/FDMS/FDC@FDC cc: Peter Cassidy [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications The first thing something needs to be a killer application is to be an application. The problem with PKI is that it isn't an application, it's a system. A killer app needs to have a very specific purpose, and needs a very immediate motivating factor for it's use. Think web browser. I'm more than a little bit skeptical that the world has much use for PKI just yet. PKI is useful for stopping active attacks, but right now almost everything on the internet is subject to passive attacks. Fix the first problem first, only then will it become clear how to solve the second problem. -Bram
Re: Killer PKI Applications
Claim is that the draft X9.59 financial industry standard (for all retail payments) could provide the level of integrity that would justify better than card/consumer present rates; i.e. the level of the integrity of the transaction is at least card present ... and the characteristic of X9.59 makes the account number pretty much worthless in non-signed transactions (i.e. even if every account number from X9.59 transactions were kept at a merchant server database ... and that database was compromised, the information could not be used for fraudulant transactions). One of the charters to the X9A10 working group for X9.59 was to preserve the integrity of the financial infrastructure with only a digital signature and be applicable to all retail based payments. The X9.59 mapping to existing payment card infrastructures, while relying on digital signatures does not rely on certificates and/or associated PKI/CA infrastructures. For more information see various references at: http://www.garlic.com/~lynn/ Randy Witlicki [EMAIL PROTECTED] on 01/11/2000 04:15:07 PM Please respond to Randy Witlicki [EMAIL PROTECTED] To: Peter Cassidy [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Killer PKI Applications The killer app should make somebody very rich. Perhaps where the consumer can make an online purchase, same as now with an SSL browser link, but they are using a credit card from "Hettinga National Bank" where the consumer gets a 1/2 percent rebate and the merchant gets charged 1/2 percent less than other credit cards (to encourage the merchant to recommend Hettinga National Bank to their customers). This would likely require disintermediation of of various finanacial processing links, maybe PKI, and perhaps even Digital Bearer Certificates. In this case, PKI is probably a Business-to-Business backend tool. Or have I been mis-reading Bob's cogitating and rants ? - Randy - For help on using this list (especially unsubscribing), send a message to "[EMAIL PROTECTED]" with one line of text: "help".
Re: Killer PKI Applications
the other problem with the CA approach is what is the CA certifying. Are they purely certifying the name of the company producing software applications ... or are they certifying every application that each software company produces. If I have to decide every company that I'm willing to accept software from ... then I've gone to a per company process that can be done with online authority and I'm maintaining a list of per company-based accpetable software sources. I don't need am not using a hiearchical CA-based trust infrastructure (possibly other than in a purely contrived manner). For the CA-based trust infrastructure to work for this scenerio ... the CA needs to be asserting the trust/quality/integrity of applications produced by each software company (so that I only need to record CA-level trust decisions) ... once I need to record vendor-level trust decisions then I've truncated any trust hierachy (embodied by a CA which then becomes superfulous/redundant). "Bill la Forge" [EMAIL PROTECTED] on 01/11/2000 01:19:34 PM To: Lynn Wheeler/CA/FDMS/FDC@FDC, "bram" [EMAIL PROTECTED] cc: "Peter Cassidy" [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications Once the user decides not to trust the CA as to whether programs from individual vendors are to be accepted ... then the user creates their own table of acceptable public keys (not relying on the CA/PKI trust infrastructure). Part of the problem with taking the CA approach is in dealing with multiple roots. We've drilled down on this problem a few times and having a signed list of acceptable keys is a solution that keeps coming back up. Frankly, I think this is an area where XML is going to play quite well. And I'm delighted with the latest draft on XML-based digital signatures: http://www.w3.org/TR/xmldsig-core/ Bill la Forge, CTO JXML, Inc.
Re: Debit card fraud in Canada
The NACHA pilot announced about a month ago specifies an AADS based transaction. The combined press release last week at BAI (something like cebit for the world retail banking industry) ... specifies AADS/X9.59 digital signing. The AADS strawman proposes an online paramerterized risk management infrastructure that can be software, hardware, bin-activated hardware, bio-sensor activated hardware, etc (i.e. integrity level of the compartment doing the digital signing). The issue isn't that the chip enables offline ... but that a chip with various characteristics can improve the integrity of online (non-face-to-face) transactions. misc. references. http://internetcouncil.nacha.org/ http://www.garlic.com/~lynn/ and specific ... http://www.garlic.com/~lynn/99.html#224 http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 David Honig [EMAIL PROTECTED] on 12/13/99 12:12:42 PM To: "Steven M. Bellovin" [EMAIL PROTECTED], Steve Reid [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Debit card fraud in Canada At 10:49 AM 12/13/99 -0500, Steven M. Bellovin wrote: true for credit cards? If so, a simple visual recorder -- already used by other thieves -- might suffice, and all the tamper-resistance in the world won't help. Crypto, in other words, doesn't protect you if the attack is on the crypto endpoint or on the cleartext. Wouldn't a thumbprint reader on the card (to authenticate the meat to the smartcard) be a tougher thing to shoulder surf? Does raise the cost over a PIN. Aren't there protocols where the exchange can't be replayed, but proof-of-knowledge is demonstrated? Or would these exchanges require on-line connectivity, thereby defeating the utility of smartcards some?
online debit ... nacha thing short excerpt from tomorrow's american banker
a private key to use in generating digital signatures with participating nternet merchants. The bank would attach a corresponding public key to the person's checking account and store it in a data base. When buying from an Internet site, the cardholder would use his ATM card number. Instead of entering a PIN, he would use the encryption key to digitally sign an electronic authorization form. The form, in turn, would be sent to the misc. related AADS information at: http://www.garlic.com/~lynn/
Re: Ecash without a mint, or - making anonymous paymentspractical
One of the things provided by X9.59 is that it is privacy/anonymous neutral at point-of-sale /or merchant webserver ... and in fact, with AADS accounts for hardgood shipments ... an X9.59-like protocol for address-authorization transaction... similar to X9.59 for payment-authorization ... not only eliminates name/address from the payment transactions at a webserver ... but can also eliminate the name/address at merchant webservers. merchant webservers get accounts ... for payments by financial institutions ... and accounts for name/address by shippers (i.e. policing name/address privacy at a couple dozen shippers is much simpler than policing name/address privacy at 20 million merchant webservers).
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital Comm
slightly different take on risk management in financial transactions. X9.59 is financial industry draft standard for all retail payments ... and is based on an AADS-model. Account Authority Digital Signature AADS AADS is the application of digital signatures to electronic business processes. At the simplest, AADS extends message integrity by encrypting the MAC with the sender's private key (i.e. the definition of a digital signature). The digital signature is used to perform two operations: 1) authenticate the sender and 2) verify the integrity of the message. The current prevailing digital signature infrastructure, Certificate Authority Digital Signatures, originated as a method of creating a totally self-contained, atomic message environment for offline operations (both sender authentication and message verification). There has been efforts to extend the CADS infrastructure to an online, anarchy model involving self-contained, authenticatable and verifiable message (message contains all information for both authentication and verification) exchange between random, unrelated parties. The extension of the CADS to online business messages between parties with existing business relationships has prooved more problematical. A large stumbling block has been the CADS self-authenticated methodology involves status (implemented in 'certifictes') information that is easily out-of-date and/or stale compared to what is expected by many business (including financial) practices. The Certificate Authority infrastructure combines a message and its digital signature (similar to the account authority method) with a certificate containing the necessary additional information to perform all necessary authentication and verification. A certificate is a defined format, digital signed message containing the public key necessary to verify the digital signature on the body of the main message and whatever additional attributes necessary to authenticate the message. This, in theory, creates a self-contained, authenticatable, and verifiable message. Frequently a digitally signed certificate message is referred to "binding" the public key to some set of characteristics or attributes. The original objective of the Certificate Authority infrastructure was to allow two parties, who otherwise have no knowledge of each other, to exchange messages, authenticate and verify the messages, and appropriately act on the contents of the messages. Extending the Certificate Authority infrastructure to the business relm has prooved problamatical because accepted business practices frequently rely on more timely attribute information than is easily available in pre-distributed "certificates" (business transactions commonly rely on account-records to provide timely attribute information as part of acting on the contents of a message). A basic assumption of the Certificate Authority infrastructure is frequently invalid in the business scenerio. First off, for most business messages, there tends to be pre-existing business relationship (i.e. the two parties aren't anonymous and unknown to each other). The business relationship between the two parties tend to also be established with account-records which contain timely status and attribute information specific acceptable for common business practices (i.e. bank account balance). Attempts have been made to modify the original premise of Certificate Authority infrastructure to provide simple forms of timely status. In one case, CRLs (certificate revokation list) have been created, basically providing a mechanism to negate a whole certificate (because one or more characteristics of the certificate is no longer valid). CRLs and/or other certificate negation mechanisms require something like an online account operation (and/or a highly structured operations tailored to keeping up-to-date on revokation information). For some time, accepted business practices have used account records to "bind" business attributes. There are examples of where account records include authentication information like signature cards, mother's maiden name, social security number and PINs. From a business process standpoint that currently supports account-record binding of authentication information, it is a simple extension to include public-key binding as an additional authentication methodology (i.e. basically registering a public-key in the account record in manner similar to the registration of other authentication information). Compared to an AADS implementation, for a business operation that would implemenat certifcate-based authentication and which also requires access to an account record in order to complete the business operation ... then it is fairly easy to show that the certificate is either superfulous (if the certificate is ignored) or represents increased risk (if it is not ignored). If a business operation is already dependent on the integrity of the account record,
