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 (fake ebay site ?)
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&textcolor%23000000&linkcolor=000099&vlinkcolor=purple&pre=0&strip=1&nohrule=1¬imestamp=1&noeditor=0&nocontact=0&nobackground=1&story_textcolor%23000000&story_linkcolor=000099&header=%2Fwww%2Fbw%2Finsp%2Finsp_storyheader.shtml&footer=%2Fwww%2Fbw%2Finsp%2Finsp_storyfooter.shtml&bgcolor=%23343399
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<x-html>
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
- 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.
- Deliverables
The following are the deliverables to be produced as a result of
completing the Project
- A design and implementation of an electronic issuing system for
wireless proximity payments at USC, scalable for commercial release
- 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
- A document detailing the issuing system requirements sufficient
for large-scale commercialization of electronic issuing for wireless
proximity payment
- 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.
- 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
- 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
guarenteeing 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