X9.59 mailing list

x959 Postings and Posting Index, next, previous - home



Identity theft tops Consumer fraud complaints
German federal employees get digital signatures
High-tech Thieves Snatch Data From ATMs (including PINs)
[ISN] Credit Card Scam
I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
credit card & gift card fraud (from today's comp.risks)
UNCITRAL Electronic Contracting Project
FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
Continuing the Dialogue on New Authentication Services
InfoSpace Buys ECash Technologies
Working Group Cardholder Authentication and ICC Cards
more on factoring breakthrough?
Smartcard security (& PKI systemic risk) thread in sci.crypt n.g
Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)
META Report: Smart Moves With Smart Cards
Worker Accused of Selling Colleagues' ID's Online (credit card scam)
Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
FC: European Commission considers mandatory digital rights management
Misc. payment, security, fraud, & authentication GAO reports (long posting)
Security Proportional to Risk (was: IBM Mainframe at home)
Regarding SPKI delegation certificate format (frowaded)
PKI: An Insider's View
(Extensible Markup Language) XML-Signature Syntax and Processing
Slashdot reports RSA keys under 2k insecure
Definese Dept Criticised on Internal Credit Card Fraud
Definese Dept Criticised on Internal Credit Card Fraud
[dgc.chat] XML/X - part I
Electronic Commerce Modeling Language (ECML):Version 2 Specification
Using Microsoft Word to create Internet Drafts and RFC's
Economics of financial applications of the smart card
some certification & authentication landscape summary from recent threads
some certification & authentication landscape summary from recent threads
pk-init draft (not yet a RFC)
some certification & authentication landscape summary from recent threads
some certification & authentication landscape summary from recent threads
Identity server infrastructure ... example
landscape & p-cards
Credit card fraud sending night-vision rifle scope to criminal
Microsoft Trustbridge ... Kerberos (tickets) support
AADS Chip Strawman & aSuretee
ATM Scams - Whose Liability Is It, Anyway?
FSTC Announces Proximity Payment Trial
RFC3354 Internet Open Trading Protocol Version 2 Requirements
Credit Card Skimming Rising In The US
Credit card theft feared in Windows flaw
x9.73 Cryptographic Message Syntax
IBM launches smart-chip consultancy - Tech News - CNET.com
Government of Canada Public Key infrastructure
Finance firms push messaging standards
glossary
San Diego Company owns e-commerce
REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
First International Conference On Trust Management
GAO Government Agencies Adhering to Privacy Laws
Meeting to mull privacy standard's next step
Workship on Human/Computer Interaction and Security systems
SAML Just The Start For Web Services Security
Cardtech/Securtech aSuretee press release
Liberty Alliance Waves White Flag at Passport
First Data Unit Says It's Untangling Authentication
First Data Unit Says It's Untangling Authentication
VeriSign unveils new online identity verification services
MaterCard test high-tech payments
eBay Customers Targetted by Credit Card Scam
eBay Customers Targetted by Credit Card Scam
eBay Customers Targetted by Credit Card Scam
[IP] The 20th anniversary of the Internet (fwd)
Briwn gets creatuve with wireless
Who owns the methods of E-commerce?
Web services specs focus on security
Invisible Ink, E-signatures slow to broadly catch on
Invisible Ink, E-signatures slow to broadly catch on
Invisible Ink, E-signatures slow to broadly catch on
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Invisible Ink, E-signatures slow to broadly catch on (addenda)
ssl certs
ssl certs
Invisible Ink, E-signatures slow to broadly catch on (addenda)
SSL certs & baby steps
SSL certs & baby steps (addenda)
SSL certs & baby steps
Invisible Ink, E-signatures slow to broadly catch on (addenda)


Identity theft tops Consumer fraud complaints

From: Lynn Wheeler
To: epay@xxxxxxxx
Subject: Identity theft tops Consumer fraud complaints
Date: Wed, 23 Jan 2002 18:58:18 -0700

http://www0.mercurycenter.com/nation/nationwire/docs/1740353l.htm
Posted at 8:09 a.m. PST Wednesday, Jan. 23, 2002

Identity theft tops Consumer fraud complaints

WASHINGTON (Reuters) - Identity theft cemented its dubious status as the most common type of U.S. consumer fraud complaint in 2001, according to federal statistics released on Wednesday.

Hijacking of personal information for fraud or theft made up 42 percent of the 204,000 fraud complaints filed with the Federal Trade Commission (FTC) last year.

Identity-theft complaints grew from 23 percent of the FTC's Consumer Sentinel database in 2000 when the problem also topped the list of consumer fraud headaches.

Scam artists crack Internet databases, intercept mail or bluff their way past bank tellers and credit bureaus in an attempt to gather Social Security numbers, bank account numbers and other confidential personal information.

Armed with that information, they can then apply for credit cards or bank loans, set up cell phone service or pass bad checks under someone else's name.

Recent victims include Oprah Winfrey and Tiger Woods.

Complaints about identity theft in 2001 outpaced Internet auctions, which accounted for 10 percent of consumer gripes; Internet services, at 7 percent; and shop-at-home and catalog offers, which made up 6 percent of the database.

The FTC statistics coincide with what experts say is increasing awareness and increasing incidence of identity theft as the Internet makes personal information more readily accessible.


German federal employees get digital signatures

From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: German federal employees get digital signatures
Date:    Wed, 23 Jan 2002 11:04:57 -0700
German federal employees get digital signatures

By Rick Perera

(IDG) -- Germany's federal government is introducing electronic signatures for its employees, a step it hopes will help make the security procedure generally accepted in the country. More than 200,000 employees of ministries and agencies will be able to sign electronic documents using a chip card with an encrypted key, giving them the same legal weight as paper documents with a handwritten signature, the federal Cabinet said in a statement Thursday.

The measure builds on legislation making digital signatures legally binding, which entered force in Germany last year, in concert with an effort to introduce such laws throughout the European Union.

Employees will be supplied with chip cards and readers between now and 2005, when a broad-ranging project to put all possible government services online is slated for completion. About a quarter of the 400 targeted services -- including, for example, bidding for federal procurement contracts -- will require electronic signatures, the government said. The one-time setup cost, including hardware, is estimated at ¥60 (US$53) per employee, with annual maintenance costs of ¥20 to ¥40.

The new decision calls for the development of standards for the securing of online documents, e-mail, and electronic transactions. The goal is to implement the standards ISIS (Industrial Signature Interoperability Specification) and MTT (MailTrusT), still under development with government funding.

"The federal administration expects that the interoperability standard ISIS-MTT will quickly establish itself on the market, and that appropriate products for each application, based on ISIS-MTT, will be available," the Cabinet decision said.

Some IT professionals were critical of the government for not being more specific about which technology it intends to use.

The industry association Bitkom (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.), while welcoming the decision, complained that it makes only suggestions and no concrete directions for implementation.

"After the many rounds of voting not much more remained than a description of the status quo," the group said in a statement. "The government thus unfortunately waters down its clear and praiseworthy aim of quickly and comprehensively outfitting the administration with security technology."

Bitkom called instead for a "citizens' card," with chip and electronic signature, for all Germans.

Rick Perera is a correspondent for the IDG News Service.


Find this article at:
http://www.cnn.com/2002/TECH/ptech/01/21/german.government.idg/index.html

High-tech Thieves Snatch Data From ATMs (including PINs)

Refed: **, - **, - **, - **, - **, - **, - **
From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: High-tech Thieves Snatch Data From ATMs (including PINs)
Date:    Wed, 23 Jan 2002 11:02:13 -0700
some previous skimming related postings:
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS

==================================

http://dailynews.yahoo.com/htx/abc/20020110/bs/atmfraud020110_1.html
Thursday January 10 03:26 PM EST

High-tech Thieves Snatch Data From ATMs By Paul Eng ABCNEWS.com

Thieves can steal an account number from an ATM or debit card, and secret pin.

At the corner market, the skim is in the refrigerated milk - and perhaps in the store's cash-dispensing ATM.

But this particular "skim" isn't good for customers since it involves the poaching of an unsuspecting consumer's bank card data.

Thieves have found a way to steal not only someone's account number from an ATM or debit card but also the person's seemingly secret personal identification number. With this double dose of information, thieves can electronically rob unsuspecting victims of their cash.

The scam has been reported in New York, Florida, California and points in Canada.

The cybercrooks' technique is so clandestine that consumers often don't know that they've become victims until they check their monthly bank statements - or when checks start to inexplicably "bounce" due to lack of available funds.

Suddenly Sapped of Cash

Chris Lundie, a 28-year-old market surveillance analyst with a Wall Street investment firm, was one such victim.

Last month, Lundie and his fiancée checked their bank account online in preparation to pay their Manhattan apartment rent. But, they noticed two odd withdrawals - for $500 and $600 - made within hours of each other at bank ATMs in Flushing, Queens.

"At first we questioned how this happened," says Lundie. "We don't work in Queens and we've never been to those ATMs."

After calling his bank to stop further activity on the account, Lundie called his local police precinct and discovered that he was the latest victim of a high-tech crime ring that may have been targeting automatic teller machine users for more than a year.

Detectives with New York City Police Department's Special Fraud Unit wouldn't comment on the "ongoing investigation" into the ring. But according to a recent report in the New York Post , the thieves may have stolen as much as $1.5 million. Authorities told the Post they suspected the scam was the work of the Russian mafia.

Snatching Data Clandestinely

Law enforcement officials did not disclose how the ring operated, but industry sources gave ABCNEWS a hint at how the ring might have stolen money from unsuspecting victims.

According to one source, the thieves may have targeted non-bank ATMs - the stand-alone cash dispensers found at local grocers, bodegas, gas stations, and shopping mall food courts. The machines are rigged with tiny devices that can read a debit card's magnetic stripe as it is run through the ATM's built-in reader. A special "logic board" or cover is placed over the ATM's keypad and records when users enter their four-digit PIN codes.

Both the card's magnetic data and the user's PIN information are stored in a separate memory module. The thieves retrieve the memory module and, using commercially available computer technology, encode the stolen information onto their own blank cards. These "cloned" debit cards can then be used with the captured PIN to withdraw money from the victims' accounts using other ATMs.

Con artists have targeted debit cards and ATMs in the past in a variety of scams. Most schemes, such as the so-called Lebanese Loop, are fairly simple.

In that scam, robbers would purposely rig the card slot of the ATM to physically capture a person's bank card. The scammer, posing as a good Samaritan, would then suggest that the victim repeatedly enter their secret PIN code in order to recover the stuck card from the machine. When the effort fails, the victim often walks away - leaving the con artist to retrieve the card and use it with the now-disclosed PIN code.

ATMs: Tempting Targets

Experts believe that the thieves may have targeted non-bank ATMs for several reasons.

For one, non-bank ATMs are typically owned and maintained by independent operators who may not know that such skimming devices are being added and removed from their cash dispensers.

Most of these stand-alone ATMs also lack built-in surveillance cameras and are placed in locations that aren't monitored closely, leaving police with very little evidence to work with during their investigations.

Crafting Countermeasures

Rob Evans, marketing director for NCR, a leading ATM supplier, says the industry has developed several technologies that can defeat these clandestine card skimming setups. ATMs supplied to NCR's bank customers, for example, can be equipped with enhanced card readers that can scramble the card's data as it's being read.

"When a user puts his card in, it jitters the electronic signals so it can't be picked up by a nearby illegal card reader," says Evans.

The banking industry is also looking into other high-tech measures such as using software encryption and so-called smart cards that store data on hard-to-duplicate microprocessors.

But industry officials such as Evans admits that it's a tough race against cybercriminals. "You do what you can to make the ATM as unappealing as you can to folks that want to use it for criminal purpose," says Evans. But as ATMs - especially stand-alone versions - proliferate, "The bad guys are going to keep coming at these things as quickly as they can."

Enduring Losses and Lessons

And that's disheartening news for both consumers and the financial institutions that absorb the estimated billions of dollars annually lost to bank card fraud.

Citigroup and J.P. Morgan & Chase - two of the largest institutions reportedly stung hard by this latest ring of thieves - wouldn't comment on the amount lost in the latest scam. But Mark Rodgers, spokesman for Citigroup, says, "No [customer] funds were at risk and we regret any inconvenience that may have resulted [from this crime]." Rodgers also says, "We've worked with customers to resolve the issues on their account."

And that's good news for consumers such as Lundie. His undisclosed financial institution restored the stolen funds to his account in about two weeks. After all, "$1,100 is a lot of money living in [New York] City," he says.

Still, he and his fiancée are keeping a close eye on their new account. And he says: "I definitely make more of an attempt to use a bank ATM."


[ISN] Credit Card Scam

From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: [ISN] Credit Card Scam
Date:    Wed, 23 Jan 2002 10:59:47 -0700
Forwarded from: Joe Penders <jpenders@xxxxxxxx>

Check out these sites:

http://www.ebay.com-order.fw.nu

same page again here

http://members.aol.com/cullcrow/

All wanting more info than anybody every needs over the net. HTML is also encrypted so can't tell where its really going to.

Ebay, AOL and FBI all informed on 19 Jan, 2002 but page is still up and collecting

I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
Date:    Wed, 23 Jan 2002 11:07:22 -0700
significant part of x9.84 and related standards have to do with secrecy needed to support biometrics.

Part of the issue has to do with whether it is a closed system or an open system. In a purely closed system .... there are trusted secured sensors that typically have a great deal of armoring (and many other security infrastructures, supposedly making it impossible to generate a transaction w/o using one of the heavily fortified secure fingerprint readers). If the fingerprint reader armoring and other security measures can be trusted and that a fingerprint is never needed in any other but the one and only, truely closed system .... then it sort-of works.

The problem is translating to an open system and multiple closed systems .... then it is the same problem as PINs/PASSWORDS ... which preclude using the same value in more than one security domain (otherwise there is a potential that institutions can impersonate you with other organizations or bad-guys can evesdrop and impersonate you by injecting fraudulent transactions into open networks. As stated many other times ... when PIN/PASSWORD becomes compromised it is relatively straight-forward to issue a new one .... when a similar compromise occurs with a fingerprint (or other biometric) it is somewhat more difficult to issue new biometrics.

==================================================================

Date Tue, 22 Jan 2002 13:41:18 -0800
To cryptography@xxxxxxxx
From Bill Frantz <frantz@xxxxxxxx>
Subject Re: I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
At 3:50 PM -0800 1/19/02, R. A. Hettinga quoted Dorothy Denning:
>My response is, "No." A good biometrics system should not depend on
>secrecy. ...
>
>What makes biometrics successful is not secrecy, but rather the
>ability to determine "liveness." ..
>
>The same principle applies in the digital world. Your biometric
>prints need not be kept secret, but the validation process must check
>for liveness of the readings. Many biometric products work this way.
>For instance, the Sensar iris-recognition system from Iridian
>Technologies (www.iridiantech.com) looks for the "hippus
>movement"-the constant shifting and pulse that takes place in the
>eye. The liveness test ensures that the reading is fresh, so an
>adversary can't replay a previously recorded reading. ...
It seems that this situation is true only if you can trust the device reading the biometric data. In the case an ATM, or a building entry system, this trust is reasonable.

>Testing liveness is reasonably straightforward if the biometrics
>reader senses appropriate characteristics and is tightly coupled with
>the validation process and database of biometric prints. If the
>reader is remote from the validation process and database, encryption
>can be used to provide a secure path connecting the components. The
>encryption system, obviously, should protect against replays.
However, encryption will buy you nothing if the biometric reading device is compromised or faked. If an attacker can take the freshness challenge from the other end of the connection, along with your public biometric data (say an iris pattern), then it can simulate an uncompromised device in responding with your "credentials".

Now there may be enough physical security in many places to be able to place reasonable trust in the devices which are installed there. However, it strains my belief that we will be able to trust the devices in every Internet Cafe in the world.

>Encryption can also be used to pass credentials from one system to
>another. For example, once my smart card validates my fingerprint, it
>may use a private signature key on the card to authenticate me to
>services that use my public key for authentication.
Unless your smart card has a fingerprint reader, it must trust the finger print reader it uses. An attacker can feed your smart card your public finger print data, responding to any freshness challenge your card may use, and get your card to authenticate someone else as you. It seems to me in this scheme, you must protect your smart card in much the same manner as you protect your credit cards. (Note that the smart card scheme is better than the credit card because, the secret data is not transmitted over a network like the credit card number. Modulo breaking the smart card protection, an attacker will need physical access to the card.)

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@xxxxxxxx | fair use.              | Los Gatos, CA 95032, USA
============================================================== ==============================================================

Date Fri, 18 Jan 2002 14:30:09 -0500
From Matthew Gaylor <freematt@xxxxxxxx>
Subject I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
<http://www.infosecuritymag.com/articles/january01/columns_logoff.shtml>
January 2001

SECURITY STRATEGIES FOR E-COMPANIES

WHY I LOVE BIOMETRICS

It is "liveness," not secrecy, that counts.

BY DOROTHY E. DENNING

I'm a big fan of biometrics. I'm tired of trying to remember umpteen zillion account names and passwords in order to use the computers in my office, browse my favorite Web sites and update the Web sites I manage. I long for the day when computers will automatically recognize me and handle the identification and authentication function with little effort on my part.

I make lots of security-related presentations, and when I tell all of this to an audience, someone inevitably asks, "What happens if someone snatches the biometric print used to validate you? Couldn't they just replay your biometric and pretend to be you? And wouldn't that make your biometric useless?"

My response is, "No." A good biometrics system should not depend on secrecy. To understand why, think about how biometrics work in the physical world. Your friends and colleagues authenticate you by recognizing your face, voice, eyes, hands and so on. None of this is secret. Anyone who interacts with you sees these characteristics. Even your fingerprints can be lifted from surfaces.

What makes biometrics successful is not secrecy, but rather the ability to determine "liveness." I can easily distinguish the living, flesh-and-blood you from a statue or photograph of you, or even someone wearing a costume and mask that looks like you. If I don't know you well, I might be fooled by a lookalike, but in the non-Mission Impossible real world, the system generally works. If I don't know you at all, I might ask for a photo ID. But I would use such a photo only because I lack knowledge of your appearance. I authenticate you by comparing your live face against the photo, not by comparing one photo against another. For further proof, I may watch you sign your name and compare the live signature against the one on your ID card.

The same principle applies in the digital world. Your biometric prints need not be kept secret, but the validation process must check for liveness of the readings. Many biometric products work this way. For instance, the Sensar iris-recognition system from Iridian Technologies (www.iridiantech.com) looks for the "hippus movement"-the constant shifting and pulse that takes place in the eye. The liveness test ensures that the reading is fresh, so an adversary can't replay a previously recorded reading. This is the beauty of biometrics. Other forms of user authentication-including passwords, tokens and encryption-all depend on protecting a secret or device from theft. Once that secret or device is compromised, the system fails until a new one is established. Moreover, these methods typically require users to hold a different secret with each and every device or service they use, thereby burdening the user. Imagine if every time you greeted a friend or colleague, you had to use a new secret handshake!

Testing liveness is reasonably straightforward if the biometrics reader senses appropriate characteristics and is tightly coupled with the validation process and database of biometric prints. If the reader is remote from the validation process and database, encryption can be used to provide a secure path connecting the components. The encryption system, obviously, should protect against replays. Encryption can also be used to pass credentials from one system to another. For example, once my smart card validates my fingerprint, it may use a private signature key on the card to authenticate me to services that use my public key for authentication. Of course, the encryption system itself requires secret keys, but in this context, the secrets may be less prone to compromise because they don't have to be known by humans.

Biometrics can be applied not only with human users, but also with locations. For example, technology from CyberLocator (www.cyberlocator.com) authenticates geodetic location by capturing a location signature from GPS signals in a way that ensures liveness. No secrets are required. One could imagine using biometrics to authenticate places or anything else with distinguishing characteristics that exhibit a form of liveness.

In addition to liveness, a biometrics system also depends on uniqueness. Otherwise, it may be subject to false accepts or rejects. Some forms of biometrics are better than others in this regard-iris recognition being one of the best.

Questions about privacy abuse aside, biometrics is likely to be the way of the future. I can't wait to get rid of my gazillion passwords.

__________________________________________________________________________
Distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes.
---


Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: freematt@xxxxxxxx with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per week) Matthew Gaylor, (614) 313-5722 ICQ: 106212065 Archived at
http://groups.yahoo.com/group/fa/

credit card & gift card fraud (from today's comp.risks)

Refed: **, - **, - **, - **, - **, - **, - **
From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: credit card & gift card fraud (from today's comp.risks).
Date:    Wed, 23 Jan 2002 11:01:28 -0700
other postings and recent info from comp.risks:

http://www.garlic.com/~lynn/aadsm9.htm#carnivore3 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/2002.html#19 Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
http://www.garlic.com/~lynn/2002.html#35 Buffer overflow
http://www.garlic.com/~lynn/2002.html#37 Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow

========================================================

Date Mon, 07 Jan 2002 20:07:25 -0500
From David Farber <dave@xxxxxxxx>
Subject Credit-card cloners' $1B scam
Homemade machines costing about $50 are being used to read credit-card mag-stripes, without having to steal the cards. The information is then e-mailed abroad, where cloned cards are fabricated. This has become a billion-dollar-a-year enterprise.

[PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists, mobsters in on hacking racket, by William Sherman, NY Daily News http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp]

[The gadget was first demonstrated in maybe 1960s at Caltech as part of a demo on how poor the mag-striped credit cards were. In spite of that, they won. Dave]

------------------------------

Date Sat, 29 Dec 2001 09:59:00 -0600
From Tim Christman <tjc@xxxxxxxx>
Subject Mag-stripes on retail gift cards
Here's a link to an article on MSNBC that I found interesting --
http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1

Many retailers are replacing paper gift certificates with small plastic cards containing magnetic stripes, similar to credit cards. Ideally, the purchase of a gift card would result in a database being updated to reflect the balance associated with the card's unique account number.

Some retailers are using sequential account numbers and have no provisions to protect against a thief using a mag-stripe reader/writer to re-program a stolen card or small denomination card so that it matches the account number of a larger valued card purchased by someone else. Many retailers even provide a convenient 1-800 number so that the thief, knowing many valid account numbers, can "shop" for a card of significantly greater value.

The RISK: A form of fraud, difficult to trace, involving a minimal investment in equipment by the thief. Also note that the thief only requires the ability to query the back-end database (through the toll-free number), not the ability to manipulate the records. Perhaps more ominously, the risk is angry family members who find a zero balance on their gift cards!

Solutions: One retailer, mentioned in the article, uses optical bar-coding which can't be re-encoded without defacing the card. Another follows a technique used by many credit card companies -- extra check digits are included in the mag-stripe that are not visible on the face of the card. It seems astounding that this isn't being done by all.

UNCITRAL Electronic Contracting Project

Refed: **, - **, - **, - **
From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: UNCITRAL Electronic Contracting Project
Date:    Wed, 23 Jan 2002 11:18:27 -0700
From Richard L. Field [mailto:field@XXXXXXXX]
Sent Tuesday, January 01, 2002 7:49 PM
To DIGSIG@xxxxxxxx
Subject UNCITRAL Electronic Contracting project
To: Interested persons

The Electronic Commerce Working Group of the United Nations Commission on International Trade Law (UNCITRAL) will next be meeting at the UN in New York on March 11-15, 2002. In preparation for that meeting, the UNCITRAL Secretariat has prepared a Note (A/CN.9WG.IV/WP.95) entitled "Electronic contracting: provisions for a draft convention". It is available at
http://www.uncitral.org/english/workinggroups/wg_ec/wp-95e.pdf (39pages).

This is the first of the next set of projects of the UNCITRAL E-Commerce Working Group, now that the UNCITRAL Model Law on Electronic Signatures has been completed. The new project deals with electronic contracting considered from the perspective of the United Nations Convention on Contracts for the International Sale of Goods (aka the UN Sales Convention or the Vienna Sales Convention). It is currently limited in scope to contract formation in electronic commerce. The WP.95 Note examines issues such as party location and when a contract should be considered "international" in scope and therefore subject to an international convention, offer and acceptance, consent, receipt and dispatch, automated computer systems, treatment of mistake and error, system requirements, and form requirements.

Bill Luddy has offered to set up a listserv and web site at Rensselaer Polytechnic Institute for those with an interest in keeping up with and commenting on this project. To subscribe to the listserv, please send an email (with your name) to Professor Luddy at <wjl@xxxxxxxx>. The listserv will also be used to announce any telephone conference calls to be held in preparation for the meeting.

-----------------------------
Richard L. Field, Esq.
755 Anderson Avenue, #4A
Cliffside Park, NJ 07010  USA
ph/fax:  +1 201-941-8015
field@xxxxxxxx
-----------------------------


FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From:    lynn.wheeler@xxxxxxxx
To:      epay@xxxxxxxx
Subject: FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
Date:    Wed, 23 Jan 2002 11:09:49 -0700
some recent FSTC announcements

From    Zach Tumin, Executive Director
             Financial Services Technology Consortium
To        FSTC's Industry Friends and Colleagues
FSTC is pleased to announce its new quarterly bulletin, FSTC Exchange. You can find the full issue at
http://www.fstc.org/news/newsletter/2002-01 Highlights are below. We look forward to working with members, associates and friends in 2002. A happy, healthy new year to all.

Zach Tumin
Executive Director
FSTC
-----------------------------------------------------------

FSTC Exchange / Winter 2002

The quarterly newsletter of the Financial Services Technology Consortium

-----------------------------------------------------------

Director s Commentary
New FSTC Initiatives in Mobile Financial Services
Validating WAP for Secure Mobile Financial Transactions
Prototyping the Secure Mobile Financial Services Infrastructure
Enabling FAST Authentication for Aggregation Services
Universal Value eXchange (UVX)
Automated Imaged Signature Comparison (AISC)
Meridien Research Partnership
New Board Members Named
FSTC Discussion Forum
What s Coming Up in 2002
-----------------------------------------------------------

Director s Commentary

As individuals and organizations we should champion the financial services industry. We should pool our collective wisdom, working together to build out the national and global infrastructures over which the nation's financial services providers conduct business, and customers access information and financial resources.
http://www.fstc.org/news/newsletter/2002-01/article01.cfm

New FSTC Initiatives in Mobile Financial Services

IDC predicts that by 2004 the number of Internet-enabled mobile devices will exceed that of personal computers. Given the growing importance of mobile technology to the financial services industry, FSTC has begun two projects to address the needs of members in delivering mobile financial services.
http://www.fstc.org/news/newsletter/2002-01/article02.cfm

Validating WAP for Secure Mobile Financial Transactions

Together with FSTC members and WAP technology and service providers, FSTC is now launching a three-month pilot project to develop and test an end-to-end wireless security environment for financial transactions, based on the emerging WAP 1.2.1/2.0 specifications. All FSTC members are invited to participate.
http://www.fstc.org/news/newsletter/2002-01/article03.cfm

Prototyping the Secure Mobile Financial Services Infrastructure

As financial institutions move to the mobile platform, interoperability between products and across service providers will be critical. To assure that member interoperability needs are met, FSTC is currently developing a submission to National Institute of Standards and Technology for a significant mobile financial services research and development initiative.
http://www.fstc.org/news/newsletter/2002-01/article04.cfm

Enabling FAST Authentication for Aggregation Services

How can aggregation providers authenticate themselves to financial institutions on behalf of financial institution customers? The FSTC FAST authentication protocol will soon be piloted to provide an answer. More information is available to members interested in reviewing the proposal or participating in the pilot.
http://www.fstc.org/news/newsletter/2002-01/article05.cfm

Universal Value eXchange (UVX)

FSTC is undertaking a development initiative to create a Universal Value eXchange (UVX) architecture and proof of concept. The framework will consolidate and normalize interfaces between legacy payment systems, and connect existing payments systems to new payment services. The project is in the formative stages.
http://www.fstc.org/news/newsletter/2002-01/article06.cfm

Automated Imaged Signature Comparison (AISC)

Can state-of-the-art image recognition technology be used to detect fraudulent check signatures? To find out, FSTC has engaged the International Biometrics Group (IBG) to assemble image comparison software from leading technology providers, develop test metrics, and exercise each system in a controlled laboratory environment.
http://www.fstc.org/news/newsletter/2002-01/article07.cfm

Meridien Research Partnership

A new collaborative partnership with Meridien Research gives FSTC members preferred access to Meridien s expertise in global financial services technology. FSTC and Meridien will share expertise on strategic technology investments, institute interactive forums to promote dialogue, and publish research on topics of joint interest.
http://www.fstc.org/news/newsletter/2002-01/article08.cfm

New FSTC Board Members Named

C. Grant Cole, senior vice president at Bank of America, Daniel R. Vermeire, chief technology officer at Huntington Banks, Lou Riehl, senior vice president at JPMorganChase Bank, and Julian Wachs, enterprise CIO for eCommerce technology and senior vice president at First Union/Wachovia Corporation, have all joined the FSTC Board.
http://www.fstc.org/news/newsletter/2002-01/article09.cfm

FSTC Discussion Forum

FSTC is introducing online discussion forums in which members can exchange ideas, explore opportunities for collaboration, and turn ideas into action. Complementing the discussion forums will be monthly live events where members can exchange ideas about the latest in financial services technology.
http://www.fstc.org/news/newsletter/2002-01/article10.cfm

What s Coming Up In 2002

The FSTC 2002 Winter Meeting is schedule for Feb. 27-28& FSTC will be moving to expand its principal membership& launching a new series of side-by-side research initiatives& launching a series of validation tests for specifications for financial transactions brought forward by other bodies& doing rapid prototyping of new authentication technologies&and more.
http://www.fstc.org/news/newsletter/2002-01/article11.cfm

-----------------------------------------------------------

About FSTC

FSTC, the Financial Services Technology Consortium, is a not-for-profit research and development organization comprised of banks, industry partners, financial service providers, technology companies, academic institutions, and government agencies.

FSTC sponsors collaborative technology development--pilots, proofs-of-concept, tests, and demonstrations--supported by member financial institutions and technology companies. Its aim is to bring forward interoperable, open-standard technologies that provide critical infrastructures for the financial services industry. FSTC members use these same infrastructures to bring their own products and services to the market place, stimulating customer interest and earning consumer confidence, and enhancing the position of financial services institutions in the marketplace.

About FSTC Exchange

FSTC Exchange is the official quarterly newsletter of the Financial Services Technology Consortium.

It is available online at
http://www.fstc.org/news/newsletter/

It is available in PDF format at
http://www.fstc.org/news/newsletter/download.cfm

If you would like to receive this newsletter at no cost, please visit the FSTC Web site at
http://www.fstc.org/news/newsletter/subscribe.cfm. For FSTC membership information or general correspondence, please contact us at fstcadmin@xxxxxxxx.

Copyright Financial Services Technology Consortium, 2002. All rights reserved.

To FSTC Members, Associates and Friends
From Zach Tumin, Executive Director

FSTC is pleased to announce the launch of a new wireless security project to validate the WAP 1.2.1 specification for mobile e-commerce. An FSTC project team will use live transactions over the Verizon wireless network to test critical financial transactions -- account balance, funds transfer, and bill payment. Today, many institutions do not support these transactions over wireless because of security concerns.

Our goal is to learn whether end-to-end encryption holds between the device and the financial institution under the WAP 1.2.1 specification using dynamic proxy navigation. Test results will be made available to project participants in May, and will be available to all FSTC members later in the fall.

FSTC members Bank of America, JPMorgan Chase, and Wells Fargo Bank are engaged on the project team. Verizon, Openwave, 724 Solutions, RIM, Neomar and Infogard Laboratories will also be participating and playing critical roles.

Wells Fargo Bank is hosting the project launch session February 6-7 in San Francisco. Project participation is open to all FSTC members. If you think your institution or firm might be interested, please contact us quickly. Project participation fees are frozen until the February 6 launch, at which time they increase.

The full press release describing this FSTC effort is appended, below.

If you would like to get a copy of the project plan, the project participation agreement, or see the participation pricing, please contact Jim Salters, FSTC Manager of Technology Development (jim.salters@xxxxxxxx)

We invite you to participate in this project and look forward to working together to validate this key specification.

Zach Tumin
_________________________________________________________________
Zachary Tumin
EXECUTIVE DIRECTOR
Financial Services Technology Consortium
401 N. Michigan Avenue, 22nd Floor
Chicago, IL 60611
www.fstc.org
zachary.tumin@xxxxxxxx
V 914-576-7629
F 978-336-8302
==========================================================

FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce

Collaborative Three-Month Validation of End-to-End Encryption for Mobile Financial Transactions to be Completed by May 2002

Project launch session scheduled for February 6th in San Francisco

Chicago ? January 21, 2002 ? Wireless security for mobile financial transactions is a key technology barrier facing financial institutions, according to the financial industry research organization Financial Services Technology Consortium (FSTC). To address the gaps in wireless security, and to establish a secure, end-to-end financial transaction infrastructure, FSTC-member financial institutions and technology companies have launched a collaborative three-month validation test, using real world transactions to test the encryption aspects of the WAP 1.2.1 mobile specification, and dynamic proxy navigation.

Sponsoring or participating companies in the WAP encryption test include 7/24 Solutions, Bank of America, InfoGard Laboratories, JPMorganChase Bank, Neomar, Openwave, RIM, Verizon Wireless, and Wells Fargo Bank. The project is open to all interested companies to join, with a two-day project launch session scheduled for February 6-7, at Wells Fargo Bank in San Francisco.

"Financial institutions need to validate that they can communicate privately and securely with their mobile customers," said Zachary Tumin, Executive Director of FSTC. "This test will not be simulated, but use live airwaves, real mobile devices, and real software products to test financial transactions, such as bill payment, fund transfers, and account balance inquiries. Using real applications we will be able to observe, in real time, if the encryption holds, end-to-end, for sensitive financial transactions. Until this test is complete, banks will be hesitant to introduce next generation wireless financial applications for mobile customers."

Results from the study will be available to project participants in May 2002, subsequently to non-participating FSTC members, and then to the public in the autumn of 2002.

"Without this collaborative effort each FSTC member bank would have to duplicate the effort and cost to conduct the same test to certify the new WAP specifications," said Kathy DeWit, Executive Vice President of Payment Strategies at Wells Fargo Bank. "Throughout the year, FSTC members regularly pool their technical resources and funds to solve shared problems. Collaboration makes our results more representative of the industry, and much less expensive, than going alone."

This year, FSTC plans to conduct a series of side-by-side technology tests and proofs-of-concept projects to validate emerging technologies geared toward financial services. Currently, FSTC is comparing automated imaged signature verification technologies that are used to reduce paper check fraud. The objective is to determine if specific technology actually performs as claimed and whether it can be implemented. All FSTC project participants gain early and exclusive access to test results.

Actual testing of encryption under the WAP 1.2.1 specification will be performed by InfoGard Laboratories of San Luis Obispo, California, with testing overseen by FSTC. InfoGard is an accredited FIPS 140-1 test laboratory under the National Institute Standards and Technology (NIST) NVLAP program. Results will be conclusive.

Organizations interested in project participation or attending the project launch session should contact Jim Salters at jim.salters@xxxxxxxx.

About FSTC

FSTC is a financial industry research organization comprised of banks, financial service firms, industry partners, national laboratories, universities and government agencies. Its goal is to bring forward interoperable, open-standard technologies for the financial services industry that makes possible new products and services. For more information, contact FSTC Headquarters at +1 (312) 527 6724 or visit http://www.fstc.org/.

Contact

Zachary Tumin
FSTC Executive Director
zachary.tumin@xxxxxxxx
+1 (914) 576 7629

To All FSTC Members

From Zach Tumin, Executive Director
FSTC Live Chat Event Reminder
Topic New Authentication Services What's the Financial Industry's Role?
Guest Chuck Wade, Internet Payments and Security Consultant
Time Wed., Jan. 23, 1200-100pm EST

Whitepaper Download
"New Authentication Services", By Chuck Wade

https://webworkzone.com/FSTCForums/dispatch.cgi/TopicOfTheMonth/folderFrame/10001 6/

Live Event

http://www.fstc.org/discussions/forums.cfm
Click on Live Event

If you have forgotten your username or password, check the FSTC Web site at
http://fstc.org/forgotPswd.cfm

E-mail questions to the event facilitator
live.chat@xxxxxxxx

Continuing the Dialogue on New Authentication Services

From: Lynn Wheeler
Date: 02/04/2002 08:59 AM
To: epay@xxxxxxxx
Subject: Continuing the Dialogue on New Authentication Services
zarchary.tumin@xxxxxxxx on 2/4/2002 7:26 am wrote:
To FSTC Members, Associates and Friends
From Zach Tumin, FSTC Executive Director
Subject Continuing the Dialogue on New Authentication Services

Recently, FSTC hosted a one-hour live chat event on new authentication services and the potential threat and opportunities they present to the financial industry. Our guest was Chuck Wade, a noted Internet payments and security consultant. Based on participation and feedback, the event was a great success.

Event Transcript
For those of you missed the live event, a transcript is available upon request. If you would like a copy, let me know via email and I'll forward one along.

Q&A Topics
The interactive Q&A was quite lively and we covered a number of important topics: Will financial institutions adopt Passport? Are there any general-purpose solutions that are lightweight enough for email? Will Liberty Alliance allow consumers to control their own data? What's the government's role in authentication?

Ongoing Discussion
To continue the dialogue on these important questions we have posted the relevant transcript sections as threads in the FSTC discussion forum. You can follow the conversation at:

https://webworkzone.com/FSTCForums/dispatch.cgi/TopicOfTheMonth/folderFrame/100016/

Feel free to add a reply to any of these threads or start your own if you have other authentication topics you would like to explore.

Access to the discussion forum is one of many FSTC member benefits. If you are a FSTC member and have forgotten your username or password, check the FSTC Web site at: http://fstc.org/forgotPswd.cfm.

If you are not yet a member, II urge you to consider joining FSTC now. For more information, visit http://www.fstc.org/membership/

Contact:
Zachary Tumin
FSTC Executive Director
zachary.tumin@xxxxxxxx
+1 (914) 576 7629


InfoSpace Buys ECash Technologies

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/27/2002 11:06 PM
To: epay@xxxxxxxx
Subject: InfoSpace Buys ECash Technologies

http://www.businesswire.com/cgi-bin/cnn-storydisplay.cgi?story=/www/bw/webbox/bw.021902/220500186.htm
BELLEVUE, Wash.--(BUSINESS WIRE)--Feb. 19, 2002-- With acquisition of eCash Technologies' assets, InfoSpace plans to bring merchants and financial institutions secure e-debit card processing and online and off-line stored value services such as pre-paid cards, loyalty programs and gift certificates

InfoSpace, Inc. (Nasdaq:INSP), a provider of wireless and Internet software and application services, today announced that the Company has acquired substantially all of the technology and intellectual property of eCash Technologies, Inc. which include electronic debit and stored value transaction technologies.

Terms of the deal were not disclosed.

These innovative technologies are built on an intellectual property portfolio of more than 20 patents issued in the US and overseas. InfoSpace plans to offer merchants additional payment mechanisms that are expected to reduce processing costs, while providing exciting opportunities for merchants to drive new revenue streams and strengthen their relationships with valued customers.

InfoSpace plans to add electronic debit functionality to its existing credit card and electronic-check processing services that would give merchants the ability to accept debit card payments. Through advanced encryption and digital signature technology, the debit solution is being designed to be able to authenticate the consumer and merchant, and authorize the payment via secure protocols developed by leading debit card associations. In addition, the solution is being designed to provide consumer identification and real-time verification of funds, allowing merchants to enjoy the equivalent of a "card present" transaction without certain of the fraud and charge-back concerns of "card not present" payments.

In addition, InfoSpace plans to offer merchants stored value coupon, incentive, loyalty and promotion services that can be redeemed both online and offline. Stored value programs can be used in a variety of ways by merchants to lower costs and build customer loyalty. These programs allow cash, points, etc. to be placed on a physical card or in an online account that can be redeemed for goods and services at the point of sale by the customer. For merchants with existing paper-based loyalty programs such as pre-paid cards and gift certificates, InfoSpace plans to develop these new technologies to extend these programs into the online world, enabling these programs to be redeemed interchangeably online and offline. InfoSpace plans to offer these services to its broad network of merchant resellers including leading financial institutions and other merchant service providers.

In the fourth quarter of 2001, InfoSpace Merchant services processed more than $1 billion in transactions, up from $700 million reported in the previous quarter. The total number of transactions processed was more than 12 million, up from 9 million reported in the third quarter. "Merchants today want innovative payment solutions giving them higher cost savings and increased fraud protection for both online and offline transactions. In addition, consumers want secure and convenient payment solutions that can be used both online and offline," said Prakash Kondepudi, InfoSpace executive vice president, merchant. "The acquisition of innovative technologies from eCash will enhance our payment technologies offered through leading merchant service providers and financial institutions with stored value payment services that address the needs of today's merchant businesses."

About InfoSpace, Inc.

InfoSpace, Inc. (Nasdaq:INSP) provides wireless and Internet software and application services. The Company develops software technologies that enable customers to efficiently offer a broad array of network-based services under their own brand to any device.

This release contains forward-looking statements relating to the development of InfoSpace, Inc.'s products and services and future operating results, including statements regarding InfoSpace's purchase of assets from eCash Technologies, Inc., that are subject to certain risks and uncertainties that could cause actual results to differ materially from those projected. The words "believe," "expect," "intend," "anticipate," variations of such words, and similar expressions identify forward-looking statements, but their absence does not mean that the statement is not forward-looking. These statements are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. Factors that could affect InfoSpace's actual results include the progress and costs of the development of our products and services and the timing of market acceptance of those products and services. A more detailed description of certain factors that could affect actual results include, but are not limited to, those discussed in InfoSpace's Annual Report on Form 10-K, in the section entitled "Factors Affecting Our Operating Results, Business Prospects and Market Price of Stock." Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of the date of this release. InfoSpace undertakes no obligation to update publicly any forward-looking statements to reflect new information, events or circumstances after the date of this release or to reflect the occurrence of unanticipated events.

--30--cla/se

CONTACT: InfoSpace, Inc.
Adam Whinston, 425/201-8946
adam.whinston@xxxxxxxx


Working Group Cardholder Authentication and ICC Cards

From: Lynn Wheeler
Date: 02/27/2002 11:08 PM
To: epay@xxxxxxxx
Subject: Working Group Cardholder Authentication and ICC Cards
note that this somwhat overlaps X9.59 since X9.59 used digital signatures for "account" holder (which has a mapping to iso 8583 payment "card") financial transaction authentication.

x9@xxxxxxxx on 2/26/2002 3:59 pm wrote:
[This message was automatically generated by X9 Forum]

There is 1 new document, TG-3 March 2002, in the X9F6 - Working Group Cardholder Authentication and ICC Cards committee.

Forum: X9F6 - Working Group Cardholder Authentication and ICC Cards

Folder: 2002-03 March 2002 Meeting - Gulfport, MS

Entry: TG-3 March 2002

From: Steve Case

Date: 02/26/2002


more on factoring breakthrough?

From: Lynn Wheeler
Date: 02/27/2002 11:08 PM
To: epay@xxxxxxxx
Subject: more on factoring breakthrough?
http://slashdot.org/articles/02/02/26/179206.shtml?tid=93

Smartcard security (& PKI systemic risk) thread in sci.crypt n.g

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/28/2002 10:26 PM
To: epay@xxxxxxxx
Subject: Smartcard security (& PKI systemic risk) thread in sci.crypt n.g.
http://www.garlic.com/~lynn/2002c.html#7

Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)

From: Lynn Wheeler
Date: 02/28/2002 10:26 PM
To: epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language (ECML): Version 2 Specification (draft)
ietf itrade working group


http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-spec-02.txt
             Electronic Commerce Modeling Language (ECML):
Version 2 Specification
                  <draft-ietf-trade-ecml2-spec-02.txt>
Abstract

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchicly organized payment related information fields in an XML syntax are defined as the second version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software.


META Report: Smart Moves With Smart Cards

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/01/2002 06:31 AM
To: epay@xxxxxxxx
Subject: META Report: Smart Moves With Smart Cards
http://itmanagement.earthweb.com/it_res/article/0,,3031_981861,00.html
Summary: Stronger authentication will supplement simple password approaches (2002-04), but infrastructure limitations will impede smart card adoption until 2003, and biometrics will remain niche through 2005. Privacy regulation (e.g., EU and Australian laws, GLBA, HIPAA) will focus attention on encryption of information at the data, file, database, and transport levels in 2002. By 2004/05, regulations will extend to numerous industries, and the concurrent maturity and transparency of PKI components (such as embedded in NOS, directories, and file systems) by 2006 will accelerate widespread use of encryption. Fine-grained authorization will remain an application play through 2005, though coarse-grained authorization will become more centralized throughout 2002/03.

Worker Accused of Selling Colleagues' ID's Online (credit card scam)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: Worker Accused of Selling Colleagues' ID's Online (credit card scam)

http://www.nytimes.com/2002/03/02/technology/02INTE.html?todaysheadlines=&pagewanted=print
March 2, 2002

Worker Accused of Selling Colleagues' ID's Online

By JACOB H. FRIES

former employee of the Prudential Insurance Company was arrested yesterday and charged with stealing the identities of colleagues from a database containing 60,000 names and selling some of them over the Internet as part of a credit card scam, federal prosecutors in Brooklyn announced.

While working in the tax department at Prudential, the former employee, Donald Matthew McNeese of Callahan, Fla., stole the database of personnel records, making it one of the largest potential identity-theft cases ever, said Jim Walden, the assistant United States attorney prosecuting the case for the Eastern District of New York. Mr. Walden would not specify how many people had money stolen in the scam.

Investigators in New York had been tracking Mr. McNeese for two years, after a detective in Brooklyn went online and noticed that Mr. McNeese had posted a message on an electronic bulletin board. In the message, Mr. McNeese announced that he had thousands of names and Social Security numbers for sale, according to the criminal complaint.

Investigators said they believed that Mr. McNeese also co-opted personal information at another company, but would not provide details, citing a continuing investigation.

Mr. McNeese, who turned 30 yesterday, was arrested at his house in Florida and is awaiting arraignment in Jacksonville, Fla., on charges of identity theft, credit fraud and money laundering, the authorities said. During his arrest, prosecutors said, he admitted taking the database when he worked at Prudential's Jacksonville office in 2000. During a search of his house, investigators seized a computer, a shotgun with a silencer and fake federal identification.

Mr. Walden, head of the Eastern District's computer crimes and intellectual property section, said he expected Mr. McNeese to be brought to Brooklyn and prosecuted. If convicted, Mr. McNeese could face 45 years in prison and ordered to pay a $750,000 fine and restitution to his victims.

On July 21, 2000, the complaint alleges, Mr. McNeese posted a message soliciting bidders: "Does anyone think this kind of info would be valuable enough to sell or trade for card numbers? If so, what kind of price would be fair? Consider that there may be thousands of records ready for sale."

A detective from the New York Electronic Crimes Task Force replied to Mr. McNeese by e-mail and indicated that he was interested in buying the identities for $50 each, the complaint says.

In later messages, the detective wrote that he could arrange a scam in which fraudulent credit cards were created from stolen identities and used to transfer money, the complaint says. Mr. McNeese then provided more identities and a transfer was arranged, according to the complaint.

In other instances, prosecutors said, Mr. McNeese posted the personal information of former colleagues on the Internet, free for anyone to use. One employee had more than $2,000 charged to his credit card, the complaint alleges. And later, investigators said, the suspect posted the Visa card number of a former supervisor and about $300 was stolen.

At the same time, Mr. McNeese created false e-mail addresses and sent harassing messages to former colleagues, according to the complaint. At one point, prosecutors believe, Mr. McNeese composed an incriminating message and made it appear to have been written by his former boss.

"All this highlights the good and bad of such a free medium like the Internet," said Mr. Walden, who added that he hoped that this case would put pressure on Internet companies to shut down sites devoted to criminal activity.

Robert DeFillippo, a Prudential spokesman, would not discuss Mr. McNeese's work history at the company. "We've been cooperating fully in a very active way," Mr. DeFillippo said. "The welfare of our employees, and that includes their privacy, is of the utmost importance to us."


Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: Re: Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
posted to internet-payments@xxxxxxxx

anders.rundgren@xxxxxxxx on 3/2/2002 6.56 am wrote:
Hum, I thought this list was down!

May I take the opportunity to introduce www.orbiscom.com who claim that they have the solution to secure Internet payments. Orbiscom is supported by major banks in the Nordics and achieves security without requiring any changes in the current infrastructure! No cryptography, or fancy merchant SW needed. In the US, First Data seems to support them as well. The basic concept is to issue short-lived, value-restricted, one-time credit-cards which means that web-sites "leaking" credit-card info will be much less harmful.

Regarding 3D Secure, I feel that is flawed as it introduces a brand -directory in the middle that is redundant, and make the system rigid. The very same idea (delegated signing), but using Web Services, could easily have supported all brands, local account-to-account schemes, etc.

An associated problem is that the banking-industry has failed to introduce an organizational-level PKI which is extremely needed for their client organizations for everything from acquiring credit card money, to sending invoices to their customers' Internet-banks. W.o. such a scheme, most of these new efforts will just be too hard to become ubiquitous. SET was extreme in requiring merchants to be a part of a credit-card-brand-PKI which is (in retrospect), simply ridiculous, as a merchant may support many brands, roles, and activities with respect to FIs.

BTW, using 3D Secure principles (not the current draft), there is no requirement for clients to have an EMV-resource, but (preferably) a PKI-resource identifying the client rather than his/her account. If EMV has no clear use on the net, will it ever make it in the physical world? I doubt it.

So maybe Orbiscom will really take this market although I remain skeptic as the winner may very well be status quo. As usual :-(.

cheers, Anders Rundgren

----- Original Message -----
From: Brent Clark
To: internet-payments@xxxxxxxx
Sent: Saturday, March 02, 2002 06:07
Subject: Visa 3-D Secure vs MasterCard SPA Whitepaper

GPayments' has just been released its latest whitepaper entitled: "Visa 3-D Secure vs MasterCard SPA: A Comparison of online authentication standards"

Visa 3-D Secure ("Verified by Visa") and MasterCard SPA are two new online authentication standards from Visa and MasterCard designed to protect online payment transactions with a password/PIN. These initiatives are aimed at reducing the incidence of online credit card fraud.

This whitepaper compare the standards head to head examining them from the perspectives of cardholders, issuers, merchants and acquirers. It also compares the standards from both a general architecture and a security architecture perspective. The whitepaper can be accessed at
http://www.gpayments.com/pdfs/GPayments_3-D_vs_SPA_Whitepaper.pdf

GPayments is focused on authentication and payment solutions for Internet transactions. GPayments has a full ePayments product suite including issuer authentication systems, cardholder applets, internet payment gateways and merchant authentication plug-ins. GPayments is a founding member of the Visa 3-D Secure Forum and a licensed MasterCard SPA implementer.

Regards,

Brent Clark

VP Business Strategy
GPayments Pty Ltd
www.GPayments.com
PO Box 1622
Warriewood NSW 2102 AUSTRALIA
Telephone: +61 2 9913 3088
Facsimile: +61 2 9913 3077


FC: European Commission considers mandatory digital rights management

From: Lynn Wheeler
Date: 03/02/2002 01:43 PM
To: epay@xxxxxxxx
Subject: FC: European Commission considers mandatory digital rights management
Date: Sat, 2 Mar 2002 12:23:13 -0500
From: Declan McCullagh <declan@xxxxxxxx>
To: politech@xxxxxxxx
Subject: FC: European Commission considers mandatory digital rights management

As the U.S. Congress weighs mandatory digital rights management, the European Commission is also looking into the topic. A 43-page EC study of digital rights management gives a nod to fair use and privacy -- and then says DRM schemes are not only inevitable but a fabulous idea.

A key excerpt from the study says the EC "should continue to encourage all players to develop operational, open and interoperable DRM solutions and to deploy them rapidly." (Apparently the EC has been funding such schemes for the last decade.)

I've placed the EC study here in PDF form (thanks, Michael):
http://www.politechbot.com/docs/european.commission.drm.030202.pdf

-Declan

----- Forwarded message from Michael Kleinhenz <kleinhenz@xxxxxxxx>
From: Michael Kleinhenz <kleinhenz@xxxxxxxx>
Subject: European Commission enforces DRM systems
To: declan@xxxxxxxx
Date: Sat, 02 Mar 2002 10:33:59 -0500

Hi Declan,

maybe something for your list:

Yesterday I was at a workshop of the European Commision on Digital Rights Management Systems. I held a talk about the weaknesses of DRMs and the chances of Open Content like business models. Most of the about 100 people attending the workshop were representatives of the content industry or manufacturers of DRM systems. Therefore my talk was not really liked by them (the usual "Open Source is like stealing" stuff).

More interesting is, that my impression of this workshop is, that

1. The EC will continue to support the use and implementation of DRM systems on a broad scale.

2. Their recent directive on that topic (2001/29/EC) that has to be implemented by the member states by the end of the year will result in a SSSCA like legislation.

3. From the proceedings and my personal conversation with some of the participants, I believe that most of the content providers have not realized the facts: many people at the workshop have talked about systems like Napster, but I think too few people had the actual technological advancement in mind when talking of such services. I was the only one to emphasize the implications from things like Freenet which I think is unstoppable, no matter what..

In result, I was scared by two things: how the workshop was compiled by the EC (95% content industry, 5% consumer rights organizations) and the fact that many people there were so naive in terms of DRMs, their implications and their implementations. Example: everyone was talking about a common standard for DRM systems to support many platforms, but no one was talking about the implications of (software)patents on it.

Attached you can find a Commission staff working paper on Digital Rights that may be interesting as well...

Thanks, Michael

--
Michael Kleinhenz LinuxTag 2002 - Europes largest Linux Expo
kleinhenz@xxxxxxxx http://www.linuxtag.org/


Misc. payment, security, fraud, & authentication GAO reports (long posting)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/02/2002 04:22 PM
To: epay@xxxxxxxx
Subject: Misc. payment, security, fraud, & authentication GAO reports (long posting)

* Payment Systems: Central Bank Roles Vary, but Goals Are the Same. GAO-02-303 February 25, 2002
* Check Relay: Controls in Place Comply With Federal Reserve Guidelines. GAO-02-19 December 12, 2001
* Federal Reserve Banks: Areas for Improvement in Computer Controls. GAO-02-266R December 10, 2001
* Anti-Money Laundering: Efforts in the Securities Industry. GAO-02-111 October 10, 2001
* Internal Controls: Federal Disbursement Controls Can Be Strengthened. GAO-01-910R August 13, 2001
* Purchase Cards: Control Weaknesses Leave Two Navy Units Vulnerable to Fraud and Abuse. GAO-01-995T July 30, 2001
* Financial Services Regulators: Better Information Sharing Could Reduce Fraud. GAO-01-478T March 6, 2001
* Information Security: Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology. GAO-01-277 February 26, 2001
* Bank Regulators' Evaluation of Electronic Signature Systems. GAO-01-129R November 8, 2000

Abstracts:
Payment Systems: Central Bank Roles Vary, but Goals Are the Same. GAO-02-303 February 25, 2002

The central banks of major industrialized countries have agreed on common policy objectives and presented them in the Core Principles for Systematically Important Payment Systems. Intended to help promote safer and more efficient payment systems worldwide, the Core Principles outline specific policy recommendations for systematically important payment systems and describe the responsibilities of the central banks. All of the central banks GAO studied seek to ensure that their wholesale payment systems operate smoothly and minimize systemic risk. All of the central banks provide settlement services for their countries' wholesale payment systems. Some central banks also provide wholesale clearing services. Other central banks own the system but have little operational involvement in clearing, while others participate in partnerships with the private sector. All of the central banks GAO studied provide settlement for some retail payment systems. Some, but not all, central banks exercise regulatory authority over retail payment systems in their countries. Central banks also tend to have less operational involvement in countries where there is a relatively concentrated banking industry. In some cases, laws governing payments and the structure of the financial services industry direct the involvement of central banks in retail payment systems.

Check Relay: Controls in Place Comply With Federal Reserve Guidelines. GAO-02-19 December 12, 2001

This report discusses the management of the air transportation network used to move checks from one Federal Reserve office to another. GAO studied the propriety of practices for bidding, awarding, and monitoring contracts and the adequacy of controls to monitor fuel and other payments to vendors. The network was moved to the Federal Reserve Bank of Atlanta (FRB Atlanta) in September 1998 and renamed Check Relay. Check Relay's internal controls are designed to ensure that each step of the contract evaluation and approval process conforms to FRB Atlanta and Federal Reserve System policies and that appropriate senior officials review and approve contract terms. Check Relay also ensures that all payments to vendors conform to contract terms. Another set of controls verifies that the amount of fuel used by Check Relay's vendors is consistent with expected levels and that fuel is provided only to the appropriate recipients. Check Relay is managed as a unit of the Retail Payments Office, which is managed out of FRB Atlanta. The Board's Division of Reserve Bank Operations and Payment Systems also has oversight responsibility over Check Relay. GAO found no evidence with which to question FRB Atlanta's conclusions that Check Relay's internal controls are effectively designed and implemented.

Federal Reserve Banks: Areas for Improvement in Computer Controls. GAO-02-266R December 10, 2001

As part of its audit of the U.S. government's fiscal year 2000 financial statements, GAO reviewed computer controls over key financial systems maintained and operated by the Federal Reserve Banks (FRB) on behalf of the Department of the Treasury's Financial Management Service (FMS) and the Bureau of the Public Debt (BPD). GAO identified opportunities to improve general controls related to access at two data centers; access, system software, and service continuity at a third data center; and access and system software at a fourth data center. GAO also identified opportunities to improve authorization controls over four key applications and accuracy controls over one of these key applications. FRB had corrected or mitigated the risks associated with all vulnerabilities discussed in earlier GAO reports. Although the general and application controls identified do not pose significant risks to the FMS and BPD financial systems, they warrant action to decrease the risk of inappropriate disclosure and modification of sensitive data and programs, misuse of or damage to computer resources, and disruption of critical operations.

Anti-Money Laundering: Efforts in the Securities Industry. GAO- 02-111 October 10, 2001

To disguise illegally obtained funds, money launderers have traditionally targeted banks, which accept cash and arrange domestic and international fund transfers. However, criminals seeking to hide illicit funds may also be targeting the U.S. securities markets. Although few documented cases exist of broker-dealer or mutual fund accounts being used to launder money, law enforcement agencies are concerned that criminals may increasingly try to use the securities industry for that purpose. Most broker-dealers or firms that process customer payments for mutual funds are subject to U.S. anti-money laundering requirements. However, unlike banks, most of these firms are not required to report suspicious activities. The Treasury Department is now developing a rule requiring broker-dealers to report suspicious activities. Treasury expects that the rule will be issued for public comment by the end of this year. Various intergovernmental groups, such as the Financial Action Task Force, have been working on recommendations that call for member nations to take various steps to combat money laundering through their financial institutions, including requiring securities firms to report suspicious activities. Although many members countries report that they have issued all or many of these recommendations and have applied them to their securities firms, it is difficult to determine how well the measures are being implemented and enforced.

Internal Controls: Federal Disbursement Controls Can Be Strengthened. GAO-01-910R August 13, 2001

GAO tested certain internal controls over federal disbursements processed by the Department of the Treasury's Financial Management Service (FMS) in fiscal year 2000. With some exceptions, FMS makes disbursements for all federal agencies through its Regional Financial Centers and Debt Management Operations Center. For fiscal year 2000, FMS reported processing approximately 890 million disbursements totaling more than $1.2 trillion. The centers disburse funds by check, electronic funds transfer (EFT), or Fedwire. FMS reported that these disbursements for fiscal year 2000 included approximately 265 million checks amounting to more than $265 billion, approximately 625 million EFTs amounting to more than $720 billion, and approximately 47,000 Fedwires amounting to more than $275 billion. The centers also process Automated Standard Application for Payments (ASAP) system enrollments. FMS reported the federal agencies authorized payments of over $254 billion in fiscal year 2000 using the ASAP system. This report reviews the results of GAO's (1) follow-up work on previously recommended improvements and corrective actions taken to address such recommendations and (2) fiscal year 2000 testing and related recommendations for improving controls over safeguarding assets and processing and documenting delegation and designation of agency certifying officers. GAO found that FMS' and the centers' corrective actions resolved weaknesses reported for fiscal year 1999 relating to (1) controls over checks awaiting destruction and returned checks, (2) segregation of duties for the ASAP system, (3) documenting agency certifying officer's signature verification, (4) authorized signature for return of canceled Fedwire disbursements, and (5) reconciling courtesy disbursements. Similar to fiscal year 1999, FMS had internal control weaknesses in personnel screening, inventory control, audit procedures, and reporting requirements.

Purchase Cards: Control Weaknesses Leave Two Navy Units Vulnerable to Fraud and Abuse. GAO-01-995T July 30, 2001

This testimony discusses internal controls weaknesses that left two Navy units in San Diego, California, vulnerable to purchase card fraud and abuse. GAO found a proliferation of purchase cards at the two units in San Diego--the Space and Naval Warfare Systems Command and the Navy Public Works. In the end, more than 1,700 cardholders essentially had the authority to make their own purchase decisions. A serious breakdown in internal controls over the receipt of government property and the certification of monthly statements, coupled with flawed or nonexistent policies and procedures and the failure of Navy employees to adhere to valid policies and procedures, led to (1) the loss, theft, and misuse of government property; (2) the potential abuse of purchase cards; and (3) payments of potentially fraudulent charges. Five fraud cases have already been identified, and the government remains extremely vulnerable to fraud, waste, and abuse arising from the purchase card program at the two Navy units. This testimony summarized the November report, GAO-02-32.

Financial Services Regulators: Better Information Sharing Could Reduce Fraud. GAO-01-478T March 6, 2001

The sharing of regulatory and criminal history data among financial services regulators can reduce fraudulent activities. GAO recently reported on several instances in which unscrupulous brokers moved from one financial industry to another. This testimony focuses on (1) systems used by financial regulators for tracking regulatory history data, (2) regulatory history data needed to help prevent rogue migration and limit fraud, (3) criminal history data needs among financial regulators, and (4) challenges and considerations for implementing an information-sharing system among financial regulators.

Information Security: Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology. GAO-01-277 February 26, 2001

The federal government must overcome several major challenges before public key infrastructure (PKI) technology can be widely and effectively used. These challenges include providing interoperability among agency PKIs, ensuring that PKI implementations can support a potential large scale of users, reducing the cost of building PKI systems, setting policies to maintain trust levels among agencies, and establishing training programs for users at all levels. Although such challenges are difficult to overcome in the near term, the federal government can take steps to better assist agencies develop and implement PKIs that may eventually be interconnected into a federal governmentwide system. The recent effort to develop a Federal Bridge Certification Authority (FBCA) is an excellent first step in this direction, but this effort lacks the context of a well-defined program plan for the government as well as key policy and technical standards. Establishing a federal PKI management framework could facilitate and accelerate participation in the FBCA as well as overall federal adoption of key technology for enabling electronic government.

Bank Regulators' Evaluation of Electronic Signature Systems. GAO-01-129R November 8, 2000

This report discusses bank regulators' evaluation of electronic signature systems. Financial institutions use signature systems to verify or authenticate the identity of customers conducting financial and nonfinancial transactions over the Internet and other open electronic networks. Officials at the Office of the Comptroller of the Currency (OCC) and the Federal Reserve told GAO that they are developing an examination strategy for Identrus LLC, which is an entity that provides services to financial institutions to authenticate electronic signatures. OCC officials have not determined what role they will play in assessing Identrus' operations, but they believe that financial institutions should take an active role in assessing the risks associated with electronic signatures.


Security Proportional to Risk (was: IBM Mainframe at home)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/04/2002 04:58 PM
To: epay@xxxxxxxx
Subject: Security Proportional to Risk (was: IBM Mainframe at home)
Anne & Lynn Wheeler writes:
After that, things still continued on the seven year cycle ... but there were two teams, working in parallel producing products offset. The 3081 was the "158" team ... the 3090 was the "168" team.

above from "ibm mainframe at home" thread in a.f.c
http://www.garlic.com/~lynn/2002d.html#7

with OT thread drift to security proportional to risk thread (somewhat e-commerce):
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

in the early 70s there was a trade-secret document theft case regarding disk technology. The assertions was that the "disk clone" business took 12 to 18 months to reverse engineer, duplicate and bring product to market (after initial introduction of new product). The assertion was that the document thefts would potentially allow a clone manufactur to bring a product to market six months earlier ... representing possibly several tens of billions of dollars in revenue.

somewhere along the way, the judge supposedly raised the "swimming pool attractive hazard" issue (aka pool owner is responsible for bad things that happen in their pool unless they can demonstrate fences and other security measures proportional to determination of trespassers that might find the pool attractive); aka for legal remedy, have to demonstrate security measures proportional to the value of the trade-secret.

For actual disk hardware this was a secure compound with perimeter fence and guards at the gates, patrols inside the compound, secure building with door badge readers, enforced & audited policies about tail-gating, 2nd floor (above ground) machine room with even more restricted badge reader acces. Within the machine room, devices were housed in a "test cell" ... basically a small heavy steel wire mesh cage (maybe 5x5x7, reinforce steel floor, heavy steel wire mesh sides & top). Door to cage had combination lock and each cage had unique combination. Lots of audit procedures and patrols to assure that security was being followed. This is somewhat analogous to safe deposit boxes but with more layers of security and constant auditing procedures.

Documents were "candy-stripe" covers with registered confidential classification. Each copy of a document was numbered. Each page of a candy-stripe document had the document copy number embossed in large print on every page (basically faint background but the number was large print essentially filling the whole page) with legend "registered confidential, do not copy/reproduce" on every page (either 3800 background flash or special paper from secure printer).

Each copy was signed out to specific person and that person had to follow a lot of processes protecting the document which were also audited on regular basis. A person having registered confidential documents also had special secure file cabinat for storing the documents, their offices had sporadic audits after hours and there were periodic audits to verify that the person still had possesion of the document. Registered confidential document copies tended to number in the tens or at most few hundres.

For the 3081 there were a whole file drawer of "811" documents (from the date nov. 1978) that were registered confidential and had to demonstrate that every copy of every 811 document was managed with the highest/appropriate security processes. Even at that, there was some leakage and a fairly well publiciszed industrial espionage case related to 811 documents.

bringing back to merchant e-commerce sites thread ... would an attractive hazard be a defense with regard to hacking e-commerce servers that had insufficient security?

random registered confidential refs:
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

random attractive hazard refs:
http://www.garlic.com/~lynn/aadsmore.htm#2527a RFC 2527 Physical Security Controls Question
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...

random disk test cell ref:
http://www.garlic.com/~lynn/94.html#15 cp disk story
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#18 IBM 4381 (finger-check)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/99.html#31 Old Computers
http://www.garlic.com/~lynn/99.html#54 Fault Tolerance
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#72 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001h.html#19 checking some myths.
http://www.garlic.com/~lynn/2001l.html#13 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002b.html#2 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?)

random 811/3081 references:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#00 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#103 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000b.html#65 oddly portable machines
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#62 z/Architecture I-cache
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#53 Varian (was Re: UNIVAC - Help ??)
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001j.html#13 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
http://www.garlic.com/~lynn/2001k.html#7 hot chips and nuclear reactors
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2001n.html#9 NCP
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002.html#45 VM and/or Linux under OS/390?????
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002b.html#32 First DESKTOP Unix Box?
http://www.garlic.com/~lynn/2002c.html#9 IBM Doesn't Make Small MP's Anymore
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home

random security proportional to risk refs:
http://www.garlic.com/~lynn/aadsmore.htm#2527a RFC 2527 Physical Security Controls Question
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror5 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#rhose17 [Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
http://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on netbanking & e-commerce security
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment standards ... finger slip
http://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001k.html#55 I-net banking security
http://www.garlic.com/~lynn/2001l.html#2 Why is UNIX semi-immune to viral infection?

Regarding SPKI delegation certificate format (frowaded)

From: Lynn Wheeler
Date: 03/05/2002 02:26 PM
To: epay@xxxxxxxx
Subject: Re: Regarding SPKI delegation certificate format (frowaded)
forwarded from SPKI mailing list (note authentication, spki, & aads masther thesis reference)

Pornthep Narula on 3/5/2002 5:47 am wrote:
On Mon, 4 Mar 2002, Carl Ellison wrote:


> I don't see a problem with delegating 10 of my 20 units to someone
> else. This is the same as writing a check. As long as you and I both
> have accounts in this bank, I should be able to transfer units to you
> at will -- and receive them as well. I can also convert real currency
> to these units. It's up to the bank if I can convert units back to
> real currency.
>
> Right?

right, iff you treat 'transfer', 'delegate' and 'grant' as same. but are they?

an excerpt from Oxford Advanced Learner's Dictionary, 6th Edition:

delegate (v) to give part of your work, power or authority to sb in a lower position than you.

grant (v) to agree to give sb what they ask for, especially formal or legal permission to do sth.

transfer (v) to officially arrange for sth to belong to sb else or for sb else to control sth.

as far as these traditional definitions go, SPKI doesn't deal with transfer at all, and is rather ambiguous when it comes to delegation vs grant. in fact, the three words have often been used interchangebly in SPKI-related RFCs, drafts, papers, and discussions. this, IMHO, is rather confusing and counter-productive.

i've been working on an authorization management framework, based on SPKI and AADS, that treats these three acts differently. a master's thesis is expected to be finalised and available for peer reviews later this year.

--
Regards,
Pornthep (tep) Narula


PKI: An Insider's View

From: Lynn Wheeler
Date: 03/06/2002 01:18 PM
To: epay@xxxxxxxx
Subject: PKI: An Insider's View
random other refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius
http://www.garlic.com/~lynn/x959.html#aads
http://www.garlic.com/~lynn/subtopic.html#privacy

====================================================================

http://www.infosecuritymag.com/articles/october01/columns_logoff.shtml

SECURITY STRATEGIES FOR E-COMPANIES

PKI: AN INSIDER'S VIEW

Bad karma and a multitude of technical issues have kept the technology from taking off.

BY BEN ROTHKE

It's been a recurring theme the past few Januarys: "This is the year of PKI." Such aspirations of hitting a grand-slam homerun weren't overly optimistic since public key infrastructure addressed many of the emerging Internet threats and operating necessities of e-commerce.

PKI vendors spent billions in product development and corporate acquisitions to position themselves for this potential market. However, the PKI game has essentially turned into a no hitter. I know; I was a player for one of the biggest PKI teams--Baltimore Technologies (www.baltimore.com).

With evaporating revenues and plunging stock prices, PKI vendors--such as Baltimore, Entrust (www.entrust.com) and VeriSign (www.verisign.com)--have dramatically scaled back their infrastructure, laid off employees (myself included) and rushed to refocus their offerings in more marketable sectors. Few still embrace their PKI roots, instead promoting new market strategies--data protection, infrastructure assurance, etc.

Where did PKI go wrong? There are many answers to explain why PKI (at least to date) has struck out. After spending years in the space, I've identified the following reasons.

Lousy name. For people without a background in security and cryptography (in other words, the majority), the term PKI is utterly nebulous. You've lost your potential customer by the time you explain what PKI means. Many say digital certificate infrastructure would have been a better name, but neither term rolls off the tongue like firewall or antivirus.

Security ignorance. The oft-quoted security dictum states: "If you think cryptography will solve the problem, then you don't understand cryptography and you don't understand your problem." This was also true of many who rushed to implement PKI simply because it was a cool technology promoted by IT prognosticators. Though PKI has many benefits, an organization without a clearly defined business need for it has no reason to implement it.

The "I" of PKI. The single biggest problem with PKI is that most people forgot the "infrastructure." PKI is a huge infrastructure project, unlike the preferred plug 'n' play solutions. While it's not rocket science, PKI is challenging because it's about reengineering a business infrastructure with an entirely new security architecture. PKI is 10 percent technology and 90 percent policies and procedures. Many early adopters didn't realize that enabling an enterprise to work with the certificates issued by a PKI server can take considerable time--months and even years.

PKI is new. Though the fundamentals of PKI were created in the 1970s, the implementation of PKI and the emergence of commercial PKI vendors didn't begin until the late 1990s. Many deployment and management problems occurred because the technology was as new to the vendors as it was to the customers.

Methodology. When discussing PKI deployment plans and methodologies, many customers were clueless. While CIOs aren't expected to know the minutiae of a PKI rollout, they need to know the fundamentals. Unfortunately, many CIOs didn't have a strategy for dealing with the multitude of non-PKI compliant in-house applications. They often wanted to roll out PKI deployments so badly that they lost sight of the big picture.

Liability issues. Infosecurity is about risk management, part of which is delineating liability for a specific course of action. With PKI rollouts, there was often a huge gap between who was liable for what in the event of a false positive or false negative.

Interoperability and lack of standards. Interoperability issues have long been a problem between users and PKI vendors. Interoperability led to the creation of the PKI Forum in early 2000, but it hasn't created many PKI standards. Without a common specification, users are left without a ubiquitous system for using digital certificates.

Legacy systems. While vendors constantly refine and improve applications, legacy systems continue to dominate many IT environments and often have zero PKI interoperability. Retrofitting is an option, but it's expensive and time consuming.

PKI is about establishing and maintaining a level of trust in the digital world. In the real world, trust is built through complex social, legal, national, international and business interactions that often take years or decades to develop. Unfortunately, establishing that same level of trust in cyberspace through technology is much harder. With Internet time being what it is, analysts demanding profits by quarter's end and digital trust meaning myriad different things to different people, PKI has been unable to escape its bad karma.


(Extensible Markup Language) XML-Signature Syntax and Processing

From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: (Extensible Markup Language) XML-Signature Syntax and Processing
also see ref for RFC index at: http://www.garlic.com/~lynn/rfcietff.htm
A new Request for Comments is now available in online RFC libraries.


RFC 3275

Title: (Extensible Markup Language) XML-Signature Syntax
and Processing
Author(s): D. Eastlake 3rd, J. Reagle, D. Solo
Status: Standards Track
Date: March 2002
Mailbox: Donald.Eastlake@xxxxxxxx, reagle@xxxxxxxx,
dsolo@xxxxxxxx
Pages: 73
Characters: 164198
Obsoletes: 3075

I-D Tag: draft-ietf-xmldsig-core-2-03.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3275.txt

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

This document is a product of the XML Digital Signatures Working Group of the IETF.

This is now a Draft Standard Protocol.


Slashdot reports RSA keys under 2k insecure

From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: Re: Slashdot reports RSA keys under 2k insecure


following is posting that Bernstein made to sci.crypt today ....
I've sent the following comments to the reporter:


: My paper demonstrates that extremely long keys need to be made
: approximately 3.009 times longer for the same factoring cost. There's no
: ''might'' about this; it's a straightforward mathematical fact.
:
: My paper repeatedly emphasizes that the situation for short keys is much
: more difficult to analyze. It _asks_ what the practical situation is. It
: _asks_ whether 1536-bit keys can be factored at reasonable cost.
:
: Your comments about ''claimed speed improvements in practice'' and
: ''implying that encryption keys as long as 2048 bits can now be broken''
: are blatant misrepresentations of what my paper actually says.
:
: My paper is a grant proposal. It explains the huge improvement for long
: keys, and outlines a plan for carrying out the short-key analysis. The
: results of the short-key analysis will not be known for a few years.
:
: Making claims about what those results will be, before the analysis has
: been done, is scientifically irresponsible. I despise such behavior; I
: resent being accused of it; I expect you to post a correction.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

t.c.jones@xxxxxxxx on 3/11/2002 6:15 pm wrote:

I talked to some cryptographers to see if this had any meaning for crypto practitioners.

As far as I can tell there is no example of any RSA key of 700 bits length being cracked (ie factored.)

If we assume that Bernstein can reducde the effort by 1,000,000 times, that is still only 20 bits.

If we assume that it will become 1,000,000 time easier to factor every year, that is 20 bits per year, or 15 years before 1000 bit RSA keys are at risk.

To be safe I tell people who want keys to last for 10 years to use 2048 bit keys. For the rest of us, 1024 bits should last for a long time.

..tom


> http://slashdot.org/articles/02/02/26/179206.shtml?tid=93


Definese Dept Criticised on Internal Credit Card Fraud

From: Lynn Wheeler
Date: 03/14/2002 10:08 PM
To: epay@xxxxxxxx
Subject: Definese Dept Criticised on Internal Credit Card Fraud
reference to the GAO report was posted here couple weeks ago
http://www.garlic.com/~lynn/aepay10.htm#19

http://www.thebankingchannel.com/printarticle.html?id=TBCWGCDL8UC
Defense Dept. Criticized on Internal Credit Card Fraud From AmericanBanker

Federal investigators testified before a House Governmental Affairs subcommittee Wednesday that the Defense Department's efforts to curb credit card fraud by employees have been ineffective.

Commanding officers from the Navy Public Works Center and the Space and Naval Warfare Systems Center, which were investigated by the General Accounting Office from November to February, also appeared at the hearing to pledge further reform. But the vows were met by stern words from skeptical lawmakers.

"We are now going to be considering a budget that requests an unprecedented increase in the defense budget, and I think it is appropriate to scrutinize every dollar, every million dollars, every billion dollars," said Janice D. Schakowsky, D-Ill.


Definese Dept Criticised on Internal Credit Card Fraud

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/17/2002 01:23 PM
To: epay@xxxxxxxx
Subject: RE: Definese Dept Criticised on Internal Credit Card Fraud
(possible resend?? ... I'm getting solid database corrupt, unable to allocate space error message when attempting to transfer this to the corporate server)

oh well, little finger fumble. i'm well known (infamous) for it (even 20 years ago).

there was a researcher in the early '80s that sat in the back of my office, went to me with meetings, got copies of all my email and logs of instant messages for a 9 month period. A detailed analysis turned into PhD sort of in CMC (computer mediated communication) ... joint between the language dept & computer AI dept at stanford (analysis of face-to-face, telephone, meeting, one-on-one, email, mailing lists, newsgroups, instant messages, etc ... compared & contrasted). Part of it including early computer conferencing with early mailing list technolgies (various precursors to current listserv & majordomo). There was also some subsequent books and papers published involving some of the same material (aka Knowledge Machines, Language and Information in a Technoligical Society).

random listserv/majordomo:
http://www.garlic.com/~lynn/99.html#225 BBSs vs. The Internet
http://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
http://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
http://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001c.html#19 What is "IBM-MAIN"
http://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes

misc. refs to stanford phd:
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
http://www.garlic.com/~lynn/99.html#205 Life-Advancing Work of Timothy Berners-Lee
http://www.garlic.com/~lynn/2001j.html#29 Title Inflation
http://www.garlic.com/~lynn/2001k.html#64 Programming in School (was: Re: Common uses...)
http://www.garlic.com/~lynn/2002b.html#51 "Have to make your bones" mentality
http://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc

slightly related:
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001j.html#31 Title Inflation
http://www.garlic.com/~lynn/2002e.html#10 Deleting files and emails at Arthur Andersen and Enron

tlewis@xxxxxxxx on 3/15/2002 7.04 pm wrote:
Definise Dept.? Is that the government deparment responsible for removing finesse from government publications? If so, they do their job extremely well.

Tony

-----Original Message-----
From: Lynn Wheeler [mailto:lynn.wheeler@xxxxxxxx]
Sent: Thursday, March 14, 2002 9:09 PM
To: Lewis, Tony
Subject: Definese Dept Criticised on Internal Credit Card Fraud


[dgc.chat] XML/X - part I

From: Lynn Wheeler
Date: 04/07/2002 07:41 PM
To: epay@xxxxxxxx
Subject: Re: [dgc.chat] XML/X - part I
or get really wierd and start talking about TPC ACID properties.
Atomicity

Either the transaction completes, or nothing happens at all. When a transaction fails in the middle of operation, the operations that have taken place should be rolled back.

Consistency

A transaction must begin in a consistent state and leave the system in a consistent state.

Isolation

No other participants are allowed to access the intermediate results. All intermediate operations are performed in isolation. Outside participants are only allowed access once a consistent state has been reached.

Durability

Once a server has committed to a transaction, it completes the transaction even if it suffers a system failure.


ref: The Benchmark Handbook for Database and Transaction Processing Systems, Jim Gray, ed, Morgan Kaufmann.

random refs:
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2001.html#6 Disk drive behavior
http://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
http://www.garlic.com/~lynn/2001k.html#15 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2002d.html#5 IBM Mainframe at home

t.c.jones@xxxxxxxx on 3/27/2002 6:54 pm wrote:
Idempotency - whoa!

the same idea is included in ANSI X9.59 - it is call a LUID there. See the following snippet of XML that i proposed to implement it. ..tom
<?xml version="1.0" encoding="UTF-8" ?>
<!--  ANSI X9.59 secure payment object definitions  -->
<!DOCTYPE X9Adocument (View Source for full doctype...)>
<XAdocument>
 <PAYREQ version="1">
<Merchant name="Frank's Fraudulent Flea Market">1,5879156</Merchant>
  <Transaction payCode="x" LUID="113" startDate=""
endDate="20010628" merchantTrac="123-4567890">79541USD</Transaction>
<Consumer>2,6652827</Consumer>
</PAYREQ>
 <Result Action="Accept">200 OK</Result>
<TOKSIG>2938d77e8a5f827</TOKSIG>
 <APPSIG>098d7a855f822b1</APPSIG>
</XAdocument>

> Date: Mon, 25 Mar 2002 23:03:13 -0500 (EST)
> From: Ian Grigg <iang@xxxxxxxx>
> To: xml-api@xxxxxxxx
> Subject: [dgc.chat] XML/X - part I
> Cc: dbs@xxxxxxxx, dgcchat@xxxxxxxx
> Sender: owner-dgcchat@xxxxxxxx
> Reply-To: dgcchat@xxxxxxxx
>
> It is with some satisfaction that we announce the first
> public demonstration of a new project that we've been
> working on for the last six months.
>
> This demonstration is taking place at Java 1 this week,
> by Erwin Van der Koogh, a programmer with Sun's XML group
> in Dublin.  He's also a WebFunds programmer, having been
> primarily responsible for the current generation.
>
> You can check out a scratch home page for the project at:
>
>        http://www.webfunds.org/guide/xml/
>
> We were looking some time ago at the difficulty faced
> by the various merchants in implementing access to the
> current money providers.  As no merchant could really
> predict where the good money was, so to speak, it was
> pretty obvious that being able to implement a range of
> gold-based units was much less risky.
>
> But it was also rather impossible.  The transfer methods
> for the systems ranged from pretending to be a browser,
> to accessing partially complete protocols to .. nothing.
> None of the systems in place seem to appeal as none of
> them have actually been thought out from the point of
> view of what we know about protocols and networks.
>
> It behoved us to come up with our own spend system.  We
> were in the throes of developing our own web-based system,
> and we wanted that bit right.  After all, a lot of demand
> comes from the support of the merchant class (a group we
> christened as Matildas, but that's a story for another
> day).
>
> Others, such as Intertrader, were still smarting at the
> cost of having developed access for different systems,
> and not having been able to efficiently deploy it because
> of the system bugs imposed on them.  And, yet others
> simply didn't know where to start.
>
> It all begged for a standard.  We sat down and drew one
> up.  Now, because standards committees tend to be noisy,
> rumbunctious, and ultimately unproductive, unless they
> have a very solid mission to draw from, we decided not
> to make this a publicity thing in the beginning.  That
> is, we decided to write it first, then open it up.
>
> All well and good, and of course, we chose to do our
> transfer interface in XML.  We called it XML/X as a
> quick code name for the project, being transactions in
> XML.  The results will be open source, the documentation
> will be readily available, and no fees will be levied on
> joining or using.  Even though this project is about
> money, it makes more monetary sense to impose no barriers
> on its widespread adoption.
>
> A quick example might clarify what all this hyperbole is
> about.  Imagine you have some accounts at a standard DGC
> such as e-gold, goldmoney, or one of those other systems
> such as PayPal.  As a merchant, you want to initiate a
> transaction from your automated web system to pay out a
> customer.  Or vice versa.
>
> So, you open up a connection to the money server and
> send down a stream of commands to cause it to happen.
> Here's how you would do it in today's XML/X:
>
>      <TransferRequest>
>        <Transfer>
>          <ClientID> P9348235 </ClientID>
>          <Payee> E3491 </Payee>
>          <Payer> 34201-543 </Payer>
>          <Amount> 45.23 </Amount>
>          <Currency> Platinum </Currency>
>          <Memo> Slicker than Slick </Memo>
>        </Transfer>
>
>        <Auth>
>          <Username> iang </Username>
>          <Password> Rock On </Password>
>        </Auth>
>
>      </TransferRequest>
>
> (Take that as an alpha - it's still evolving and is
> likely to change.)  Consider this one feature as an
> example:  In our XML/X, you can do a one-shot transfer
> and get a reliable result.  It's reliable because you
> can resend it (see the <ClientID>?), and get the same
> result - one and only one transaction, as long as the
> server saw the instruction and acted at least once.
>
> That's pretty useful.  In fact, it's so useful it
> is blessed with the otherwise indecipherable term of
> _idempotency_ (which means, it happens zero times or
> once, no matter how many times you send it).  There are
> lots of other useful features, but they lack general
> interest unless one has social disabilities and wears
> a propellor.
>
> How useful would all that be to a cambist?
>
> Such near-latin would be even more useful if all systems
> offered the same interface.  By designing in elements
> of protocols, it makes sense to adopt this one rather
> than roll your own.  As an aside, XML/X incorporates
> elements from SOX, the most reliable protocol for money
> I've ever seen, although I admit to being a tad biased.
>
> But the best is yet to come...
>
> TO BE CONTINUED...


Electronic Commerce Modeling Language (ECML):Version 2 Specification

From: Lynn Wheeler
Date: 05/01/2002 09:24 AM
To: epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language (ECML):Version 2 Specification
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

Title     : Electronic Commerce Modeling Language (ECML):Version 2
Specification
Author(s) : J. Parsons, D. Eastlake
     Filename  : draft-ietf-trade-ecml2-spec-03.txt
Pages     : 22
     Date      : 30-Apr-02
Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchicly organized payment related information fields in an XML syntax are defined as the second version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-spec-03.txt

Using Microsoft Word to create Internet Drafts and RFC's

From: Lynn Wheeler
Date: 05/01/2002 09:25 AM
To: epay@xxxxxxxx
Subject: Using Microsoft Word to create Internet Drafts and  RFC's
A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title     : Using Microsoft Word to create Internet Drafts and
RFC's
Author(s) : M. Gahrns, T. Hain
     Filename  : draft-hain-msword-template-08.txt
Pages     : 18
     Date      : 30-Apr-02
This document will describe the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format.

A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hain-msword-template-08.txt

Economics of financial applications of the smart card

From: Lynn Wheeler
Date: 05/24/2002 08:25 AM
To: eapy@xxxxxxxx
Subject: Economics of financial applications of the smart card
Economics of financial applications of the smart card (added: 24-May-2002)
http://europa.eu.int/ISPO/fiwg/archives/steering/fasc.htm

The outlook for the financial applications of the smart card (FASC), such as debit security, electronic purse or multi- functional payment card, appears highly controversial and unsettled. On the one hand, there are optimists who predict that FASC will become ubiquitous within the next few years both in the physical and the virtual worlds. On the other hand, there are sceptics who see FASC confined to few niche market segments. The actual deployment of FASC follows a disparate pattern, with strong geographical variations. FASC are rolled out on a large-scale, in hundreds of million of units, in Europe, while they remain in pilot stages of small-scale experiments in the United States and Japan.

some certification & authentication landscape summary from recent threads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/01/2002 12:48 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: some certification & authentication landscape summary from recent threads
real-word, real-time certification transactions
===============================================

One of the most familiar world-wide electronic certification transactions is the point-of-sale payment card transaction. basically a customer makes an assertion about paying the receipt ... and the consumer/issuing financial institution either agrees to certify that assertion or not. if the financial institution agrees to certify that assertion ... it typically assumes some amount of financial liability for each and every certification transaction that it performs. this is somewhat different from the offline, certificate based model where the certifying institution (CA or certification authority) may have no idea how many and/or what kind of transactions that their "certificate" is involved in (and as a result there is little way of truely doing any kind of real time risk exposure assesement).

Some of these real-time electronic certification transactions include a name & address certification option (i.e. in addition to the payment assertion, there can be an optional name & address assertion) typically referred to as AVS. Some number of web/internet based businesses have discovered how to perform an ersatz electronic payment transaction that includes AVS certification w/o any item appear on the consumer's monthly statement (the consumer doesn't know that it happened and/or doesn't see any charge associated with it).

This is significantly different than the offline certificate model ... where a certified trusted electronic document is created at some time in the past regarding some stale, static information which is then used in potentially arbritrary & unknown number of operations.

These real-time certification operations have the interesting characteristic that the fees charged are between the institution performing each certification and the relying party that is going to be relying on the certification. This differs from the typical certificate-based model where the consumer is being charged for their certificate ... not the relying-party. Given the realtime certification fee model ... one might expect to see a situation in the consumer paid certificate model ... where the relying party re-imburses the consumer some value for each time the certificate is checked.

X9.59
=====

x9.59 is designed to add digital signature authentication to all payment related electronic real-time assertions. The objective is reducing the fraud and risk exposure on a per transaction basis by providing end-to-end integrity of the asserted transaction. In turn this should lower the liability exposure to the certification authorities (issuing institutions) that are performing the real-time certification responses.

http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/x959.html#x959

FSTC FAST
==========

financial authenticated secure transaction .... basically is looking at extending the prevelent real-word,real-time, online, electronic certification transaction to things in addition to paymemt, name and address. One of the assertion items mentioned was age ... that a signed assertion is made as to being younger or older than some value ... and the financial institution would certify the assertion.

It is possible to take the X9.59 specification and its mapping to various existing real-time payment transactions and perform a similar mapping to real-time FAST certification transactions.

Real-world internet authentication
==================================

Probably the highest incidence/frequency of real-world internet authentication events today involves RADIUS typically with userid/password (majority of ISP, corporate networks, boundary routers, etc).

As part of the work on supporting FIPS186-2, ecdsa digital signature authentication (see mappings documented for x9.59) ... a version of RADIUS with FIPS186-2 ecdsa is being made available. RADIUS supports multiple authentication mechanisms and different mechanisms can be specified on a user by user (or account by account) basis. The FIPS186-2 case effectively registers a public key for the account (in lieu of a password) and performs FIPS186-2 authentication ... in place of password.

http://www.garlic.com/~lynn/subtopic.html#radius

also
http://www.garlic.com/~lynn/rfcietff.htm

and select "TERM->RFC#", then select RADIUS in the acronym "fastpath" at the front of the entry. This will give pointers to all the RADIUS related internet standard RFCs

Real-world internet authentication
==================================

For campus, departmental, and server type operations, one of the emerging security mechanisms is Kerberos. This was developed at Project Athena 15 or so years ago. This appears in windows 2000, various unixes and various mainframes. Kerberos is also an internet RFC standard. Use similar procedure in the "TERM->RFC#" but scroll down to the Kerberos entry to get a list of all Kerberos related RFCs.

There is a internet standard draft in progress (not yet made it to RFC status) that specifies the use of public key authentication in conjunction with Kerberos. This draft is agnositc whether the public key is supplied with a certificate or is registered in place of the password in the Kerberos userid/priveleges database.

Internet public key events
==========================

Possibly 99.999 percent of the public key events occuring on the world-wide internet is done in conjunction with SSL and "manufactured certificates".

The nominal purpose for these "manufactur certificates" is so that the SSL transaction can check the domain name typed-in for the URL against the domain name in the certificate. The issue is questions about domain name infrastructure integrity and its ability to provide trusted responses to requests of mapping a domain name to an IP-address.

Note however, that the authoritative agency that all CAs have to check with as to the validity of a asserted domain name ... prior to certifying and manufacturing the certificate ... is the domain name infrastructure. As a result CAs are dependent on the very same domain name infrastructure that everybody else is. There are proposals to improve the operational integrity of the domain name infrastructure .... in part so that CAs can better trust the information that they are certifying. One item is for people registering their domain name and ip address ... to also register their public key at the same time.

Now

1) improving the integrity of the domain name infrastructure for CAs ... also improves it for everybody ... and lowers the need for SSL domain name certificates

2) domain name infrastructure has a generalized mechanism for real-time distribution of information ... not restricted to ip-address response. If the domain name infrastructure had registered public keys ... they could distribute such public keys in the same response when they distributed ip-addresses ... further reducing the need for SSL domain name certificates. Note this also could significantly simplify and reduce the SSL protocol startup chatter (as well as totally eliminating requirement for certificates)

http://www.garlic.com/~lynn/subpubkey.html#sslcerts

=========================================================

... trivia question ... from earlier posting:
http://www.garlic.com/~lynn/aadsmore.htm#dctriv Digital Commerce Trivia Question

some certification & authentication landscape summary from recent threads

From: Lynn Wheeler
Date: 06/02/2002 07:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
and of course small brain check:

that should have been http://www.garlic.com/~lynn/rfcietff.htm

in the rfc specific summaries ... clicking on the ".txt=" field retrieves the actual RFC.

the procedures uses to generate the index also does knowledge based type consistency checking on the transitions ... a subset of the consistency result used to appear in section 6.10 in earlier STD1 (i.e. standard #1, a specific RFC periodically re-issued as overall internet standard reference).

examples:
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

specific RFC summary

2865 DS
Remote Authentication Dial In User Service (RADIUS), Rigney C., Rubens A., Simpson W., Willens S., 2000/07/05 (76pp) (.txt=146456) (Updated by 2868 ) (Obsoletes 2138) (RADIUS)

some kerberos

Kerberized Internet Negotiation of Keys
see also kerberos
3129

kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411

specific rfc summary

1510 PS
The Kerberos Network Authentication Service (V5), Kohl J., Neuman C., 1993/09/10 (112pp) (.txt=275395) (KERBEROS)


lynn.wheeler@xxxxxxxx on 6/1/2002 12:48 pm wrote:
also
http://www.garlic.com/~lynn/rfcietff.htm

and select "TERM->RFC#", then select RADIUS in the acronym "fastpath" at the front of the entry. This will give pointers to all the RADIUS related internet standard RFCs


pk-init draft (not yet a RFC)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/02/2002 08:19 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: pk-init draft (not yet a RFC)

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-cat-kerberos-pk-init-15.txt
2. Introduction

The popularity of public key cryptography has produced a desire for its support in Kerberos [2]. The advantages provided by public key cryptography include simplified key management (from the Kerberos perspective) and the ability to leverage existing and developing public key certification infrastructures.

Public key cryptography can be integrated into Kerberos in a number of ways. One is to associate a key pair with each realm, which can then be used to facilitate cross-realm authentication; this is the topic of another draft proposal. Another way is to allow users with public key certificates to use them in initial authentication. This is the concern of the current document.

PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in combination with DSA keys as the primary, required mechanism. Note that PKINIT supports the use of separate signature and encryption keys.

PKINIT enables access to Kerberos-secured services based on initial authentication utilizing public key cryptography. PKINIT utilizes standard public key signature and encryption data formats within the standard Kerberos messages. The basic mechanism is as follows: The user sends an AS-REQ message to the KDC as before, except that if that user is to use public key cryptography in the initial authentication step, his certificate and a signature accompany the initial request in the preauthentication fields. Upon receipt of this request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as before, except that the encPart from the AS-REP message carrying the TGT is now encrypted utilizing either a Diffie-Hellman derived key or the user's public key. This message is authenticated utilizing the public key signature of the KDC.

Note that PKINIT does not require the use of certificates. A KDC may store the public key of a principal as part of that principal's record. In this scenario, the KDC is the trusted party that vouches for the principal (as in a standard, non-cross realm, Kerberos environment). Thus, for any principal, the KDC may maintain a symmetric key, a public key, or both.

The PKINIT specification may also be used as a building block for other specifications. PKINIT may be utilized to establish inter-realm keys for the purposes of issuing cross-realm service tickets. It may also be used to issue anonymous Kerberos tickets using the Diffie-Hellman option. Efforts are under way to draft specifications for these two application protocols.

Additionally, the PKINIT specification may be used for direct peer to peer authentication without contacting a central KDC. This application of PKINIT is based on concepts introduced in [6, 7]. For direct client-to-server authentication, the client uses PKINIT to authenticate to the end server (instead of a central KDC), which then issues a ticket for itself. This approach has an advantage over TLS [5] in that the server does not need to save state (cache session keys). Furthermore, an additional benefit is that Kerberos tickets can facilitate delegation (see [6]).


some certification & authentication landscape summary from recent threads

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/03/2002 07:08 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
no discussion about SSL-client-auth work.

there is discussion about SS domain name server certificates and that it supposedly addresses integrity issues with domain name infrastructure .... but because CA authentication of of SSL server certificate is also dependent on same infrastructure ... that CAs have proposals to fix that domain name infrastructure. however the fix then reduces original requirement for the certificates (fixing integrity issues with domain name infrastructure). "fix" would also enable domain name infrastructure to do real-time non-stale, non-static distribution of public keys. furthermore, domain name infrastructure doing real time distribution of public keys in the same operation as ip-address distribution can improve SSL startup efficiency and reduce the startup SSL message chatter.
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

there has been discusscion that the dominant client authentication process in the internet/web today around the world (by possibly order of magnitude) is radius related typically with userid/passwords (all ISPs, corporate internets, routers, etc) ... as per previous note.

Not mentioned in previous note but in several discussions at:
http://www.garlic.com/~lynn/subtopic.html#radius

is that majority of web servers ship with stub code for doing client authentication. frequently people then implement userid/passwords in flat files for client authentication.

however, some straight-forward code that could be shipped with every web server would be some additonal code that would make radius calls for doing client authentication. This has a significant administrative benefit because a large number of web-servers doing client authentication are at ISP web-farms. Such an implementation would significantly reduce the costs & overhead for infrastructure administration of client authentication by providing a single structure implementation (across all client-authentication operations). It further has the advantage that the single adminstrative operation for doing all client authentication supports a variety of client authentication mechanisms on a per client/userid level (i.e. select userid/password, chap, public key, etc).

Note that the dominant form of client authentication in the web today ... userid/passwords (whether radius or not) works with standard browsers of today. code going out on sourceforce.net is plugins that support radius FIPS186-2, ecdsa signature authentication. this means that the identical same process for authenticating the ISP connection is then also available/usable for every other client authentication in the internet/web world (with support for graceful, account by account upgrade/transition).

This has the advantage of not being limited to just small number of web server client authentications (as in SSL-client auth) but all internet/web client authentications.

anders.rundgren@xxxxxxxx on 6/3/2002 1:37 am wrote:
Question: Does SSL-client-auth work without certificates? Using standard browsers of today.

some certification & authentication landscape summary from recent threads

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/03/2002 07:14 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
oh i forgot to ask ... you said that the swedish does a 50 cent(?) charge per OCSP transactions ... when the merchant/relying party sends in the OCSP request .... do they transmit the value of the transaction being certified? typically in risk management .... the entity accepting liability in connection with the transaction likes to have as good a handle on their exposure as possible ... aka ... not only the number of transactions but also the per transaction exposure.

Identity server infrastructure ... example

From: Lynn Wheeler
Date: 06/03/2002 07:17 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Identity server infrastructure ... example
example of Identity server infrastructure (both certificates and RADIUS ... possible to enhance RADIUS with fips186-2 ecdsa digital signature authentication).


http://wwws.sun.com/software/products/identity_srvr/ds_identity.html

LDAP userid/password
X.509v3 digital certificates
RADIUS
Public service provider


landscape & p-cards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/05/2002 06:11 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: landscape & p-cards
I'm not sure about "my way".

I worked with this small client/server startup in menlo park that wanted to do electronic payment transactions. Putting up this thing that was the original payment gateway ... in insisted that this thing they had invented called SSL do "mutual" authentication (this was back before there was SSL3) ... and i believe was the original implementation that had both client and server doing certificate based authentication. both the ability to do payments on these servers and the use of client-based certificates seems to have a fairly wide world-wide deployment. is that what you are referring to as "my way".

the case for AADS came out of the observation that even tho there were client certificates in the payment gateway case ... all the actual business processing was being done based on accounts ... the certificates were a momentary facade based on the fact that was the way the SSL code worked ... not how the business process worked. In effect, that once the SSL code had done its bit, its way ... there was a business process implementation that did its thing with accounts. misc. refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

or is it this thing called the internet .... misc. refs:
http://www.garlic.com/~lynn/internet.htm#0

the internet is disruptive technology ... being "open" and getting to be ubiquitous (compared to the earlier closed networks). the transition from close to open has increased the requirement for authentication technology. Passwords have been a weaker authentication technology as well as becoming more cubmersome as electronic world expands and requirement for (shared-secret) passwords to be unique in every domain. the issue with certificates is that they really have a design point for the offline environment. the question then is whether the future is going to be online paradigm or offline paradigm. certificates really are a stale, static, (read-only), trusted copy of some information sitting around in some account record. the purpose of the certificate is to provide a copy of that stale information when it isn't practical to access the real information.

now as to P-cards. the question is what is the primary business driver for p-cards ... 1) outsourcing the business or 2) lack of in-house connectivity. If the primary business driver for p-cards is lack of in-house connectivity ... then there is some reasonable expectation that as business connectivity increases, that purchase operations return more in-house. if a primary business driver for p-cards has been outsourcing to more experienced and scalable operations ... then it is likely that p-cards become more prevalent.

a slightly related subject is that in the US, a majority of transit funding comes from the federal government. The federal government have been telling transit authorities that they need to be getting out of the money collection business and turn it over to organizations that specialize in such activity ... and concentrate just on what they are funded for ... moving people. Presumably the reasoning 1) is that organizaitons that specialize in moving money can do it more efficiently than various transit authorities and 2) it shouldn't be necessary for the federal gov. to be subsidizing development and enhancement of transit-specific money collection and management systems (when there are financial institutions that specialize in such activity).

in the p-card case (& in transit) there is big difference between real-time auth and the offline stuff that might be done with credentials (aka ... 7-8 years ago ... it was pointed out that credentails were analogous to the signing limit checks ... but then it was observed that one of the reasons for migration to p-cards was there was still fraud with signing limit checks ... offline model didn't support real-time and/or transaction aggregation). while the internet is inexpensive, reduces the cost of doing business and is heading towards providing online ubiquitous connectivity ... one of the reasons that it is inexpensive is just exactly that ... it is inexpensive (aka there are things like SLAs lacking).

there was an incident a couple years ago where processing center had divergent routing and redundancy ... with multiple central exchanges feeding into the facility from different physical directions and different physical wires. The central exchanges are suppose to automatically reroute if there is a problem from any one direction. this rerouting is suppose to be under a minute. this particular case, the rerouting was delayed 17 minutes real time. this caused ceo level discussion with the phone entity. imagine large number of facilities not able to execute transactions (transit or retail) during peak rush hour.

note that the p-card question implies expectation of online, ubiquitous connectivity ... and is with regard to an online p-card question is with respect to one online implementation (slightly more expensive ... until you take into consideration availability and scaleability) and another online implementation.

applying a similar expectation of online, ubiquitous connectivity ... is what raises the issue regarding certificates & certificate based PKI which were invented specifically for addressing an electronic but offline paradigm ... aka there wasn't going to be any facitlity for directly connecting to the certification authority and/or the authoritative agency for the information being certified (aka in the SSL domain name certificates, while there is a "certification authority" it is typically certifying information that it has checked on with the authoritative agency as to the validity of the information). If the authoritative agency with regard to the information being validated was online line with ubiquitous connectivity ... then certificates become redundant and superfluous ... as well as any certification authority (separate from the authoritative agency).

anders.rundgren@xxxxxxxx on 6/4/2002 4:56 am wrote:
Lynn, I don't believe (note, "believe" not know for sure), that this where I see the market go.

I.e. I don't believe that TTP CAs issuing one-to-many credentials, should ever be liable for anything but their own activities including the identity of the certified entity. For the latter that liability is likely to be only in the range of $10000-$100000. If you need more you will have to pay a big premium. And if relying parties require more, they will get no customers.

Identrus is though heading your way but I have not [yet] seen any signs of the B2B-industry buy into their lawyer-centric stuff. VeriSign is good enough and is much easier to buy. I don't really see we have a problem with B2B-PKI except that business systems do not support PKI. I.e. their "account records" has neither support for certificates nor for public keys.

=========================================
But I know that you think differently and so do many PKI
promotors.  I still think we have not seen the winner yet.
Status quo beats PKI and AADS by a mile.  Unfortunately.
=========================================
Although interesting, we'd better terminate this thread and give room for other interesting payment-related stuff.

Proposed subject: What does P-Cards have for "reason to live" in an on-line society? My answer: null. 3D Secure et al makes centrally maintained profiles a thing of the past.

Anders


Credit card fraud sending night-vision rifle scope to criminal

From: Lynn Wheeler
Date: 06/06/2002 04:18 AM
To: epay@xxxxxxxx
Subject: Credit card fraud sending night-vision rifle scope to criminal
http://www.csmonitor.com/2002/0605/p01s04-wome.html

Microsoft Trustbridge ... Kerberos (tickets) support

From: Lynn Wheeler
Date: 06/06/2002 01:31 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Trustbridge ... Kerberos (tickets) support
http://news.com.com/2100-1001-933297.html?tag=fd_top

note that pk-init draft (rev 15 recently expired and draft 16 is yet to go up) specifies initial authentication to kerberos server via public key mechanisms.

AADS Chip Strawman & aSuretee

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 08/01/2002 12:58 PM
To: epay@xxxxxxxx
cc: 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: AADS Chip Strawman & aSuretee
I mentioned several times over the past four years the AADS Chip Strawman that I had been working on (for strong authentication)
http://www.garlic.com/~lynn/x959.html#aads

I also gave a talk on it at the Intel Developer's Forum last year, including a claim that pretty much as it currently existed, it could do all the things that were requirement for trusted computing module. A copy of this presentation is also at the above URL (slides on assurance).

ATM Scams - Whose Liability Is It, Anyway?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/13/2002 09:50 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: ATM Scams - Whose Liability Is It, Anyway?
--ATM Scams - Whose Liability Is It, Anyway?

American Banker Tuesday, August 13, 2002

By David Breitkopf

As the topic of fraud at automated teller machines commands increasing attention, some observers fear that conflicting interests among the banks and vendors involved - particularly over liability - will snarl industrywide efforts to correct the problem.

Bankers say they have only begun to understand the range of problems associated with skimming.

"It's uncharted territory right now," said Robin Nenninger, the executive vice president and manager of ATM operations at U.S. Bancorp. "I do think you'll be looking closer at the contracts to decide where the ultimate liability lies. You want to protect yourself, but you also want to solve it for the industry."

Henry Polmer, a partner at the law firm Piper Rudnick LLP in Washington, is part of a task force examining the matter. "Everyone wants to cure the problem, but what happens if there's a large loss?" he asked. "Who's liable? At some point, there could be finger-pointing."

On July 23 the Electronic Funds Transfer Association organized a meeting of nearly every interested party to work on collective solutions, specifically to the growing problem of skimming. This type of fraud involves stealing PIN numbers and other card data, often through devices attached to the machines, and using the data either to manufacture fraudulent cards or to loot bank accounts.

Because many of the entities represented at the meeting had conflicting interests, Mr. Polmer and others expressed concern that the "ATM Integrity Task Force" that was set up at the meeting might not be able to sustain a united front.

"The potential for disputes between the parties over their liabilities to each other lies just below the surface," he said.

The task force includes officials from ATM manufacturers, banks, independent sales organizations, the card associations, electronic funds transfer networks, software companies, and law enforcement. Since skimming could be fostered by negligence on the part of any of the entities involved in a transaction - from the card-issuing bank all the way back to the ATM manufacturer - all manner of finger-pointing is possible.

Complicating the situation is a patchwork of regulations governing these transactions, along with the fact that law enforcement is reluctant to pursue skimming thefts unless the amounts involved are substantial.

Consumers who report unauthorized transactions to their card issuers in a timely fashion are made whole by their bank and protected against losses by the EFT Act, the Federal Reserve's Regulation E, and card association rules such as zero liability.

Nevertheless, consumers could be vulnerable to identity theft, which could destroy their creditworthiness for years. Identity-theft victims complain that local police departments tend to be powerless to help them and that working with federal law enforcement tends to be difficult.

Though issuers are the first to take the hit when consumer accounts are attacked, network rules can make the merchant-acquirer or ISO liable to the issuer if account data and PINs were not properly encrypted at the ATM. Nonbank ATM owners and ISOs, in turn, may be contractually liable to the merchant-acquiring bank.

"Of course, everyone turns ultimately to the ATM manufacturers to see whether they have accurately certified the compliance of their machines with network rules," said Mr. Polmer.

At the task force meeting, a number of members said that it is nearly impossible to locate a machine at which a fraud was perpetrated.

One of the suggested solutions was to give ATMs identification numbers - similar to the vehicle identification numbers on cars - so the machines could be more easily tracked. However, that alone would not guarantee that law enforcement would be able to determine which ATM has been compromised.

Card-issuing banks in particular are interested in being able to identify which machines were used in the crime to help determine liability.

"If they know whose ATMs caused those cards to be compromised, then the cardholder's bank will be able to allege that that machine was not secure," Mr. Polmer said. Otherwise, the issuing bank would end up paying for the fraud, he said.

If the issuing bank could identify the acquiring bank responsible for the ATM, the acquiring bank would then seek to move the liability further down the food chain, often to the ISO that deployed the machine.

H. Kurt Helwig, the executive director of the Electronic Funds Transfer Association, of Herndon, Va., said the task force did not want to discuss the potentially divisive issue of liability.

"I don't look at the task force as a vehicle to discuss liability issues," he said. "I suspect the attorneys of those companies will be dealing with those problems, but I think the goal of the task force is to work together to solve the issue or control it."

Nandita Bakhshi, the director of the deposit/payment product group for FleetBoston Financial Corp., said the question of liability remains cloudy. "I don't think we've gotten a good answer yet. That's an issue that needs to be discussed between the issuing banks, the acquiring bank, and the EFTA and the networks. These are evolving things. I don't think people anticipated these types of issues."

The weakest link in the liability chain could be the ISOs, the companies that put the ATMs or help finance the placement.

"Quite frankly, we're the last throat to choke," said Lance Setliff, the national sales manager for Momentum Cash Systems Inc., a Houston ISO.

Mr. Setliff said he doubts the merchants whose stores house the ATMs would be held liable, because most do not have enough money to cover the funds that a skimmer could steal. Last year, for example, a scam in New York netted about $3.5 million in only a few weeks.

Momentum Cash says that in recent months it has gotten much tougher about screening the people it hires as "dealers" to make arrangements with merchants. However, the ISO says that the rise of skimming was only one of the factors in its decision. Another is the spectacular bankruptcy last year of the Philadelphia-based Credit Card Center, the largest ISO in the United States, which made many merchants wary of doing business with ISOs, Momentum Cash says.

"We talked to merchants, and merchants know about that," Mr. Setliff said. "We took a black eye."


FSTC Announces Proximity Payment Trial

From: Lynn Wheeler
Date: 08/15/2002 04:11 PM
To: epay@xxxxxxxx
Subject: FSTC Announces Proximity Payment Trial

To FSTC Members and Friends
From Jim Salters, Director of Project Development, FSTC

The full project proposal and letter of intent can be downloaded at
http://fstc.org/projects/new.cfm#infrared

Questions and letters of intent should be directed to me (jim.salters@xxxxxxxx) or Zach Tumin (zachary.tumin@xxxxxxxx).
___________________

Executive Summary
  1. Overview

    FSTC proposes an initiative for its member financial institutions and technology companies to participate in the USC and Harex InfoTech Wireless Mobile Payments Trial. The trial will create a live commerce environment in which infrared-based (and RFID-based if desired) devices will be deployed, and user acceptance and behavior studied. FIs have the option of participating operationally in the test, in addition to directing the research.
  2. Deliverables

    The following are the deliverables to be produced as a result of completing the Project
    1. A design and implementation of an electronic issuing system for wireless proximity payments at USC, scalable for commercial release
    2. A report researched and prepared by USC's Marshall School of Business documenting customer/user acceptance issues in the use of infrared and/or RFID payment devices among USC students and staff
    3. A document detailing the issuing system requirements sufficient for large-scale commercialization of electronic issuing for wireless proximity payment
  3. Participation Requirements

    Total project budget is $576,000. FSTC members will be responsible for approximately 25%, or $148,000. Assuming that four financial institution participate, the cost per (FI) participant is $37,000 per member.
  4. Participation Benefits

    Participating FIs will leverage a $576,000 project with a $37,000 investment, and gain/receive
    • Research products valued at 5-6 times the purchase price
    • Invaluable experience implementing the infrared/RFID payment system
    • Customer contacts/touch/relations as issuer with USC students and staff
  5. Implementation Dates


The target project start date is August 27th, 2002, and will run September - June 2002/3.


RFC3354 Internet Open Trading Protocol Version 2 Requirements

From: Lynn Wheeler
Date: 08/15/2002 05:06 PM
To: epay@xxxxxxxx,: internet-payments@xxxxxxxx
Subject: RFC3354 Internet Open Trading Protocol Version 2 Requirements

A new Request for Comments is now available in online RFC libraries.

RFC 3354

Title: Internet Open Trading Protocol Version 2 Requirements
Author(s): D. Eastlake, III
Status: Informational
Date: August 2002
Mailbox: Donald.Eastlake@xxxxxxxx
Pages: 6
Characters: 9671
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-trade-iotp2-req-02.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt

This document gives requirements for the Internet Open Trading Protocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included.

Version 2 of the IOTP will extend the interoperable framework for Internet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms.

This document is a product of the Open Trading Protocol Working Group of the IETF.

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Credit Card Skimming Rising In The US

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 09/05/2002 08:53 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Credit Card Skimming Rising In The US

Credit Card Skimming Rising In The US
Bankrate.com

May 29 2002 : Losses to credit card skimming exceed USD 1 billion per year, and occur "anywhere credit cards are put into a point-of-sale database", due to transparent technology, says Brian Marr, of the US Secret Service. A skimmer acts "as a net [in taking] information off the card", Marr explains, and traps data from hundreds of credit cards, to "be downloaded into a computer and e-mailed anywhere in the world". In the past three years, skimmers have shrunk in size and are widely available online, whereas criminals previously "had to make a skimmer [themselves]", says Lou Struett, of Magtek, a manufacturer of mag-stripe card readers.

Card skimming is a big problem in Europe, Asia and Latin America, with Hypercom's George Wallner noting, "a Far East factory will do as many as 5,000 cards a night, and the next day those cards are in a suitcase on the way to Europe". Skimmers are available online from USD 300, and equipment to make a counterfeit credit card costs USD 5,000 to USD 10,000, and thieves can also slip a 'skimming bug' into an older credit card terminal, to retrieve the card data a few days later. In the US, a scam ring surfaced in April, in which two waitresses at an Orlando restaurant sold credit card data to a crime ring in Miami.

In a separate, "atypical" case, Hampton police charged an individual with credit card theft for opening a series of fake businesses and respective bank accounts. The man "also obtained a POS terminal" and "hundreds of credit card numbers", the Daily Press reports, "and in the evening, he would sit down and rack up sales with these businesses through this POS terminal, putting those sales into his accounts". Next day, he would "go around the different banks ...and withdraw funds against these sales", some of which exceeded USD 50,000 in one day, but the sharing of data by five different banks led to his arrest.

The major credit card firms, and technology vendors, are addressing the issue of skimming with new procedures and products designed to minimize the risk of card fraud. Migrating to chip-based cards under the EMV initiative will eliminate many of the problems associated with the cloning of payment data from a mag-stripe card, while the upgrading of POS terminals to accept chip-based transactions, eliminates the risk of terminals being 'bugged'. Gartner analyst, Jeff Roster, also believes that if POS terminals, such as Trintech's eVia terminal, are brought to tables in restaurants, the overall rate of skimming would drop.


Credit card theft feared in Windows flaw

From: Lynn Wheeler
Date:09/06/2002 08:16 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Credit card theft feared in Windows flaw
http://news.com.com/2100-1001-956729.html

x9.73 Cryptographic Message Syntax

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 09/27/2002 09:12 AM
To: epay@xxxxxxxx
Subject: x9.73 Cryptographic Message Syntax
X9.73 reconsideration is being finalized.

It references RFC 2630, CMS ... which has been obsoleted by 3369 (which also obsoletes RFC 3211)

3369 PS
Cryptographic Message Syntax (CMS), Housley R., 2002/08/30 (52pp) (.txt=3D113975) (Obsoletes 2630, 3211) (was draft-ietf-smime-rfc2630bis-08.txt)

there is also at the same time

3370 PS
Cryptographic Message Syntax (CMS) Algorithms, Housley R., 2002/08/30 (24pp) (.txt=3D51001) (was draft-ietf-smime-cmsalg-08.txt)

there is also:

3278 I
Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), Blake- Wilson S., Brown D., Lambert P., 2002/04i/30 (16pp) (.txt=3D33779) (was draft-ietf-smime-ecc-06.txt)

... i have a IETF RFC standards index at: http://www.garlic.com/~lynn/rfcietff.htm

from an x9.59 standpoint there is section 6.2 on Signed Data. and 6.2.5

Detached Signatures.

In the mapping of x9.59 to ISO 8583 an optimized transport was suggested which uses existing ISO8583 transport values with just the additional information needed to reconstruct & validate the senders signing.

from an 8583 perspective, effectively iso 8583 fields along with some additional values are marsheled into a block foi signing. The suggested use was fips186-2, ecdsa digital signature. A standard 8583 message then had the additional values and the digital signatures combined in a normal 8583 "addenda" field. The relying party (typically the consumer's issuing institution) receives the 8583 message and reconstitutes the originally signed message to perform the signature verification. In this scenario, the actual signed message is not transmitted in the original "signed format". The suggested mapping of X9.59 to iso 8583 eliminates the redundant transmission of elements in a standard iso 8583 message as well as eliminating any superfluous values not needed for the 8583 transaction and the verification of the signature on the transaction.

Fitting x9.59 specification suggested mapping to iso 8583 within the context of the x9.73 specification can either be viewed as a) detached signature (under 6.2.5) or possibly use the Signed Data format for signing and verification but not for actual transmission. Within the context of the x9.59 suggested mapping to iso 8583, certificates are redundant and superfluous when the public key has been registered with the consumer's

financial institution. The 6.2 Signed Data format allows that the certificate related material is OPTIONAL but there is:

SignerInfos ::= SET OF SignerInfo
SignerInfo ::= SEQUENCE {
version Version (v1 | v3, ...),
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] UnsignedAttributes OPTIONAL
}
values which are nearly all fixed in the suggested x9.59 mapping except for "sid".

SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
certHash [73] EXPLICIT Hash
}
The verbage for the sid field is
The sid field of SignerInfo identifies the signer's certificate. This standard provides three alternatives for identifying the signer's public key issuerAndSerialNumber, subjectKeyIdentifier, and certHash. The issuerAndSerialNumber alternative identifies the signer's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier identifies the signer's certificate by the X.509 subjectKeyIdentifier extension value; and the certHash identifies any certificate format.

==============

In the x9.59 to iso 8583 mapping, the public key has been registered with the consumer's financial institution, the consumer's financial instituion certifies that public key and registers it in the consumer's account record. There is two choices at this point, either

1) add a new choice for SignerIdentifier which indicates retrieve certified public key from consumer's account record, where the identification of the account record is included in the body of the transaction ... say something like "IssuerAccountNumber".

2) create a convention for interoperation of x9.59 mapping to iso 8583 within the CMS specification that "certHash" identification of any certificate format .... is an "account format" certificate (in this context). this account record is similar to a certificate LDAP operation ... except it occurs implicitly within the construct of an existing business process that is retrieving the record (although there could be provisions for realtime LDAP retrieval for non-legacy operations).

IBM launches smart-chip consultancy - Tech News - CNET.com

From: Lynn Wheeler
Date: 09/28/2002 07:10 AM
To: epay@xxxxxxxx
Subject: IBM launches smart-chip consultancy - Tech News - CNET.com
http://news.com.com/2100-1001-959991.html?tag=fd_top

Government of Canada Public Key infrastructure

From: Lynn Wheeler
Date: 10/12/2002 05:29 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Government of Canada Public Key infrastructure
http://www.cio-dpi.gc.ca/pki-icp/index_e.asp

Finance firms push messaging standards

From: Lynn Wheeler
Date: 10/16/2002 12:55 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Finance firms push messaging standards
http://news.com.com/2100-1023-962284.html?tag=fd_top_1
October 16, 2002, 11:25 AM PT

Seven top brokerage firms on Wednesday formally announced a coalition to promote the adoption of standards in the fragmented instant messenger industry.

As previously reported, financial services firms, including Deutsche Bank and J.P. Morgan Chase, this summer formed the Financial Services Instant Messaging Association (FIMA), formerly known as the Instant Messaging Standards Board (IMSB). The committee, which also includes representatives from Credit Suisse First Boston, Lehman Brothers, Merrill Lynch, Morgan Stanley, and UBS Warburg, publicly touted its lofty goal of fostering technical harmony among IM providers Yahoo, AOL, MSN and others


glossary

Refed: **, - **, - **
From: Lynn Wheeler
Date: 10/19/2002 09:18 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: glossary
I've done quite a few additions (over the past couple months) to the merged security glossary at
http://www.garlic.com/~lynn/index.html#glossary

up to date description
http://www.garlic.com/~lynn/index.html#glosnote

while the financial glossary is quite large .... i've been trying to get approval to include the most recent BIS (basel) glossary merged into the financial glossary. So far I haven't been able to find a contact to say one way or another. if anybody is knows of a contact at BIS that might be in position to approve the merginng of their glossary into my financial glossary, I would appreciate it.

bis is at:
http://www.bis.org/index.htm

glossary at:
http://www.bis.org/publ/cpss00b.htm#pgtop

San Diego Company owns e-commerce

From: Lynn Wheeler
Date: 10/23/2002 06:37 PM
To: epay@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: San Diego Company owns e-commerce
from:
http://yro.slashdot.org/yro/02/10/23/197234.shtml?tid=155
Kernel Panic writes Looks like you can now be sued for using graphical and textural content on your e-commerce site. As everyone who has an e- commerce site does. A company in San Diego was granted one patent for using graphics and text to sell things on the web and another for accepting information to conduct automatic financial transactions via a telephone line & video screen. They have started their crusade with smaller companies that do not have the financial resources to fight back so as to build a "war chest" to take on larger companies like Ebay and Amazon. One site has taken the offense after becoming one of the first defendants of 50 companies so far. Curiously it appears the company was formed in March of 2002, less than a month before filing for the first lawsuit.

REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles

From: Lynn Wheeler
Date: 10/24/2002 03:14 PM
To: epay@xxxxxxxx
Subject: REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles

Date: Tue, 22 Oct 2002 07:15:08 -0800
From: Rob Slade <rslade@xxxxxxxx>
Subject: REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles

BKSECXML.RVW   20020831

"Secure XML", Donald E. Eastlake/Kitty Niles, 2003, 0-201-75605-6,
U$44.99/C$69.99
%A   Donald E. Eastlake III
%A   Kitty Niles
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2003
%G   0-201-75605-6
%I   Addison-Wesley Publishing Co.
%O   U$44.99/C$69.99 416-447-5101 fax: 416-443-0948
%P   532 p.
%T   "Secure XML: The New Syntax for Signatures and Encryption"

Part one is introductory material. Chapter one is about XML (eXtensible Markup Language), but is not very clear, especially in regard to the relationship between XML, SGML (Standard Generalized Markup Language), and HTML (HyperText Markup Language). Security concepts do not play a big part. The tutorial on cryptography, in chapter two, is very simplistic, uses obtuse language, and is much harder on the reader than is really necessary.

Part two deals with the basics of XML. Chapters three through eight present some of the syntax and structure of XML documents, DTDs (Document Type Definitions), Schemas (particularly unclear), XPath, XPointer, and SOAP. That is about all they provide: the material is not helpful in explaining uses, or how the parts fit into a framework or package.

Part three covers canonicalization and authentication. Canonicalization is important to authentication, as chapter nine points out, because it allows us to eliminate meaningless differences between essentially the same file, as when different file systems use varying newline characters or sequences. Ordinarily, such differences would result in differences in hash code results, and therefore a false failure of authentication. Chapter ten outlines signature syntax, while eleven talks very briefly about the XMLDSIG standard for digital signatures, and twelve reviews the European Telecommunications Standards Institute's (ETSI) somewhat more advanced signatures.

Part four looks at keying, with the KeyInfo element in chapter thirteen, and XKMS key management in fourteen. Chapter fifteen, on the proposed XMLENC standard, and sixteen, containing some discussion of combinations of encryption and signatures, make up part five. Part six, entitled "Algorithms," reviews algorithm specification, in chapter seventeen; available algorithms, in eighteen; and related non- cryptographic algorithms, in nineteen.

The writing is turgid, almost deliberately dense, and fails to provide necessary tutorial details. Those who are well familiar with XML will find some particulars regarding the specific encryption documents, but few others will find the work useful.

copyright Robert M. Slade, 2002 BKSECXML.RVW 20020831 rslade@xxxxxxxx rslade@xxxxxxxx slade@xxxxxxxx p1@xxxxxxxx http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade


First International Conference On Trust Management

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date; 11/04/2002 05:46 PM
To: epay@xxxxxxxx
Subject: First International Conference On Trust Management

++++++++++++++++  CALL FOR PAPERS  ++++++++++++++++++++

The First International Conference
              On Trust Management

                 28-30 May 2003

Heraklion, Crete, Greece

          (http://www.eBusinessCity.org)

The First International Conference on Trust Management will take place
at the beautiful summer resort Kalimera Kriti (Good Morning Crete)
(http://www.kalimerakriti.gr/) near Heraklion, Crete, Greece, on May
28-30 2003. The Conference is organized by iTrust, a Working Group on
Trust Management in Dynamic Open Systems (http://www.itrust.uoc.gr/)
and the University of Crete (http://www.uoc.gr) and partially funded
by the Future and Emerging Technologies (FET) unit of the IST program
(http://www.cordis.lu/ist/fethome.htm).

The Proceedings will be published by the Lecture Notes in
Computer Science (LNCS) series of Springer Verlag,

http://www.springer.de/comp/lncs/index.html Its purpose is: To facilitate the cross-disciplinary investigation of fundamental issues underpinning computational trust models by bringing together expertise from technology oriented sciences, law, philosophy and social sciences. To facilitate the emergence of widely acceptable trust management processes for dynamic open systems and applications To facilitate the development of new paradigms in the area of dynamic open systems which effectively utilise computational trust models. To help the incorporation of trust management elements in existing standards Papers, short papers, panel, special session and tutorial proposals are solicited in the following list of areas which is indicative and not exhaustive: - The ethics, sociology and psychology of trust - Cyberspace freedom vs. safeguarding consumer confidence and trusting relations. - Legal issues underpinning the management of trust - Trust in Contract, service level agreement negotiation and management, organizational networks - Models and semantics of trust - Trust specification, analysis and reasoning - Trust based on recommendation and reputation - Design of trust based architectures and decision-making mechanisms for e-community and e-service interactions - Monitoring trust - Relationship between trust and risk - Relationship between trust and security Keynote Speaker Stuart Feldman, IBM VP Internet Technology, USA Program Committee ( means confirmation pending) Christos Nikolaou, U. of Crete, Greece, Conference Chair Paddy Nixon, U. of Strathclyde, UK, Program Chair Nikos Alivizatos, U. of Athens, Greece Eliza Bertino, U. of Milano, Italy Jon Bing, NRCCL, U. of Oslo, Norway Joan Borrell, Autonomous University of Barcelona, Spain Cristiano Castelfranchi, CNR, Italy Stefano Cerri, U. of Montpellier II, France Theo Dimitrakos, CLRC, UK Valerie Issarny, INRIA, France Keith Jeffery, CLRC, UK Christian D. Jensen, Trinity College, Ireland & DTU, Denmark Andrew Jones, King's College, UK Audun Josang, DSTC, Australia Graham Klyne, Nine by Nine, UK Heiko Krumm, U. of Dortmund, Germany Manolis Marazakis, Plefsis, Greece Stefan Poslad, Queen Mary College, UK Dimitris Raptis, Intracom, Greece Jakka Sairamesh, IBM Research, USA Giovanni Sartor, U. of Bologna, Italy Simon Shiu, Hewlett Packard, UK Morris Sloman, Imperial College, UK Ketil Stoelen, SINTEF, Norway Yao-Hua Tan, Free University of Amsterdam, Holland Sotirios Terzis, U. of Strathclyde, UK Dimitris Tsigos, Virtual Trip Ltd, Greece Stavroula Tsinomera, U. of Crete, Greece Emily Weitzenboeck, NRCCL, U. of Oslo, Norway Paper Submission Papers should be submitted electronically in PDF, HTML or MS-Word format, either by e-mail to the Conference Secretariat (info@xxxxxxxx ) or to our ftp site (ftp://ftp.eBusinessCity.org). In either case, please follow the guidelines below: 1.In your submission, there should be only one file containing the paper text, suitable for review printing (maximum 20 printed pages with font size not less than 10pt). 2.Each figure (or other material except text) should be in a separate file 3.All files consisting your paper should be gathered in a single file (zip or tar format) 4.Submit your paper either by e-mail or ftp (please note that electronic submissions are obligatory) 5.Send a separate e-mail message to info@xxxxxxxx containing the paper title, abstract, keywords and any relevant contact information. All accepted papers for the conference will be published by the LNCS series of Springer-Verlag. Please consult the Authors Instructions subpage (http://www.springer.de/comp/lncs/authors.html) as well as to the Editors Instructions subpage (http://www.springer.de/comp/lncs/editors.html) on the LNCS Home Page where answers can be found to most technical questions. Short Papers During the conference a space will be reserved for short paper sessions. Research projects of any scale are invited to illustrate innovative concepts and prototype systems. Short paper proposals should include title, names of presenters and outline (max. 500 words). Electronic submissions are obligatory; proposals should be submitted by e-mail to the Conference Secretariat, info@xxxxxxxx Panels/Special Sessions chair Christian D. Jensen, Trinity College, Ireland & DTU, Denmark Suggestions for the organisation of panel sessions on one of the proposed topics or on related topics are welcomed. Proposals should include a short CV and position paper for each panellist, and should be sent to Christian.Jensen@xxxxxxxx Tutorial chair: Theo Dimitrakos, CLRC, UK Proposals for tutorials are solicited. Tutorials would be either half day (3 hours) or full day (6 hours). Each proposal should include a title, a summary (intentions, objectives, etc.), duration and a short CV of the instructor(s) and should be sent to T.Dimitrakos@xxxxxxxx Demo chair: Dimitris Tsigos, Virtual Trip Ltd, Greece Result demonstrations of on-going projects are strongly encouraged. Those interested should submit a description of the intended Demo to tsigos@xxxxxxxx Local Organizing Committee Christos Nikolaou, U. of Crete, Chair Eva Michelidaki, U. of Crete, Dissemination Calliope Anagnostopoulou, U. of Crete, Local accommodations Shore Shadman, U. of Crete, Registration Kyriakos Papadakis, U. of Crete, Webmaster Michalis Klisarchakis, U. of Crete, Webmaster Vasilis Poursalidis, U. of Crete, Networking & Systems Elias Theoharopoulos, U. of Crete, Networking & Systems Important Dates Submission of papers: January 6 Submission of panel or special session proposal: March 30 Submission of tutorial proposal: March 30 Submission of demo proposal: March 30 Notification of panel or special session acceptance: April 15 Notification of tutorial acceptance: April 15 Notification of demo acceptance: April 15 Notification of paper acceptance: March 10 Submission of final version: March 31


GAO Government Agencies Adhering to Privacy Laws

From: Lynn Wheeler
Date: 11/04/2002 05:41 PM
To: epay@xxxxxxxx
Subject: GAO Government Agencies Adhering to Privacy Laws
On 30 Oct 2002, the General Accounting Office issued a report "Information Management: Selected Agencies' Handling Of Personal Information" finding that the Departments of Agriculture, Education, Labor, and State generally adhere to government privacy laws. "The report found that agencies' handling of information varies and that a wide range of government personnel have access to the information, but by and large, the agencies follow current privacy laws." (Information considered included names, phone numbers, addresses, SSNs, financial and legal data, and demographic information, provided for a specific purpose such as to receive benefits, obtain services or loans, or participate in a specific federal program.)

[Source: Eric Chabrow, InformationWeek, 30 Oct 2002; PGN-ed]
http://news.lycos.com/news/story.asp?section=Politics&storyId=556059

Meeting to mull privacy standard's next step

From: Lynn Wheeler
Date: 11/11/2002 05:26 PM
To: epay@xxxxxxxx
Subject: Meeting to mull privacy standard's next step
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,75814,00.html

Workship on Human/Computer Interaction and Security systems

From: Lynn Wheeler
Date: 11/11/2002 01:31 PM
To: epay@xxxxxxxx
Subject: Workship on Human/Computer Interaction and Security systems

http://www.iit.nrc.ca/~patricka/CHI2003/HCISEC/index.html

SAML Just The Start For Web Services Security

From: Lynn Wheeler
Date: 11/11/2002 09:45 PM
To: epay@xxxxxxxx
Subject: SAML Just The Start For Web Services Security
http://itmanagement.earthweb.com/columns/secugud/article/0,,2771_1498491,00.html

Cardtech/Securtech aSuretee press release

From: Lynn Wheeler
Date: 11/20/2002 08:30 AM
To: epay@xxxxxxxx
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Cardtech/Securtech aSuretee press release

http://www.firstdata.com/news_article.jsp?nID=1813

Liberty Alliance Waves White Flag at Passport

From: Lynn Wheeler
Date: 12/03/2002 06:19 AM
To: epay@xxxxxxxx
Subject: Liberty Alliance Waves White Flag at Passport
http://www.eweek.com/article2/0,3959,740753,00.asp

First Data Unit Says It's Untangling Authentication

From: Lynn Wheeler
Date: 12/06/2002 09:48 AM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: First Data Unit Says It's Untangling Authentication
AADS press release ... also
http://www.garlic.com/~lynn/x959.html#aads


http://www.firstdata.com/news_article.jsp?nID=1813

First Data Unit Says It's Untangling Authentication

From: Lynn Wheeler
Date: 12/09/2002 01:37 PM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: First Data Unit Says It's Untangling Authentication
cross-post thread from another mailing list:
http://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication

and somewhat related thread in sci.crypt ng:
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to

VeriSign unveils new online identity verification services

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/11/2002 09:49 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: VeriSign unveils new online identity verification services
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,76558,00.html
Trust services vendor VeriSign Inc. today unveiled a new online identity- verification service that allows Web customers to positively establish their identities with online merchants.

The new Consumer Authentication Service (CAS) provides online businesses with instant, round-the-clock information taken from more than 50 public and private databases to ensure a customer's identity, said Anil Chakravarthy, director of product management for VeriSign's enterprise group.

The information comes from state motor vehicle department, government, credit bureau and telephone number databases, Chakravarthy said. Optimized scoring models are used to help businesses quickly and easily determine whether potential buyers are who they claim to be.

The services, which are charged to the businesses on a per- transaction basis by Mountain View, Calif.-based VeriSign, vary with the importance of the identity checks.

The services aren't for typical retail online sales but could be used by online auction houses such as eBay or similar businesses to establish the identities of first-time customers seeking credit accounts, Chakravarthy said.

"It makes very good sense for the online auction house to check on you" to reduce fraud, identity theft and other problems, he said.

The new service uses a predefined set of XML standards to connect to an enterprise's customer-facing Web application. The authentication data entered by the consumer is then automatically routed using XML and encryption through VeriSign's services and is checked against varied databases to cross-verify and risk-rank the consumer identity in real time. Verification is then automatically sent back to the enterprise application and to the consumer, using underlying XML data.

The communication is secured with Secure Sockets Layer encryption that is already built into standard Web servers and browsers.

"We take extraordinary measures not only to be highly secure ... but also we take extraordinary care to ensure the privacy of this information," Chakravarthy said.

VeriSign had previously offered such services only to online auction vendors but is now making the services available to a broader audience.


MaterCard test high-tech payments

From: Lynn Wheeler
Date: 12/13/2002 10:08 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: MaterCard test high-tech payments
http://news.com.com/2100-1001-977829.html?tag=fd_top
MasterCard tests high-tech payments

By Alorie Gilbert
Staff Writer, CNET News.com
December 13, 2002, 8:01 AM PT

MasterCard is testing a new credit-card system designed to speed the payment process at check-out counters and replace cash transactions at places such as movie theaters and fast food restaurants.

The system, called MasterCard PayPass, allows consumers with specially equipped credit cards to simply tap or wave their cards against a reader to make a payment, rather than having to swipe the card. If the value of the purchase is under a certain amount, the cardholder needn't sign a receipt.

The cards come embedded with hidden computer chips and radio antennae, which transmit payment details wirelessly. The cards can also be used with traditional magnetic stripe readers.


... snip ...

eBay Customers Targetted by Credit Card Scam

From: Lynn Wheeler
Date: 12/13/2002 10:12 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: eBay Customers Targetted by Credit Card Scam
http://news.bbc.co.uk/1/hi/business/2564725.stm
eBay Customers Targetted by Credit Card Scam

By Stefan Armbruster
BBC News Online business reporter

The world's largest online auction site eBay has been targeted by fraudsters using a shadow site to steal credit card details from its 55 million customers.

The scam involved sending e-mails to customers asking them to log on to a Florida-based website - ebayupdates.com - and re-submit their financial details.


... snip ...

eBay Customers Targetted by Credit Card Scam

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/14/2002 01:44 PM
To: Drsmith <drsmith@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: eBay Customers Targetted by Credit Card Scam
note that the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

has definitions that supports signing all financial transactions ... aka part of the task given the x9a10 working group for x9.59 payment standard was all retail payments (not just internet, not just face-to-face, not just pos, not just non-face-to-face, not just credit, not just debit, not just stored-value, ... but ALL) ...
http://www.garlic.com/~lynn/x959.html#x959

and also piloted in the NACHA debit network trial .... pointer at:
http://www.garlic.com/~lynn/x959.html#aads

basically some amount of AADS has focused on standards support for FIPS186-2, ecdsa/x9.62 digital signature standard as means of authentication ... and the aads chip strawman basically focused on just doing FIPS186-2, ecdsa/x9.62 digital signing. Note that the standards activity of having FIPS182-2, ecdsa/x9.62 digital signature standard as means of authentication doesn't mandate that it be done with a hardware token. the protocol specification of FIPS186-2/x9.62 authentication is independent of the environment that performs the signing. The issue of whether it is some PC software, or PDA software, or hardware and/or what kind of hardware token is an integrity and business issue. The protocol part can be common to all implementations ... and the end-point implementation then is purely a business & integrity issue (1-factor, 2-factor, 3-factor authentication, and/or integrity level of the components).

The other part is that possibly over 90 plus percent of the internet-related authentication events occur with RADIUS ... aka majority of the isps internets & corporate internets. aads enhanced radius has been demo'ed a number of times .... misc. discussions
http://www.garlic.com/~lynn/subtopic.html#radius


Another major authentication process that goes on in the world today is the kerberos based stuff supported by most of the operating system platforms (and not solely internet). the original kerberos standard has been shared-secret based ... however there is a draft standard to extend it to include public key based authentication that includes both certificate-based public key as well as certificate-less (aka AADS) based public key
http://www.ietf.org/ids.by.wg/krb-wg.html
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt

other discussions of upgraded the current certificate-based SSL public key infrastructure to certificate-less based infrastructure:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

basically, any shared-secret, pin/password based infrastructure can be upgraded by using the same business process ... but with a public key, non-shared-secret based paradigm (and can all be supported by a single asuretee hardware token).

for more information on kerberos & radius authentication standards ... go to
http://www.garlic.com/~lynn/rfcietff.htm

and under RFCs listed by select Term (term->RFC#); from there it is possible to select RADIUS from the Acronym fastpath .... aka
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


or scroll to kerberos ... aka:
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411

drsmith@xxxxxxxx on 12/14/2002 9:53 am wrote:
Those signing devices you refer to should not be limited to ecom. Face to face transaction need something similar. "Who is this person checking my signature and what qualification do they have?" I ask this question every time, especially this time of year after the fear mongering of the Associations to encourage checking of cards . We should not limit solutions to one medium this creates differences in our payment habits and further confuses the masses, lemmings that they are. To find a secure solution that does not bridge multiple mediums will go the path of SET.

eBay Customers Targetted by Credit Card Scam

Refed: **, - **, - **
From: Lynn Wheeler
Date: 12/14/2002 02:49 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: eBay Customers Targetted by Credit Card Scam
ref: previous posts
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam

so another AADS based implementation is SSH .... i build a table of acceptable public keys .... and then they can be used to authenticate. so an enhancement to SSH would be to add fips186-2/x9.62 ecdsa support to standard SSH distribution. then you can use a hardware token or a pda that supports simple fips186-2/x9.62 ecdsa digital signatures to sign x9.59 financial transactions (all forms), radius logins of your PPP connections (just about all ISP, DSL, dial, etc), as well as all kerberos, and then ssh. nothing special in the token needs to be aware of anything ... other than it is signing a message ... and the same token can be used for everything that requires a fips186-2/x9.62 ecdsa digital signature.

.... misc. ssh refs:
http://www.openssh.com/
http://archive.erdelynet.com/ssh-l/
http://www.ssh.com/

[IP] The 20th anniversary of the Internet (fwd)

From: Lynn Wheeler
Date: 12/15/2002 05:32 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: [IP] The 20th anniversary of the Internet (fwd)
somewhat related discussions :
http://www.garlic.com/~lynn/internet.htm#0

also for index of rfcs ... see
http://www.garlic.com/~lynn/rfcietff.htm

Date: Sat, 14 Dec 2002 14:02:54 -0500
Subject: [IP] The 20th anniversary of the Internet
From: Dave Farber <dave@xxxxxxxx>
To: ip <ip@xxxxxxxx>
Sender: owner-ip@xxxxxxxx

I still have the button and still have the memories of tht week djf

------ Forwarded Message
From: Bob Braden <braden@xxxxxxxx>
Date: Sat, 14 Dec 2002 10:08:38 -0800 (PST)
To: ietf@xxxxxxxx
Cc: internet-history@xxxxxxxx
Subject: The 20th anniversary of the Internet

We ought not to let pass unnoticed the impending 20th anniversary of the Internet. The most logical date of origin of the Internet is January 1, 1983, when the ARPANET officially switched from the NCP protocol to TCP/IP. Six months later, the ARPANET was split into the two subnets ARPANET and MILNET, which were connected by Internet gateways (routers).

The planning for the January 1983 switchover was fully documented in Jon Postel in RFC 801. The week-by-week progress of the transition was reported in a series of 15 RFCs, in the range RFC 842 - RFC 876, by UCLA student David Smallberg.

There may still be a few remaining T shirts that read, "I Survived the TCP/IP Transition". People sometimes question that any geeks would have been in machine rooms on January 1. Believe it!! Some geeks got very little sleep for a few days (and that was before the work "geek" was invented, I believe.)

So, on New Year's Eve, hoist one for the 20th anniversary of the Internet.

Bob Braden
____________________________________________________

Routers brought to you by Bob Hinden of BBN.

Prominent survivors included Dan Lynch of Interop fame.
And of course Vint Cerf was working the Levers of Power at
ARPA.


Briwn gets creatuve with wireless

From: Lynn Wheeler
Date: 12/14/2002 05:48 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Briwn gets creatuve with wireless
http://news.com.com/2100-1033-977868.html?tag=fd_top
Brown gets creative with wireless

By Ben Charny Staff Writer, CNET News.com December 13, 2002, 1:06 PM PT

United Parcel Service said Friday it has stitched together a network using two wireless technologies to speed package processing at hundreds of its shipping hubs.

The shipping giant, which calls itself "Brown" in its advertising, is beginning to deploy a tracking system that combines the Wi-Fi and Bluetooth wireless technologies. Bluetooth can carry data over several feet, while Wi-Fi has a 300-foot range, making it a popular method of extending Net access in many homes and business.

UPS representative Ginnie Myhr said 55,000 package handlers eventually will get Bluetooth bar code readers that are worn on the finger like a ring. The ring scans a package label and sends the information to a Wi-Fi radio attached to a handler's belt. The radio then sends the information to a central computer.

UPS is testing the new system in four hubs, and it plans to install the gear inside 1,700 U.S. package-sorting centers by 2004, Myhr said.

The system uses equipment built by Symbol Technology.


... snip ...

Who owns the methods of E-commerce?

From: Lynn Wheeler
Date: 12/16/2002 07:27 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Who owns the methods of E-commerce?

http://www.informationweek.com/story/IWK20021212S0010
Patenting The Process Dec. 16, 2002

Who owns the methods of E-commerce? Many companies say they do and that they have the patents to prove it. By John Soat

"Obviously, if all video on the Web infringes on their patent, you'd think they'd go after the big guys, but they seem to be going after little content providers who can't afford to fight them in court. I can't help but feel like I'm being shaken down by the hi-tech version of Tony Soprano. ..."

Strong words, even for a message board on the Internet. Mitigated, perhaps, by the poster's nom de Web: Spooky Suicide. And when you find out Mr. Suicide operates a (self-described) "slightly naughty" Web site known as "Suicide Girls," you may begin to suspect there's more than a little pot-versus-kettle syndrome at work here.

But this post is only one of many that have popped up over the last several weeks, mostly in chat rooms and on message boards frequented by operators of adult Web sites, in reaction to a company called Acacia Media Technologies. Acacia has contacted the companies to advise them that they're violating Acacia's patents for accessing or downloading digital video and/or audio over the Internet, and they must license the technology. Included in the communications are explanations of the patents and a royalty schedule for payments. Acacia has filed lawsuits alleging patent infringement against 27 adult-entertainment companies, though none of the suits has yet been served.


... snip ...

Web services specs focus on security

From: Lynn Wheeler
Date: 12/18/2002 08:11 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Web services specs focus on security
http://news.com.com/2100-1001-978314.html?tag=fd_top
Web services specs focus on security

By Martin LaMonica

Staff Writer, CNET News.com December 18, 2002, 6:22 AM PT

A group of companies led by IBM and Microsoft on Wednesday published a series of specifications designed to make Web services more secure.

The proposed specifications describe how companies can establish policies on exchanging information among trading partners and how to make disparate security systems interoperate. IBM and Microsoft co- authored the specifications with input from a limited number of companies, including BEA Systems, RSA Security and VeriSign.

The companies will incorporate industry feedback and submit the specification to a standards body early next year, executives said.


... snip ...

Invisible Ink, E-signatures slow to broadly catch on

Refed: **, - **, - **
From: Lynn Wheeler
Date: 12/19/2002 04:50 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Invisible Ink, E-signatures slow to broadly catch on

http://cbs.marketwatch.com/news/story.asp?guid=%7B4CB87141%2D6DB9%2D427E%2DA46F%2DC0147B881307%7D&siteid=mktw
Invisible ink
E-signatures slow to broadly catch on
By Barbara Kollmeyer, CBS MarketWatch
Last Update: 1:26 AM ET Dec. 19, 2002

LOS ANGELES (CBS.MW) -The advent of electronic signatures heralded a new age in online commerce -- a numeric code to replace an individual's handwriting to register agreement.

Yet since President Clinton signed the Electronic Signature Act over two years ago (see related story), indications are few companies are taking full advantage. While little hard data exists, consumers have been slow to embrace the technology due to fear of fraud and a lack of understanding, experts said.


... snip ...



Invisible Ink, E-signatures slow to broadly catch on

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 07:43 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on
Forwarded from something I ran across somewhere else ....
Lets hypothesis an industry with a business model that every year they would sell a shiny new $100 credential to every person in the world ... and are finding out that nobody is buying the credential.

Lets say that they go to business organizations and enlist them in getting laws passed based on credentials being equivalent to human signatures with the characteristics of non-repudiation (and furthermore, everybody has to get one).

From the consumer's standpoint, non-repudiation means that in a dispute the legal burden of proof is shifted from the merchant to the consumer. Furthermore, the only thing that is necessary to achieve this, is to define a new bit in the credential (and the new laws).

From the business standpoint ... the credential isn't costing them any money ... the consumer is paying for it ... and it has the advantage of shifting the burden of proof away from the business to the consumer.

Some of the draft laws even refer to how all consumers are extremely eager to participate in such wonderful new technology (they just can't wait to get their shiny new credential every year and how shiny new credentials make them feel so good and safe). It is like they don't even have to perform a digital signature ... they just wave their shiny credential over the bits and everything is just magically blessed with non-repudiation and the burden of proof shifted to themselves and how such actions just bring such uncontrollable joy to their hearts.


Invisible Ink, E-signatures slow to broadly catch on

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 08:42 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on
but it isn't the credential that magically enables all of that.

it is the business process behind what the credential represents that is the actual enabler; as well as any trust in those background business processes. That is totally separate from the additional burden represented by establishing trust in the credentialling process itself.

the credendtial just is used to represent the background business process in an offline environment when there isn't direct access to the real online business process.

much of the world has been migrating to online, all-the-time, everywhere for some time.

The majority of the world today in financial related activities of value are using online operations that directly link to the background business processes in real time. Directly connecting to the background business processes in real time for things of value makes the stale representation by the credential redundant and superfluous.

Typically a credential can only represent a stale, static, much restricted subset of information that is of interest in any transaction involving value. Such value transactions typically are interested in not only the subset of the information that might be represented by the (stale, static) credential but also timely information that involves things like aggregation and current status. It is left to operations of no value and either incapable or not justified use of online environment (with timely and/or aggregated information) that credentials can find a market niche.

anders.rundgren@xxxxxxxx on 12/20/2002 8:17 am wrote:
Or put in another way ....

A credential issued through a global trust-network of banks

A credential allowing organizations to safely open their intranets to the Internet

A credential eliminating the ocean of passwords that plague users and help-desks

A credential that when revoked disables all access

A credential that when reissued restores all access

A credential that is conveniently carried in a mobile phone

A credential that allows you to pay, bank, identify, B2B, e-Gov etc.

... could maybe be worth some $25-$50 / Year

Anders


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 09:08 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
    "Robert E. Frank" <bobfrank@xxxxxxxx>,
"Ed Gerck" <egerck@xxxxxxxx>, epay@xxxxxxxx,
"internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
... and for market niche of no or little value .... it would be difficult to justify charging very much for a credential that is only enabling no/little value operations/transactions. If very little is being charged for a no/little value credential ... it would be somewhat difficult to fund an expensive background business process (for representation by the credential). Typically highly trusted business process cost more than no-trusted business process. So the correllary is likely to be that inexpensive, little/no-value credentials for use in little/no-value transactions are likely to have little (business process) trust.

Looking at it from the reverse viewpoint, transactions of value today are using online access to the real backroom business process because the timeliness and quality of the information (including things like up-to-date aggregated information) subsumes the function of having a stale, offline representation. The issue can be viewed as a risk cost/benefit proposition. Timely, online access to the real backroom business processes is likely to cost more than using an offline, stale, static paradigm. The risk of performing a transaction with stale, static, offline information is higher than real timely access to online information. The issue is that as online all-the-time, everywhere becames less expensive and more pervasive, the niche for stale, static offline credential operations becomes smaller. In otherwards, it becomes easier and easier to justify the cost of an online oriented paradigm for value operations as online paradigm becomes less expensive and more pervasive.

lynn.wheeler@xxxxxxxx on 12/20/2002 8:42 am wrote:
but it isn't the credential that magically enables all of that.

it is the business process behind what the credential represents that is the actual enabler; as well as any trust in those background business processes. That is totally separate from the additional burden represented by establishing trust in the credentially process itself.

the credendtial just is used to represent the background business process in an offline environment when there isn't direct access to the real online business process.

much of the world has been migrating to online, all-the-time, everywhere for sometime.

The majority of the world today in financial related activities of value are using online operations that directly link to the background business processes in real time. Directly connecting to the background business processes in real time for things of value makes the stale, static representation of the credential redundant and superfluous.

Typically a credential can only represent a stale, static, much restricted subset of information that is of interest in any transaction involving value. Such value transactions typically are interested in not only the subset of the information that might be represented by the (stale) credential but also timely information that involves things like aggregation and current status. It is left to operations of no value and either incapable or not justified use of online environment (with timely and/or aggregated) information that credentials can find a market niche.


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:32 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, Ed Gerck <egerck@xxxxxxxx>,
    epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
OCSP only tells you whether the certificate information is valid or not.

lets say it is a financial transaction.

the financial transaction wants to know the current balance or credit limit (which is a real-time aggregated amount .... i.e. some previous value plus all transactions todate).

so in a certificate world ... we put the current bank amount and/or current credit limit in the certificate (ignore for the moment the privacy issues).

the merchant gets the certificate ... and then does the OCSP .... which is the chance the current, real-time value is in any way related to the stale, static value deposited in the credential.

So we now have progress:

we can do away with the credential all together ... and always just do the OCSP ... and the OCSP doesn't actually have to say what the current credit or balance is ... it just has to say whether the transaction is approved or not (addressing some serious privacy issues in placing current balance/limit in a certificate which gets broadcast all over the world). now it turns out we can call this new kind of OCSP transactions an ISO8583, X9.59 digital signed transactions for all financial transactions.

The actual problem is that information about whether you are entitled to perform an operation (aka you are the actual owner of the account) which is a only small subset of the information of interest in performing a financial transactions. In fact, almost all merchants from the standpoint of a financial transactions ... don't give a darn about who you are (which is typically the information carried in a privacy-invasive identity certificate) ... but want to know whether they are going to get paid. Knowing that they are going to get paid is of significant more interest than knowing who you are. Knowing who you are can actually be considered irrelevent in a 8583/x959 financial transaction.

If a merchant was given a choice of doing either

1) do an OCSP transaction to find out if you are still who you are

or

2) do a iso8583/x959 transaction to find out if they are going to get paid

Which do you believe a merchant will choose ... finding out if you are still you ... or finding out if they are going to get paid?

So with a little simplification, we have now eliminated all transactions that involve financial matters.

So what other transactions of value do you have in mind where:

1) the information in the certificate is totally sufficient by itself ... w/o any additional recourse, for supporting the business operation

2) there is no privacy issues when the necessary and sufficient information by itself is broadcast all over the world.

For long detailed discussion of SLL web domain name server certificates business:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

There have been all sorts of temporary market niches in the internet world that doesn't necessarily actually represent a sound, fundamental. longterm viable business proposition.

Summary of the above:

1) SSL domain name server certificates invented to address integrity concerns/exposures with the domain name infrastructure
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

2) SSL domain name server certificates were quick&dirty fix to those integrity issues pending fixes for the basic infrastrucutre

3) Even then the basic business premise is flawed since the certification authorities are dependent on the domain name infrastructure as the authoritative agency regarding who owns a domain name

4) The irony is that the certification authority business has proposals to improve the integrity of the domain name infrastructure ... so that they can trust the information they are certifying as to who owns as domain name

5) Improving the integrity of the domain name infrastructure (for purposes of the certification authority business to trust) then starts the slippery slope invalidating the original premise for having the certificates in the first place.

I've replayed this discussions tens if not hundreds of times .... SSL domain name certificates (which we were somewhat involved in as per refs in #1 above when as part of enabling this thing called electronic commerce for doing financial transactions ... my wife and i had to perform due diligence several of the major certification authorities) are a quick & dirty fix to a online business integrity issue. Fixing that online business integrity issue ... eliminates the need for the offline certificates. Furthermore, there is some irony that the certification authorities are pushing fixing integrity business issues because they are also dependent on the same institutions for the validity of the information that they are certifying.

I would, in fact, claim that the existanfe of the SSL domain name certificate business ... supports the contention that it is a market niche pending having the real online business ... aka in this particular scenario the real online business exists and has for some time ... it just is that there have been integrity issues ... and as soon as the integrity issues for the online business processes are fixed then the need for the SSL domain name certificate quick&dirty fix goes away. In fact the SSL domain name certificate business is pushing those fixes because they need it or there is then trust issues with the information they are certifying. They can do all the certification they want ... but if the source of the information is bad .... what they have certified is bad.

anders.rundgren@xxxxxxxx on 12/28/2002 9:49 am wrote:
VeriSign's 500 000 Web-server certificates/year seems to contradict the statement that there is no money in TTP-issued credentials. One can argue about the quality of this but not the money :-)

Using OCSP, off-line "stale" credentials becomes "live" and on-line.

The alternative, having a unique credential at each resource provider is ineffective and slows down the use of "e-services".

The real problem is that no matter what system you use, there is a risk that the person in the other end is not the one it should be due to credential theft, loss and to some extent due to CA errors.

/a


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 01:33 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
but as already pointed out in past investigations the banks don't accept a random TTPs issued cert (whether using OCSP or not). They issue relying-party-only certificates .... for privacy and liability reasons. The certificate just contains the account number .... any other information is privacy-invasive. So while the certificate appears like issued from a TTP ... it is in fact, from a business process standpoint issued by the financial institution that is executing the transaction.

ok, have been around the relying-party-only certificate by financial institutions numerous times before .... in much the same way have been around the ssl domain name cert:
http://www.garlic.com/~lynn/subtopic.html#rpo

so investigating what happens with a relying-party-only-certificate ... the financial institution registers the person's key, stores it in their account record and issues a certificate .... also stored in the account record.

Rather than the RPO case ... lets look at vanilla TTP w/OCSP case (possibly 3d secure)

a single message comes with

A) the ISO8583 transaction ... 50 bytes,
B) the digital signature ... 20-40 bytes
C) the certificate ... 4kbytes to 12kbytes

the bank looks up the account record from the ISO8583 message and checks for open to buy ... it is now ready to reply ... except it has to
1) find the CAs public key,
2) check the trust hierarchy (which could involve large amount of network chatter)
3) validate the certificate key
4) use the public key from the certificate to validate the financial transaction digital signature
5) contact the OCSP (which involves more network chatter)
6) do this in under 350milliseconds (the avg. elapsed time for the original payment gateway roundtrip)

previous refernce to the original payment gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

So now .... we examine the RPO case
1) eliminated ... bank is the CA
2) eliminated ... bank is the trust hierarchy
3) bank validates their own certificate signature
4) use the public key from the certificate to validate the financial transaction digital signature
5) eliminated ... bank account is the OCSP

now the RPO case still has the bank validating its own signature and the humongous payload bloat caused by the certificate. X9.63 has done a lot of work on certificate compression because of the humongous bloated penalty that certificates place on the financial transaction network. So, compression can use a technique of field elimination if the relying-party already possesses the field. It is possible to show that the relying-party for a financial transaction already possesses all fields of interest that might be in the certificate. As a result it is trivial to show (using X9.63) techniques that the certificate in "C" can be reduced to zero bytes .... significantly reducing the bloat and penalty placed on the financial network. The problem is that there is still this transmitted certificate (even if it is only zero bytes) that needs to have the signature verified.

so the RPO case goes to the next level of optimization. In addition to compressing the certificate to zero bytes ... the signature on the certificate is verified when the certificate is original issued and deposited in the account record. Since the bank knows that only valid information is being placed in the account record .... it is not possible for the CA's signature on the certificate to change after it has been deposited in the account record. So it follows, that it is not necessary to perform subsequent checks at every transaction as to the validity of the bank's own key.

So in the optimized version we have:

A) the ISO8583 transaction ... 50 bytes
B) the digital signature ... 20-40 bytes
C) the compressed certificate ... 0 bytes

And because validation is done at the time the information is entered into the account record, the transaction becomes
1) read the account record from the ISO 8583 transaction
2) use the public key in the account record to validate the signature on the ISO 8583 transaction
3) possibly do the operation in a single network round-trip of avg. 350milliseconds.

This is very close to what is defined for ISO8583 X9.59 financial payment standard (including the part of compressing the certificate to zero bytes)
http://www.garlic.com/~lynn/x959.html#x959

and is also very close to what NACHA implemented for the ISO8583 debit network trials
http://www.garlic.com/~lynn/x959.html#aadsnacha

This is also the KISS principle applied to digital signature infastructures:
http://www.garlic.com/~lynn/aadsm10.htm#hackhome Hackers Targeting Home Computers
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss3 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
http://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
http://www.garlic.com/~lynn/aadsm7.htm#3dsecure 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes
http://www.garlic.com/~lynn/aepay3.htm#gaping gaping holes in security
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2001l.html#1 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001l.html#3 SUNW at $8 good buy?
http://www.garlic.com/~lynn/2002b.html#22 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
http://www.garlic.com/~lynn/2002k.html#43 how to build tamper-proof unix server?
http://www.garlic.com/~lynn/2002k.html#44 how to build tamper-proof unix server?
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#27 Root certificate definition
http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI

anders.rundgren@xxxxxxxx on 12/20/2002 11:30 am wrote:
- Using 3D Secure the bank (issuer) would check the TTP-issued cert using OCSP
- Then it would check the account
- And if it looks OK sign the transaction to the merchant
- Privacy is fairly OK unless it is a problem that the bank knows your favorite merchants

BTW, I think that 3D, SAML et al will create a market for TTPs that did not exist a year ago.


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 03:55 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
      epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
somewhat total aside .... first time i ran into x.500/x.509 was at an acm sigmod meeting. My wife and i were doing this high availability, no single point of failure, high performance, high integrity, scalable database work as part of the ha/cmp product:
http://www.garlic.com/~lynn/subtopic.html#hacmp

anyway, the person at the sigmod meeting was explaining x.500 as a bunch of network gurus busily re-imventing 1960s database technology. the work that went along with it for x.509 was (extremely privacy invasive) identity certificates (which represented some information supposedly contained in this x.500 1960s-era database entries).

There was some reference that these network gurus may have been the same people that brought us OSI. Misc. references to OSI and what went wrong:
http://www.garlic.com/~lynn/subtopic.html#xtphsp

so one of the distinction often cited about the difference between ISO and IETF (besides the difference between OSI and TCP/IP) is it is possible for ISO to pass standards that may never, ever be implemented (and in fact could be such that they aren't actually implementable in any practical since). For some of the IETF standards process description go to:
http://www.garlic.com/~lynn/rfcietff.htm
and scroll down in the main frame to the description of the standards process and the requirement for two interoperable implementations for standards progress.

So about the time we were doing the HA/CMP product stuff we were also doing the hsdt project
http://www.garlic.com/~lynn/subtopic.html#hsdt
and internet stuff
http://www.garlic.com/~lynn/internet.htm#0

and doing some stuff with high speed protocol. Part of the ISO issue of passing standards that might not be implementable ... is that they can also make rulings that additional standards work can't be done unless in conforms to earlier standards activity (which might not be actually implementable). Now ISO is somewhat schizo about this in the area of OSI ... and things like IEEE (ISO chartered group) and LAN standards. LAN standards effectively collapse OSI levels 1, 2, and part of 3 into a single layer .... quite definately violating OSI. So we were doing some stuff on HSP (high speed protocol) which would go directly from level 4 (transport) interfacing directly to the LAN/MAC layer. This would also violate OSI since it jumped the interface betwen layer 3 & 4 ... and went directly to the middle of layer 3 ...... which is where LAN interface sits. One of the more schizo of the ISO organizations is US chartered X3S3.3 ... responsible for network level 3&4 standards .... which had a strong ruling that it was not possible to do HSP as defined .... going directly from transport to LAN/MAC interface. Anothe example of little problems with ISO network related standards activity.

In any case, in the HSP work .... it also looked at reliable, high-performance transactions. HTTP (& HTTPS) uses TCP. TCP has a minimum of 7 packets to perform reliable session/transactions. There was some looking at VMTP which accomplishes the same thing in 5 packets. VMTP/RFC1045:
http://www.garlic.com/~lynn/rfcidx3.htm#1045

However, with a little more work, HSP came up with a reliable transaction protocol that could be done in three packets. Slight thread drift (which helps me remember VMTP being RFC1045) is that I had done the RFC1044 implementation that shipped in mainframe TCP/IP product:
http://www.garlic.com/~lynn/rfcidx3.htm#1044
which had the slight characteristic that the base implementation got about 44kbytes/sec thruput using a full 3090 engine .... while the enhanced 1044 implementation got 1mbyte/sec thruput (hadware media thruput) using about 1/50th as much processing (twenty times the thruput using 1/50th the pathlength).

So getting back to the discussion about SSL domain name certificates. In the thread
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#26 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#57 Cirtificate Authorities 'CAs', how curruptable are they

as well as several other SSL domain name certificate threads:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

I make the assertion that not only does fixing the integrity of the domain name infrastructure (on behalf of the certification authorities) sows the seads of eliminating the SSL domain name certificates ... but also opens the opportunity for simplifying (KISS) the SSL protocol.

So current process is somewhat:
1) contact domain name system to get the ip-address that corresponds to the domain URL
2) minimum 7 packet for reliable TCP for HTTP/HTTPS
3) certificate transmittal
4) ssl protocol chatter
5) hypothetical trust hiearchy network chatter to obtain necessary signing certificates to validate certificate
6) hypothetical OSCP network chatter to check on the status of each of the signing certificates
7) hypothetical OSCP network chatter to check on the status of the domain name certificate
8) the misc. digital signature verifications with all the various public keys
9) once the SSL session has been setup the client transmits the SSL transaction request
10) the server finally gets the SSL transaction requests, does whats needed
11) replies to the SSL transaction request
12) client gets the rsponse and tears down the SSL/TCP session

Now, part of improving the domain name infrastructure integrity ... somewhat on behalf of the certification authority industry ... is that when a domain name is registered, the entity also registers a public key. This doesn't include a certificate ... it is just the registration authority part of public key registration that is done at the same time as registering the domain name (this is akin to when somebody creates an account they supply their mother's maiden name or some other supposed secret, it isn't necessary to have identification ... it is just that the registering entity is the one also providing the authentication material).

So the domain name infrastructure already has the ability to serve up all information registered with a domain name .... so the new scenario is
1) contact domain name infrastructure and get ip-address, public key, and whatever else may be registered (possibly including server's preferred SSL parameters if they so desire).
2) client creates a piggybacked xtp transaction packet that has the selected ssl parameters and the session key encrypted with the server's public key, followed by the encrypted transaction session information packet ... all in one transmission
3) server receives the piggybacked xtp transaction packet and unwinds it all and performs the requested transaction
4) server responds with piggbacked xtp transaction containing the (encrypted) response and the session tear-down
5) client response with tear-down acknowledgement

So eliminating the SSL domain name certificate not only gets rid of the whole certificate stuff ... but eliminates huge amount of network chatter or nattering on as one reply to the following post suggested:
http://www.garlic.com/~lynn/2002p.html#30 Sci Fi again

Basically single round trip to get the domain name information followed by single round trip to do the SSL transaction.

ssl certs

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 07:41 PM
To: epay@xxxxxxxx
Subject: Re: ssl certs
the authoritative agency for who owns a domain name is the domain name infrastructure. A certification authority has to check with them regarding the validity of the application for the SSL domain name certificate. The certification authority just certifies the information that they have checked about with the domain name infrastructure. I'm not saying that once they have generated a certificate ... that the certificate can be changed.

I've saying that the domain name infrastructure has had instances of domain name take-over. Somebody (fraudulently) takes over a domain name and then applies to the certification authority for a SSL domain name certificate. The certification authority just verifies all the information .... which is then correct and then generates a certificate based on the information that they have verified with the authoritative agency for the information that they have certified.

So one of the proposals .... somewhat motivated by the certification authority institutions, is to have domain name applicants register a public key at the same time they acquire/register their domain name. Then all further communication between the domain name owner and the domain name infrastructure is via digitally signed messages. These digitally signed messages don't require a certificate since the messages are being sent to the domain name infrastructure which will verify the digital signature with the public key on file. The objective is to improve the integrity of the domain name infrastructure, making domain name take-over more difficult, and improving the trust that there would be in the validity of ssl domain name certificates which are generated by certification authorities ... certifying information that is on record with the domain name infrastructure.

Now the irony .... is that the registering of the public key .... on behalf of the certification authority industry .... and using a certificate-less process .... is part of the process that starts the process leading to SSL domain name certificates being made redundant, superfluous and unnecessary.

In this case, I'm not making any references to whether SSL certs (once issued) are corruptible or not. I'm making a reference to the fact that traditionally security is only as good as the weakest link. The weakest link in this case is possibly not the SSL certs ...... it is the whole backroom business process associated with the information that the SSL certs represent, specifically the domain name infrastructure. However, it has been integrity issues with the domain name infrastructure that gave rise to the need for SSL certs in the first place.

The irony is that correcting the integrity issues with the domain name infrastructure ... on behalf of the certification authority industry ... starts down this slippery slope of making the SSL domain name certificates redundant, superfluous and unnecessary.

refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

now ... as in previous discussions ... there may or may not be additional information in the ssl domain name certificates ... but in fact any additional information in the ssl domain name certificate is not part of the SSL protocol and is probably viewed less than a couple hundred times around the world. Basically, in addition to fraudulently having done a domain name take-over .... the only other thing that is frequently checked is that there is a D&B entry that corresponds to the listed owner of the domain name. It is possible to trivially generate a valid D&B entry for some business name and have that D&B entry correspond to the listed owner for the domain name that has been taken over. That is usually sufficient to satisfy requirements regarding the obtaining of a valid certificate. The fact that the business name might not be the one expected by clients ... is of sufficiently small problem to be non-existant since effectively nobody actually ever looks at SSL domain name certificates.

t.c.jones@xxxxxxxx on 12/20/2002 5:56 pm wrote:
Lynn: you seem to say that SSL certs are corruptable, but that doesn't square with my experience. If the cert is correctly issued by the CA (usually true.), then the consumer should be able to rely on the assertion that the web page contains an offer that is really from the merchant. What else is needed?

If you are aguing that there could be a better way, that is always true of any system. What about the SSL cert system fails today. (Other than an attack on the browser, which is a different story altogether.)

..tom


ssl certs

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:12 PM
To: epay@xxxxxxxx
Subject: Re: ssl certs
say there is a fly by night crook ... you set up a dummy company and get a valid D&B entry.

you do a domain name take-over ... using the dummy company name ... and then apply for a SSL domain name certificate relying on the fact that the domain name infrastructure points to the dummy company name.

You contract with some webhosting system with you dummy company .... to have it all setup remotely. Nobody ever sees you. Nobody ever looks at the content of the SSL certificate ... and the SSL protocol only checks that the domain name in the certificate matches the domain name name in the URL the client typed in.

The goal and the effect is nearly identical to ip-address take-over scenario ... which is supposedly the whole reason for SSL certificates ... but only slightly more complicated. The crook has a fraudulent webserver that everbody believes is valid ... the same as in the ip-address scenario ... but this time the SSL certificate attests to it also. The root problem is the same ... integrity issues in the domain name infrastructure.

The SSL certificate stuff was a quick&dirty patch on the domain name infrastructure with respect to ip-address take-over. However, it effectively did absolutely nothing to handle other integrity issues in the domain name infrastructure that can lead to the same exact fraud as ip-address take-over. The actual difficulty in achieving this is only moderately more than the ip-address take-over scenario and the associated risk/rewards are well within possible fraud with fake web servers.

The whole point of having SSL certificates was a quick and dirty patch up for an integrity issue with ip-address take-over in the domain name infrastructre ... however it leaves wide the domain name take-over scenario that can result in the same exact fraud that the SSL certificates are suppose to prevent (and the domain name take-over exploit is only slightly more difficult and expensive that the basic ip-address take-over scenario).

So the certificate authority industry have come up with suggestions to improve the integrity of the domain name infrastructure .... helping close the holes that SSL certificates are still open for ... resulting in the same exact fraud scenario that SSL certificates are suppose to prevent.

As previously stated .... the irony is that improving the integrity of the domain name infrastructure .... starts to eliminate the justification for having the SSL certificate quick & dirty fixup in the first place aka if the domain name infrastructure has eliminated integrity issues that make it prone to take-over of any kind (ip-address take over or domain name take over) .... then the SSL certificate quick & dirty fixup is no longer needed.

The whole point of having SSL certificates has been a quick & dirty fixup to the integrity hole in the domain name infrastructure with regard to "take-overs". It turns out that it only addressed one part of the take-over scenarios ... not all of them. Fixing the domain name infrastructure so the possibility for all take-overs can be eliminated .... eliminates the need for having a SSL certificate quick & dirty fixup (since the fundemental problem has been corrected and there is no longer need for the SSL certificate quick & dirty fixup).

ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

eliminating take-over exploits in the domain name infrastructure eliminates the major original justification for SSL domain nameq certificates ... so we are now down to a side issue .... which was incidental to the SSL certificate patchup for the take-over scenario ... and that is trusted key exchange. Now there are a number of methods for doing trusted key exchange. A generic one is when one end generates a session secret/symmetric key and encodes/encrypts it with the public key of the other party (but there are others).

So the other part of the certification authority industry suggestion for improving the integrity of the domain name infrastructure to eliminate take-over situations is to have a public key registered at the same time that the domain name infrastructure is registered. That helps that assure the integrity of the information being certified .... as opposed to improving the integrity of the certificate .... it improves the integrity of the information in the certificate.

Now, if we have a public key registered with the domain entry .... for purpose that the domain name owner signs all email with their private key (something that the certification authority industry is interested in) ... then it is possible for the domain name infrastructure to transmit that public key as part of domain name resolving ... at the same time it transmit the resolved ip-address for the domain name. That method of trusted real-time public key distribution then can be used by the client for encrypting the generated secret/symmetric secret key as described in:
http://www.garlic.com/~lynn/aepay10.htm#77

taking care of the residual justification for having SSL certificates.

t.c.jones@xxxxxxxx on 12/20/2002 8:38 pm wrote:
Allow me to use your favorit arguement. The business case here is clear. If you steal a company's name, logo, or other IP, you will wind up with at least a major suit from the company that owns that IP, and perhaps more if it is shown to be fraud. You could become a 10-year room-mate of some Enron big- shots.

We should not rely on technology to solve these obvious cases of fraud, we have lots of history dealing with fraud and should allow those mechanisms to function.

I beleive that with SSL we have all of the technology and legal solutions that we need today. What we need is the means to display this information securely to the consumer and get their informed consent to the transaction.
..tom


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:44 PM
To: Einar Stefferud <Steflist@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>, Ed Gerck <egerck@xxxxxxxx>,
    epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
as discussed in the rest of this thread and the side thread
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs

is that the whole SSL certificate infrastructure is already based on domain name infrastructure .... w/o any real contractual warrant. The domain name infrastructure is the authoritative agency for domain name infrastructure.

You can either contact the domain name infrastructure directly w/o contractual warranty and get the information directly

or

You can have an SSL certificate containing information where the certification authority has contacted the domain name infrastructure directly w/o any contractual warranty. There is the possibility that there is a contractual warranty by the certification authority that it has reliably contacted the domain name infrastructure with regard to validating the information. So that is the merchant comfort certificates ... that certification authorities will possibly warrant that they have contacted the domain name infrastructure.

from
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
some past merchant comfort certificate threads:
http://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#mcomf3 Human Nature
http://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert6 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert7 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert8 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert9 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert10 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert11 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert12 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert13 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert15 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert17 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay6.htm#dspki use of digital signatures and PKI
http://www.garlic.com/~lynn/2000c.html#32 Request for review of "secure" storage scheme
http://www.garlic.com/~lynn/2001c.html#62 SSL weaknesses

einar stefferud on 12/28/2002 9:50 pm wrote:
Unfortunately, from my long experience with the DNS and ICANN travails, I must report that your trust in the contents of a DNS query response is unwarranted. We only trust it now because monetary transaction security considerations are not involved in DNS resolver code.

As soon as you load the DNS with some required monetary trustworthiness, it is subject to severe compromise.

Note that in essence you are back to trusting VERISIGN without benefit of any contractual warranty of any kind regarding an ability to rely on the response delivered by the DNS Resolution service.

I seriously doubt that you really want to go there!...\Stef


SSL certs & baby steps

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 12:39 AM
To: epay@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
Ed Gerck <egerck@xxxxxxxx>,
    internet-payments <internet-payments@xxxxxxxx>
Subject: SSL certs & baby steps
so lets step back and look at it in smaller baby steps

domain name infrastructure has integrity issues that can result in both ip-address take-over as well as domain name take-over.

ssl domain name certificates are targeted at detecting ip-address take-over situations (by detecting that a fraudulent web server doesn't have a certificate matching the expected domain name).

ssl domain name certicates don't address the domain name infrastructure integrity issues associated with domain name take-over ... leaving the possibility of undetected fraudulent web servers.

so a couple items from the original electronic commerce stuff

1) my wife and I coined the term certificate manufacturing to distinquish the deployed ssl domain name certificate quick & dirty patch ... from a PKI

2) my wife and I wrote up some stuff about things that might be certified as to the validatity and/or integrity of merchant sites ... which were never adopted.

so lets step back from my assertion about domain name infrastructure server up public keys along with ip-address for domain names.

a side observation ... while domain name infrastructure may have no warranties with respect to financial dependent transactions ... the web and any related financial transactions are depedentent on the domain name infrastructure correct operation in order to operate. The ssl domain name certificates don't prevent ip-address take-over ... it just provides a mechanism for detecting it. This possibly removes some number of fraud motives for doing an ip-address take-over. however, other reasons for ip-address take-over ... like denial of service attacks can still occur, and potentially bring all such financial transactions to a stop. So while there is no warranty with regard to guaranteeing correct financial transactions ... there still is significant financial exposure if such financial transactions were prevented. Whether there are warrenties or not ... the financial impact is nearly as bad if the domain name infrastructure doesn't have the integrity to restand denail of service attacks is signficant (even if one doesn't believe the domain name infrastructure will have the warranties to back actual financial transactions).

so lets look at a little baby step that results in the domain name infrastructure serving up a public key along with the ip-address for a domain name.

lets say instead of registering just the public key in the domain name infrastructure an abbreviated domain name certificate was registered aka domain name, public key, certification authority digital signature and a certification authority identification. Instead of serving up a "bare" public key ... lets suppose that the domain name infrastructure serves up such an enhanced public key. what are the differences from the current environment.

1) current environment is dependent on the correct operation of the domain name infrastructure to function

2) current environment uses ssl domain name certificates to detect ip-address take over (doesn't prevent them, just detects them).

3) real-time serving of an abbreviated certificate will work correctly when the domain name infrastructure is working correctly

4) any failure in the real-time serving of an abbreviated certificate will result in an ip-address take over being detected.

I claim that there is no security and/or integrity difference whether such a certified public key comes from the webserver (as in the current implementation) or from the domain name infrastructure.

It addresses any suggestions that the fundamental holes in the domain name infrastructure with respect to ip-address take-over may take some time to fix and the quick & dirty fixes are with us for some time to come.

It also has the characteristic that the domain name infrastructure can "revoke" a certificate in real time by deleting it from the domain name entry (and no longer serving it up). This allows effectively much of the business characteristics of a full-blown PKI ... while not requiring the client to implement any additional OCSP and/or CRL complexity stuff.

the domain name infrastructure isn't at any more risk than it is today with the SSL certificates coming from the webserver. It still is subject to denial of service attacks because of attacks resulting in incorrect operation. However, the availability of a valid abbreviated certificate can detect an ip-address take-over ... and an incorrect certificate and/or a missing certificate won't result in a valid SSL connection by a fraudulent he.

webserver domain name infrastructure serves up public key ... just as in my original description ... but allows that integrity issues with respect to ip-address take-over not being fixed for some time to be accounted for.

It also has the advantage that when operating correctly the effect of PKI management of manufactured certificates is provided for w/o actually involving any client implementation. It doesn't prevent any attacks on the domain name infrastructure that result in incorrect operation and effectively denial of service (which is exactly the same in either SSL domain name certificate operation).

the issue is that as (or if) domain name infrastructure comes to be trusted ... the per transaction verification of the signature on the abbreviated certificate no longer has to be performed .... but the data flows and the implementation operation stay the same.

Of course, this by itself does nothing to address the issue of domain name take over integrity issues ... other than in the existing proposal that a public key be registered when the domain name is registered ... and that all future communication between the domain name owner and the domain name infrastructure is digital signed (and can be verified with the public key on file for the domain). The public key on file can be encoded as a bare public key ... or as part of an abbreviated certificate that is digital signed by a certification authority. However, has detailed in the related description for financial transactions with public key on file ... it isn't necessary to revalidate the certification authority's signature once the public key is reliably added to the account record.

I assert that this intermediate step retains all the integrity characteristics of the currently deployed ssl domain name certificate infrastructure ... with the added advantage of:

1) the effective equivalent of PKI management of manufactured certificates is achieved by being able to eliminate/remove the certificate from the domain name database entry (and not serve it up ... which would achieve the same thing as daily distribution of CRLs to every possible client in the world &/or an OCSP implementation by every client in the world)

2) the ability to create a highly optimized SSL transaction implementation since the client can have all the necessary information prior to initiating the webserver communication.

3) at some point when the integrity issues with the domain name infrastructure are resolved ... and issues like denial of service attacks are eliminated, then the public key and process data flow stays exactly the same .... except that the bare public key can be distributed w/o the accompanying certificate envelope.

SSL certs & baby steps (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:18 AM
To: epay@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
    Ed Gerck <egerck@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>
Subject: SSL certs & baby steps (addenda)
there are integrity and vulnerability issues with the domain name infrastructure

these integrity and vulnerability issues can result in various kinds of "take-over" exploits.

the SSL domain name certificates are designed to detect ip-address take-over exploits (not prevent them) ... and do nothing to detect other kinds of take-over exploits.

not detecting an exploit can lead to fraudulent transactions resulting in a financial impact

detecting an exploit will effectively degenerate to a denial of service exploit

integrity and vulnerability issues with the domain name infrastructure can result in various kinds of denial of service exploits

denail of service exploits of the domain name infrastructure can result in significant financial and economic impact, possibly on par with fraudulent transactions.

just detecting an exploit and changing it from a fraudulent transaction exploit to denial of service exploit would still represent a signficant financial and economic impact

it is possible to take a baby step for real-time distribution of public keys by the domain name infrastructure .... compared to the current infrastructure

this baby step can compensate for existing domain name infrastructure integrity issues by having the public key signed (as opposed to distributing naked public keys)

the current SSL domain name operation is a certificate manufacturing infrastructure w/o the certificate management characteristics necessary for a PKI

the baby step distribution of real time public keys can provide effectively the characteristic of management of public keys ... by deciding whether or not to distribute the public key

the baby step is consistent with the certification authority business proposal for addressing domain name take-over exploits (registering public keys with the registering of the domain name).

the baby step doesn't address the elimination of denial of service exploits (any more than the current SSL domain name certificates do).

with the baby step there can still be denial of service attacks on the domain name infrastructure

the baby step of adding public key distribution to the domain name infrastructure provides public key management capability significantly more efficiently than either distributing CRLs to every potential client in the world and/or having clients execute OCSP transaction.

the baby step is consistent with some future real time distribution of "naked" public keys (w/o the signing envelope) at some future time when the integrity and vulnerability issues of the domain name infrastructure have been sufficiently addressed. there are significant financial and economic justification for addressing these integrity and vulnerability issues just based on the impact of denial of service exploits.

neither the existing ssl domain name certificate infrastructure nor the baby step prevent ip-address take-over exploits and both just turn an ip-address take-over exploit into a denial of service exploit.

neither the existing ssl domain name certificate infrastructure nor the baby step prevent denial of service exploits

he baby step with real time distribution of public keys (whether enveloped with signature for additional integrity or "naked") is consistent with the certification authority business proposal for improving the integrity of the domain name infrastructure by addressing domain name take over exploits by registering public keys in the domain name database entry.

SSL certs & baby steps

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:47 AM
To: t.c.jones@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
Ed Gerck <egerck@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>
Subject: Re: SSL certs & baby steps
we beleive one of the reaons that our earlier proposal for enhancemed merchant certification didn't catch on was that electronic commerce on the web has been extremely bi-model; something like 70 percent of the transactions are done by some 50-60 sites and something like 90 percent of the transactions are done by 200 sites.

reputational buying decisions are very concentrated for those 90 percent of the transactions ... i.e. you have done it before, your friends have done it, it is on the T.V. etc.

The straight forward enhanced certification process provided little or no additional useful information for the buying decision involving something like 90 percent of the web transactions. The URL itself was sufficient recognition and either the current SSL (or the baby step) precluded fraudulent transactions from ip-address take-over attempts (but none provided any additional benefit for the myrid of denial of service exploits). Because of the concentration of transactions the trust has been widely established for URL for the majority of the transactions.

The financial and economic impact for the 90 percent of transactions on the internet is in the area of denial of service exploits (attacks on the web services and/or attacks on the domain name infrastructure). this is because the transactions are so concentrated and reputational information is available because the person has made prior purchase, they know somebody that has made purchases and/or because of TV and other kinds of advertisement.

The place for enhanced certification process was for the remaining ten percent of the transactions spread across the millions of remaining web sites. The problem seemed to be the economic cost/benefit for enhanced certificate process for the millions of web sites based on it only was a factor in ten percent or less of all web transactions.

There was some proposal of possibly having an online BBB or some sort of state/fed licensing board site that would give real time statistics about complaints, resolutions, etc. This would have meaning for all web sites ... but specifically for the web sites accounting for 90 percent of the transaction provide some additional useful information to the consumer other than straight reputational.

the baby step proposal doesn't preclude en enhanced merchant certification for enveloping the public key. If the domain name system is attacked then the environment quickly degenerates to denial of service (whether the certificate is coming from the domain name infrastructure or from the merchant).

t.c.jones@xxxxxxxx on 12/21/2002 9:10 am wrote:
I think that you are focused on the wrong problem. Let's not obsess about how we got here, let's look at what we have and what we want.

Do we want the NDS to overtake and subsume the existing trademark system? I don't think so.

How about we just focus on the consumer. Let's get him the information that he needs to make an informed buying decision. He makes that today on brand names and logo's. I. E. on trust.

Give the consumer what they want. I am quite sure that he does not even understand the DNS system, nor have any desire for that to become the sole branding mechanism for the Internet.

..tom


Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:52 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
    "Robert E. Frank" <bobfrank@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>,
    Einar Stefferud <Steflist@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
actually i think we are in violant agreement ... possibly as some of my later posts regarding ssl certs and baby steps may show.

egerck@xxxxxxxx on 12/21/2002 9:44 am wrote:
This is not quite correct. The DN in a X.509/PKI cert had nothing to do with the DNS. It was the lack of foresight of some people that has made PKIX vulnerable to yet another problem -- the DNS.

Also, may I recall that there is no "SSL certificate infrastructure". What we have is a PK wanna-be I. And, SSL is broken anyway. It does not prevent server spoofing, its MSIE implementation allows easy MITM attacks that can read all traffic in the clear, and here are additional 24 problems (dure to PKI) that I have documented since 1997, which paper was downloaded more than a million times and presented at the Balck Hat Conference in '99. You can search in google for a copy near you, using the query "Overview of Certification Systems Gerck"

And, PKI certs are simply too big for wireless and also for everyday use -- this message would probably more than double in size if signed.

Cheers,
Ed Gerck


x959 Postings and Posting Index, next, previous - home