X9.59 mailing list


x959 Postings and Posting Index,
next, previous - home

updates for (AADS) Relying-Party Certification Business Practices
EC/DSS signature size
NACHA to Test ATM Card Payments for Consumer Internet Purchases
Micropayments & IETF ... fyi
simple (ANSI) debit/credit protocol
more on privacy
NACHA AADS ATM debit ... from tomorrow's american banker
X9.59/AADS demos operational
X9.59/AADS announcement at BAI
Ellison/Schneier article on Risks of PKI ... fyi
X9.59/AADS demos at RSA conference
Attacks on a PKI
Comments from 2nd LB on DSTU X9.59
Stealing cards easy as Web browsing
Security breach raises questions about Internet shopping
Security breach raises questions about Internet shopping
X9.59 related press release at smartcard forum
Internet Fraud
X9.59 Reconsideration Ballot
X9.59 Reconsideration Ballot
Some high-level concepts related to the X9.59 mapping outline in Annex B
Suggested changes to Annex B, 8583 mapping
Simple 8583 mapping
Misc 8583 mapping cleanup

updates for (AADS) Relying-Party Certification Business Practices

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Subject: updates for (AADS) Relying-Party Certification Business Practices
Attached is proposed draft text for resubmission of the AADS NWI ... using existing terms and business practices description.
Relying-Party Certification Business Practices


Part of the relying-party certification business practices work seeks to reconcile

• significant installed operational infrastructures and operations that have been highly optimized for high capacity and high throughput transactions for the financial industry

with certificate and Certification Authority standards especially in the areas of

• privacy and liability

A simple initial pass converging the two infrastructures results in a combination of

    relying-party-only certification operation
    eliminating the necessity to transmit certificates in order to completely validate a digital signature trust hierarchy.
    eliminating the requirement to publish a detailed CPS for a relying-party-only Certification Authority (a single business entity operating as a relying-party and its own Registration Authority and Certification Auhtority,


Relying-Party Certification Business Practices shows that additional optimization is possible within the existing standards and business practices of Certification Authority infrastructures.

Part I:

Part of the work relies on the existing certificate transmission optimization work that allows for not transmitting certificates when it can be presumed that the relying party already has a copy of the specific certificate and/or can be reasonably expected to obtain such certificate by other methods.

The certificate and Certification Authority infrastructure recognizes that in order to validate a digital signature, a certificate containing the corresponding public key be available. In fact, every digitally signed object (including, but not limited to certificates, which themselves are digitally signed objects requiring additional certificates for validation) requires a separate certificate to provide the public key for digital signature validation. This is true for all digitally signed objects and certificates except for the case of self-signed digital certificate (where the public key for validating the certificate's digital signature is included in the body of the certificate).

The AADS work recognizes that in situations where the Registration Authority, the Certification Authority, and the relying party all exist in the same business unit (as happens in the situation involving relying-party-only certificates, which have been prompted by liability and privacy issues), it can be assumed that the relying party already has a copy of all certificates needed to validate a digital signature.

Existing certificate business practices allows for not having to transmit digital certificates when it is reasonably expected that the relying party already has access to the required certificates. An existing example is the case of the existing WEB SSL infrastructure where the webserver will not transmit the Certification Authority's certificate (and/or other certificates that might exist in a digital signature certification trust hierarchy). These certificates are believed to be already resident at the client and/or available to the client software if required.

In the case, of relying-party-only certification environment, it is reasonable to expect that the relying party already possesses all necessary certificates (and/or can be reasonably expected to easily obtain them). Most current implementations only make the assumption that some or possibly most of the certificates need not be transmitted along with a digital object.

The relying-party certification business practices work extends the current certification optimization efforts to show that for the relying-party-only certification environment, that the relying-party not only has access to some and/or most of the necessary certificates but actually already has access to all necessary certificates.

In this business optimization of existing certificate business practices, it is possible for relying-party-only transactions to eliminate the transmission of all certificates (not just some or most). Since existing business practices allow for not transmitting certificates that can be reasonably expected to be available to the relying party, the relying-party-only certification business practices shows that all certificates can be reasonably expected to be available to the relying-party.

Part II:

Existing standards and business practices allows for Certification Authority to maintain an internal repository of certificates in optimized format as long as the original certificate format can be exactly reproduced bit-for-bit. These optimization are implementation dependent for specific operations and may contain a combination of data compression and/or field elimination (i.e. fields that are common to all certificates issued by the same Certification Authority may be discarded when stored in the repository).

It is also possible in the internal operation of a Certification Authority for entries in the certificate repository to be extracted and operated with directly without necessarily having to reconstruct the original certificate first. For instance, a Certification Authority may wish to sort all certificates in the repository by date (and/or select all certificates that will expire within the next 30 days).

The sorting and/or selection process may be able to directly extract the expiration date directly from the repository without having to read the entire certificate entry, rebuild the exact bit-representation of the originate certificate, do the ASN.1 decoding of the original certificate (to obtain the expiration date field) and then use the resulting value for sorting &/or selecting.

The issue in relying-party certification business practices involving the Certification Authority's internal certificate repository and its internal business operation, would it be possible for the Certification Authority in its dual role as Certification Authority and relying-party to be able to directly extract public key entries from the certificate repository.

The claim is that for internal business operation there is no prohibition preventing a Certification Authority from extracting individual fields directly from its own certificate repository (as in the case of date sorting/selection example).

Given that a Certification Authority can directly access fields in its own certificate repository for internal business processes, there is not prohibition against relying-party Certification Authorities from directly extracting public keys directly from certificate repository entries, as opposed to:
    completely reading all entries for a certificate repository entry
    recreating the original exact certificate bit-string representation (i.e. doing the ASN.1 encoding of each field)
    immediately doing the ASN.1 decoding of each original exact certificate bit-string representation
    extracting the individual fields resulting from the ASN.1 decoding obtaining the original fields (which is the point where things started in #1 before the ASN.1 encoding of the fields followed by the immediate ASN.1 decoding of the same fields)


Since the values coming out of #4 are the same exact values going into #1, are there superfluous business requirements that for internal business operations? Or is it necessary to redundantly do the ASN.1 encoding followed by the immediate ASN.1 decoding (where the intermediate results from the ASN.1 encoding are never used in the case of internal business operations).

The Relying-Party Certification Business practices asserts that for internal business operations that it is within existing business practices for specific fields from entries within the internal certificate repository to be available directly (w/o having to undergo superfluous and extraneous ASN.1 encode followed immediately by ASN.1 decode).

In effect, the ASN.1 encoding of the certificate data elements provide for a mechanism for transmitting information between different interoperable business entities. Furthermore, the digital signature on the certificate, helps verify that the certificate hasn't been modified in transit. In order for any specific entity to utilize the contents of a certificate that has been transmitted, it must be ASN.1 decoded.

One of the optimizations that can be used by Certification Authorities in their internal business operation is to store the ASN.1 decoded versions of the certificate in their internal certificate repository (as well as eliminating redundant and/or common fields that are necessary for internal business operation). This also allows for traditional database operations (like select, sort, query, etc. to be used directly against the certificate fields for certificate records in the certificate repository.

EC/DSS

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: EC/DSS
does anybody have a list/table just showing DSS signature sizes for the nist&x9.62 recommended curves/fields? ... say curve/field, field size, DSS r&s byte size

NACHA to Test ATM Card Payments for Consumer Internet Purchases

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: NACHA to Test ATM Card Payments for Consumer Internet Purchases
at the FSTC meeting this summer ... this was described as being AADS-like. There was then some offline discussion about possibility of converging the format to X9.59 signed payment object definition (i.e. the purpose of the X9.59 work has been to define a signed payment object that could be used in across a broad range of payment infrastructures, including existing legacy infrastructures with existing message flows).

NEWS RELEASE

CONTACTS:

Michael Herd
703/561-3924
mherd@xxxxxxxx

Julie Foster
703/561-3915
jfoster@xxxxxxxx

NACHA to Test ATM Card Payments for Consumer Internet Purchases

Herndon, VA, October 27, 1999- The Internet Council of NACHA - The Electronic Payments Association is preparing a pilot program in which consumers will pay for Internet purchases by using their ATM cards combined with digital signatures. "The goal of the pilot program is to develop and test a low-cost, convenient payment option for Internet purchases incorporating robust security and immediate authorization," said Lucien Dancanet, Vice President, Information Security Director of Citigroup. "In this pilot a financial institution validates a digital signature, similar to the way it normally validates a personal identification number." In addition to technical requirements, the pilot will develop business practices and operational rules that will allow regional and international ATM networks to communicate with each other to approve consumer purchases. Current participants in the pilot include Citigroup, STARsm, AmeriNet, Inc., Internet Revenue Network, PULSE, eFunds Corporation, and UTM systems corp. Techn ical and security consulting is being provided by Certicom, and additional legal advice is being provided by the Georgia State University eCommerce Institute. Julie Saville, Vice President of Star Systems, Inc., said, "Currently, ATM networks do not allow ATM cards to be used for Internet purchases. This pilot program could enable the wide-scale use of ATM cards for e-commerce, enhancing the value of those cards for consumers, merchants, and ATM networks' member financial institutions." "Eighty percent of U.S. households have ATM cards but cannot use them to make purchases on the Internet," said David Kerlin, President of AmeriNet, Inc. "This pilot is an important step in allowing Internet purchases for people who prefer to use their ATM cards."

In the pilot, a participating consumer would use a private key to generate digital signatures. The private key is securely stored in a chip on a device such as a smart card or within a web application. When making an Internet purchase, the consumer would use his or her ATM card number; but instead of using a personal identification number (PIN), the consumer would digitally sign an electronic authorization form. The form is then sent to the consumer's financial institution, where the digital signature is verified. The merchant would then receive confirmation, the consumer's checking account would be debited through a participating ATM network, and the payment would be settled through the Automated Clearing House (ACH) Network. Elliott C. McEntee, President and Chief Executive Officer of NACHA, said, "The benefit of this pilot to consumers is the development of a convenient and secure Internet payment method tied directly to a checking account. Merchants would have a guaranteed, low-cost payment mechanism running in real-time. Financial institutions would act as trusted third-parties, just as they do every day for other commercial transactions." As part of the pilot, a technical test will be conducted during the 4th quarter of 1999 to demonstrate the feasibility of a consumer digitally signing a merchant's form, and transporting the digital signature through third-party processors and ATM networks to financial institutions. A full-scale pilot program, conducting real transactions, is scheduled for the 2nd quarter of the Year 2000. The Internet Council is encouraging interested financial institutions, merchants, processors and ATM networks to join the pilot before the full-scale launch in 2000. Additional information is available on the Internet Council's web site at http://internetcouncil.nacha.org

About NACHA - The Electronic Payments Association

NACHA represents more than 12,000 financial institutions through its 34 regional payments associations, and 600 organizations through its seven industry councils and corporate Affiliate Membership program. NACHA develops operating rules for the Automated Clearing House (ACH) Network and for electronic payments in the areas of Internet commerce, electronic bill payment and presentment (EBPP), financial electronic data interchange (EDI), international payments, electronic checks, electronic benefits transfer (EBT) and student lending.

Micropayments & IETF ... fyi

Refed: **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Micropayments & IETF ... fyi
http://www.wired.com/news/print/0,1294,32092,00.html
3:00 a.m. 3.Nov.1999 PST

TEL AVIV, Israel -- The era of almost-everything-free-on-the-Internet may be evolving into the age of the micropayment with new software from IBM and Compaq, who are pushing for new Net standards to hurry things along.

If the standards are adopted, micropayments would allow Web users to make monetary transactions over the Net for as little as a few cents. Up until now, the cost of processing such small fees has been impractical for sites.

"Micropayments are for anything that is too inexpensive to pay by credit card," says Amir Herzberg, manager of e-business and security technologies at IBM's research lab in Haifa, Israel. "This enables people to sell stuff on the Net for small sums -- the middle ground between free and expensive."

IBM has developed its own micropayments technology. Herzberg and his colleagues hope the Internet Engineering Task Force (IETF) will incorporate some of its features when it adopts micropayment standards.

The IETF will discuss micropayments for the first time at its next meeting in Washington on 8 November. The informal gathering, known as a "birds of a feather" meeting, is a chance for interested parties to chew the fat and attempt to persuade the IETF to form an official working group on micropayments.

One of the main things Herzberg is pushing for is a unique hypertext link for micropayment. With IBM software, the cursor changes to a dollar sign when users mouse over items for which micropayments are available.

Russ Jones, business manager of Compaq's MilliCent micropayment technology, agrees with the need for a standard, particularly hypertext markup language for a micropayment link.

"Without any existing standard, each micropayment supplier has had to invent a new way to indicate the price of a URL," Jones explained. "Standardized pricing markup will do for Internet content what the Universal Bar Code standard did for retail merchants."

Users can also configure the tool to accept all micropayments under US$1 with simply a mouse click, but can also configure it to display a dialog box asking whether to proceed with the transaction if the sum exceeds $1.

The IBM technology allows ISPs, telecommunications companies, banks, or altogether new billing entities to handle the actual transfer of money. The system also incorporates a range of authorization and security options.

As useful as micropayments may be in taking money from Web surfers, the charges can also be reversed.

"If you want people to come and try your software," says Herzberg, "give them five to 10 cents. We believe this could be very attractive. And it could be used for gambling. It would be nice to have a casino that pays money on the spot."

IBM is not necessarily endorsing gambling, but it is exploring all possible uses for the new technology, as is Compaq.

"MilliCent can be used by Web sites to build any number of parallel online revenue models through the simultaneous use of pay-per-click purchases, subscriptions, and advertising," said MilliCent's Russ Jones. "It can also be used to offer promotional incentives, issue and track loyalty points, and make direct monetary payments to users."

With or without a standard, micropayment revenues may allow Web sites to focus on content and services, rather than advertising income. But Jones doesn't believe that the banner ad will be banished.

"The point of microcommerce is not to compete with advertising or start charging for free content," he said. "The real opportunity is to bring new premium content and innovative services to the Web."

Improved content and services sound promising, but Paul Hagen, senior analyst with the Forrester Group, is less enthusiastic about micropayments.

"I don't believe micropayments will be prevalent any time soon," Hagen said. "I think the way that most sites will deal with small transactions is to keep track of them and roll them up into a monthly or a triggered credit card transaction. In other words, the Wall Street Journal will take a credit card for a pre-pay or when the downloads of articles hits $25, it will hit the credit card. So, the transactions are really macro -- they just end up being chits that add up (or wind down)."

Not surprisingly, Herzberg of IBM does not agree.

"This is a pretty typical position of quite a lot of the analysts -- but a wrong one," he said. "Customers really are reluctant to subscribe -- or even give their credit card -- to a site so the site will accumulate charges. A small percentage of customers who trust a specific site and are very interested in its contents may go ahead, but most customers -- definitely impulse buyers -- are lost."

simple (ANSI) debit/credit protocol

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: simple (ANSI) debit/credit protocol
the following is discussion of increase the LUID in x9.59->8583 mapping from 8 bytes to 16bytes ... which turned out for the purpose of inserting some sort of truncated hash into the field. The original description of the LUID was that the consumer could effectively use it as a transaction identifier ... in a manner similar to check registry and that the debit/credit statements would be modified to print the LUID information (i.e. that consumer then could cross-fit entries from transaction registry with what was on the montly statement)

.... attachment

part of the point for the x9.59 addenda field size discussion is that I get abused by the operational people for every additional byte (in the addenda field) that would have to flow thru a production network.

If it is a hash of some long unique string identifier ... then I assert that the 10% payload increase hit to the payment infrastructure is not justified by the near negligible business benefit of trying to cram a hash of some long unique string identifier into the LUID.

In fact, the incremental business benefit would justify driving the x9.59 addenda field definition such that the supported LUID (at this state of production interchange networks) to 4 bytes (which would show up as 4,000,000,000/4billion number in statement).

I assert that there is already a SHA1(OD) in the payment object and I assert trying to cram a second hash of unique string identifier is superfluous.

Lets say that SHA1(unique string) truncated to 16 bytes (as in the LUID) meets some requirements.

Then the existing SHA1(OD) in the object identifier meets those same requirements or it doesn't.

If the existing SHA1(OD) does not meet the requirements for SHA1(unique string) ... then I assert for all possible functions F(OD, SHA1(unique string)), combining OD and SHA1(unique string) ...that SHA1(F(OD, SHA1(unique string)) exceeds any requirements of a 16byte truncated SHA1(unique string).

Simple example would be to define that the "order detail" contains a customer defined identifier which is

ODi = cancat(ODo, SHA1(unique string))

i.e. where cancatenating SHA1(unique string) is an acceptable F(OD, SHA1(unique string).

typical ODo are likely to be in the range of several hundred bytes to several thousand bytes ... so the incremental merchant overhead on ODo is a couple percent or less ... and only occurs on the cuustomer/merchant exchange.

Then the ODi is sent to the merchant along with the signed payment object. The signed payment object contains SHA1(ODi) ... and the merchant can recompute SHA1(ODi) and verify it against the SHA1(ODi) in the payment object before processing the order.

In the payment card case, the merchant can forward the 8583 transaction along with the x9.59 addenda field. This x9.59 addenda field contains (for identification purposes), at least a 4 byte LUID, the customers YYYYMMDDHHMMSS (8 byte packed decimal date/time) and the SHA1(ODi). Reducing the LUID from 16 bytes to 4 bytes reduces the existing X9.59 addenda field definition from 88 bytes to 76 bytes.

We would advocate that standard statementing be enhanced to print the 4 byte LUID on the statement for each item in addition to the existing identifying information. For applications for which this isn't sufficient (i.e. 4 billion count), then suggest those requirements be satisfied with an electronic statement that has the x9.59 addenda field appended to every item detail.

For those applications they then have the following choices for identifying the items:
20 byte SHA1(ODi)
7+4=11 byte yyyymmddhhmmss.LUID
20+7=27byte SHA1(ODi).yyyymmddhhmmss
20+4=24byte SHA1(ODi).LUID
20+7+4=31byte SHA1(ODi).yyyymmddhhhmmss.LUID


The assertion is that SHA1(F(OD,SHA1(unique string)) is a significantly better business solution to the requirement and results in no incremental payload burden on the payment infrastructure to meet its requirement.

The SHA1(F(OD,SHA1(unique string)) then can be used for both validating the ODi in any dispute as well as serving as a customer unique identifier ... and it is 20bytes instead of only 16. If the 20 bytes isn't sufficient, then the application can use some concatenated identifier combination of SHA1(ODi), customer date/time, and LUID (possibility of 31bytes)

The proposed revised x9.59 addenda field then (with 4 byte LUID) is 76bytes or 36bytes with the 40 byte DSS digital signature.

There are a couple breaking points:
some merchant acquiring interfaces use 80 byte fixed length records, having the addenda field 80 bytes or less means that the addenda field can be transmitted in a single record rather than two
trying to fit the addenda field into existing interchange 99byte field
trying to minimize the amount of abuse I have to take from the operational people on every additional byte that adds load to the existing operational infrastructure


Note that in the above ... the unique string doesn't have to be transmitted to the merchant ... only the SHA1(unique string) combined in some manner with the order detail ... in effect, the SHA1(unique string) becomes a customer identifier for the order detail information ... which is a useful thing in itself ... and outside of the scope of the payment infrastructure. Then as a fall-out of SHA1(F(OD, SHA1(unique string))) ... it becomes both a customer identifier and also a validation of the order detail involved in the payment .... w/o any increase in payload overhead impacting the payment infrastructure.

more detailed reference at:


https://www.garlic.com/~lynn/8583flow.htm

Now to the EC/DSS signature size. DSS/FIPS186 has r and s defined as 20bytes each resulting in a digital signature of 40 bytes. The proposed revised X9.59 addenda field is then 36 bytes plus 40 bytes for a total of 76 bytes.

For EC/DSS, r and s size is defined to be the order of the field. Previously, work has been done using fields n=160 resulitng in EC/DSS r and s being the same size as DSS/FIPS186. The NIST recommendations is that n>160; two fields being considered are n=163 and n=192.

For n=163, the EC/DSS r & s are then 21 bytes each and the digital signature is 42 bytes. The x9.59 addenda field then becomes 36bytes plus 42bytes equals 78bytes. This fits within some 80byte acquiring limits w/o having to use two records and the 99byte limit.

For n=192, the EC/DSS r & s are then 24 bytes each and the digital signature is 48 bytes. The X9.59 addenda field then becomes 36bytes plus 48 bytes equal 84bytes. For those acquiring implementations that implementing 80byte fixed length records, they will have to transmit the X9.59 addenda field as two records. It does fit within any interchange mapping to 99 byte field.

If convention is that the 36byte part is first, and the signature is at the end of the field, then any variability in the size of the field is based on variability in the digital signature size.

It is believe that the current credit & debit production infrastructures are, in some sense, at a stage compareable to n=163 ... i.e. the 78byte addenda record with n=163 matches current production operation. It is anticipated that the production infrastructure will evolve over time and be adequate level to handle increases in sizes discussed for both larger secure hashes (>20bytes) & larger EC/DSS signatures (>42bytes).

more on privacy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: more on privacy
part of the AADS/X9.59 scenerio being privacy agnostic ... where it can be applied to both retail/consumer payments as well as retail/consumer shipping address (for hard goods ordered on the internet). This has been discused on this list before ... and is also part of the FAST activity at www.fstc.org.

previous discussion ... at both archive for this list as well at
https://www.garlic.com/~lynn/aepay3.htm#votec
https://www.garlic.com/~lynn/aepay3.htm#privacy
https://www.garlic.com/~lynn/aepay3.htm#passwords
https://www.garlic.com/~lynn/aepay3.htm#x959risk2

as stated somewhere in various of these threads ... that all trying to establish rules & procedures for 20 million merchant servers with regard to protecting privacy information is significantly harder than eliminating the privacy information being at those servers altogether 
Title: Web privacy standard clears legal obstacle
Resource Type: News Article
Date: October 29, 1999
Source: NYT (Free Registration Required)
Author: Courtney Macavinta
Keywords: INTERNET/WWW    ,PRIVACY STANDARD,LEGISLATIVE PROG,PLATFORM FOR PRI
Abstract/Summary:
A proposed international standard that would let Net surfers negotiate how much personal information they want to hand over to Web sites--if any--has cleared a significant legal hurdle that threatened to hinder its progress.

The Platform for Privacy Preferences (P3P), which will be supported by Microsoft and Netscape browsers, will let consumers approve or block the transfer of personal information to Web sites based on predefined settings. For example, if surfers don't want to give their names and addresses to sites that sell the information to third parties, they can specify that in their settings, which will be automatically cross-checked with the policies of P3P-enabled sites.

Facing the possibility of stricter laws and pressure from the White House to bolster online privacy through technology and voluntary guidelines, many Net companies have steadfastly supported the recognition of P3P. But the World Wide Web Consortium (W3C), which has been hammering out the P3P standard for more than two years, worried that a potential patent dispute was a major obstacle to the wide deployment of P3P.

Original URL: http://www.nytimes.com/cnet/CNET_0_4_1424553_00.html

Added: Mon Nov 1 9:49:34 -050 1999

Contributed by: David Dillard

NACHA AADS ATM debit ... from tomorrow's american banker

Refed: **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: NACHA AADS ATM debit ... from tomorrow's american banker

>a private key to use in generating digital signatures with participating
>nternet merchants. The bank would attach a corresponding public key to the
>person's checking account and store it in a data base. When buying from an
>Internet site, the cardholder would use his ATM card number. Instead of
>entering a PIN, he would use the encryption key to digitally sign an
>electronic authorization form. The form, in turn, would be sent to the

misc. related AADS information at:


https://www.garlic.com/~lynn/

X9.59/AADS demos operational

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59/AADS demos operational
The X9.59 shopping experience demo is now operational. One of the e-store host/vendors modified their merchant web server software to be able to do X9.59 transactions (in theory either debit or credit), along with x9.59 plug-in for browswer signing (using AADS chipcard signing) and simulated MFI & CFI. These are operational all using sockets/tcpip and can be packaged on single laptop for demos.

it is projected by the end-of-the week demos for some of the other AADS transactions will also be operational (i.e. FSTC/FAST-type stuff for age, lockation, zip-code, etc authentication).

while some of the players have done RADIUS aads transaction (i.e. dominant method used by ISPs world-wide for authenticating login) demos in the past ... none of the router vendors has actually shipped one in their products ... although there was interest at the smartcard forum last week by at least one of the major router vendors for getting AADS RADIUS support out.

as alwas, background information is at:


https://www.garlic.com/~lynn/

X9.59/AADS announcement at BAI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59/AADS announcement at BAI
announcement for X9.59/AADS at BAI this week
Media Contacts:

First Data Corp.: Caroline Hoke, (770) 857-7178, caroline.hoke@xxxxxxxx
CyberSafe: Steve Birge, (425) 837-1057, steve.birge@xxxxxxxx
TSA: Joel Molyneaux, (402) 778-1590, molyneauxj@xxxxxxxx
Interworld: Chris Faust, chrisf@xxxxxxxx

Six Companies Announce Plans to Support Proposed Digital Payments Industry Standard First Data Corp., Compaq, TSA, Certicom, InterWorld and CyberSafe cooperating to develop AADS digital payments infrastructure

MIAMI - Dec. 7, 1999 - A group of leading technology companies today announced its support and plans to develop the Account Authority Digital Signature (AADS) and proposed ASC X9 digital payments standard. First Data Corp., Compaq Computer Corp., Transaction Systems Architects (TSA) Corp., Certicom, InterWorld and CyberSafe together made the announcement at the Bank Administration Institute (BAI) Retail Delivery 1999 Conference here.

These companies are developing solutions for a secure digital payments infrastructure based on AADS, to be used on either the Internet or at point-of-sale terminals. A demonstration - including a reference implementation and Internet-based merchant web site - is available at the conference. (To make an appointment to see the demo, visit booth #1242.)

An implementation of this secure digital payments solution uses a smart card and personal identification number (PIN), that, when combined, provide a secure "digital signature" for purchases transacted either on the Internet or at a point-of-sale terminal. The PIN activates the signing key in the smart card to give each transaction a unique digital signature. Once initiated, the secure transaction is authenticated as being uniquely associated with the buyer, and is securely transferred through the authentication process.

This digital signature system provides the purchaser with a greater degree of security and privacy than traditional systems while simultaneously providing the merchant with greatly reduced charge-back and transaction repudiation. With AADS, the card issuer, which has the existing consumer relationship, handles both the authentication and the transaction authorization. By eliminating the need for third-party authorization, the theft of credit card content and information - including numbers on the Internet - is reduced. The AADS solution applies equally to credit card or debit card processing.

"First Data is supporting this and other security and authentication solutions and protocols desired by consumers, merchants and bank card issuers. We are committed to ensuring that electronic transactions - whether over the Internet or at the point of sale - are as safe and secure as possible," said Lee Adrean, executive vice president of First Data Corp. and responsible for the company's Internet Commerce initiatives.

"CyberSafe and First Data have been working together to meet an important market requirement for digital payments - security infrastructures that provide a worry-free environment for consumers and merchants in conjunction when using real or virtual smart cards" said Jim Cannavino, chairman and CEO of CyberSafe Corp. "CyberSafe believes that AADS is the basis for financial settlement, security, and on-line shopping experiences that directly address consumer security and privacy concerns as well as eliminate merchant concerns related to charge-backs and repudiation of charges".

Each of the companies supporting the statement of direction will contribute a unique and important part of the infrastructure:

§ First Data Corp. intends to support its customers by providing AADS-enabled transaction processing services and smart cards.

§ TSA intends to support AADS in software and services based on its BASE24®, i24TM and e24TM product lines, with particular focus on implementation of a "PIN Debit on the Internet" capability.

§ Certicom intends to provide the elliptical curve encryption technology for smart card and authentication engines.

§ Compaq currently ships certain components of the Compaq desktop, server, and laptop product lines enabled for reading/signing AADS smart cards. Compaq also provides the Compaq NonStop? Himalaya S-series product line that supports TSA BASE24® software product offerings.

§ InterWorld intends to offer digital signature support as part of its web site development offerings.

§ CyberSafe will enable security for AADS, by providing e-commerce application developers a software development kit (SDK) and other security infrastructure products and services to enable rapid deployment of an AADS infrastructure.

About First Data

Atlanta-based First Data Corp. (NYSE: FDC) helps move the world's money. As the leader in electronic commerce and payment services, First Data serves more than two million merchant locations, 1,400 card issuers and millions of consumers, making it easier, faster and more secure for people and businesses to buy goods and services. For more information, please visit the company's web site at
http://www.firstdatacorp.com/.

About InterWorld

InterWorld Corporation is leading the Enterprise Commerce movement that enables businesses to compete and evolve in today's new digital economy. With InterWorld's Commerce Exchange solution, manufacturers, distributors and retailers can get to market quickly, scale to meet growing demands, as well as, evolve to keep pace with changing market conditions and customer demands. For more information, visit
http://www.interworld.com/

About TSA

Transaction Systems Architects' (NASDAQ:TSAI) software facilitates electronic payments by providing consumers and companies access to their money. Its products are used to process transactions involving credit cards, debit cards, smart cards, home banking services, checks, wire transfers as well as automated clearing and settlement. TSA solutions are used on more than 3,200 product systems in 75 countries on six continents. For more information, visit
http://www.tsainc.com/.

About Certicom

Certicom is a leading provider of next-generation encryption technology used to build strong, fast, and efficient security solutions. Major computing and communications companies, such as 3Com/Palm Computing, BellSouth Wireless Data, Hewlett-Packard, Motorola, Pitney Bowes and VeriFone, incorporate Certicom technology into electronic commerce software, wireless messaging applications, and smart cards. For more information, visit
http://www.certicom.com/.

About Compaq

Compaq Computer Corporation is the second-largest computer company in the world and the largest global supplier of computer systems. Compaq develops and markets hardware, software, solutions, and services, including industry-leading enterprise computing solutions, fault-tolerant business-critical solutions, enterprise and network storage solutions, commercial desktop and portable products, and consumer PCs. Customer support and information are available at
http://www.compaq.com/.

About CyberSafe

CyberSafe is a privately held corporation founded in 1991. Its award-winning TrustBroker? Security Suite, Defensor®, and Centrax? product lines are designed to enable secure electronic business, while reducing administration costs. CyberSafe is headquartered in Issaquah, Wash., and on the World Wide Web at
http://www.cybersafe.com/. For additional information, please send requests to info@xxxxxxxx.

# # #

CyberSafe, Defensor and the CyberSafe logo are registered trademarks of CyberSafe Corporation and its wholly owned subsidiaries. TrustBroker and Centrax are trademarks of CyberSafe Corporation and its wholly owned subsidiaries. All other products and trademarks are the property of their respective owners.

Ellison/Schneier article on Risks of PKI ... fyi

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Ellison/Schneier article on Risks of PKI ... fyi
from sci.crypt ....

Bill Lynch writes:
All,

There is a new paper up at
http://www.counterpane.com/pki-risks.html

Recently released by Carl Ellison and Bruce Schneier. The two point out what they see as the 10 risks of a public-key infastructure. I think their point is that security is like a chain, only as strong as the weakest link. PKI is a system where several "links" are not protected cryptographically (or in a secure manner), hence the security can be compromised. It's a good article, take a read.

X9.59/AADS demos at RSA conference.

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59/AADS demos at RSA conference.
For those of you that didn't get by the world-wide retail banking show last month in miami to see the X9.59/AADS demos ... there will be X9.59/AADS demos at the RSA conference coming up this month in San Jose


http://www.rsasecurity.com/news/pr/000103.html

Attacks on a PKI

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Attacks on a PKI
There has also been a thread "Attacks on a PKI" going on recently in sci.crypt newsgroup (which may be of some interest). part of the thread is archived at:


https://www.garlic.com/~lynn/99.html#226

https://www.garlic.com/~lynn/99.html#228

https://www.garlic.com/~lynn/99.html#235

https://www.garlic.com/~lynn/99.html#236

https://www.garlic.com/~lynn/99.html#238

https://www.garlic.com/~lynn/99.html#240

and for digital commerce trivia questions (from the DCSB ... digital commerce society of boston) mailing list:


https://www.garlic.com/~lynn/aadsmore.htm#dctriv

Comments from 2nd LB on DSTU X9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Comments from 2nd LB on DSTU X9.59
We need to schedule a meeting to answer the remaining comments.

Are there any suggestions/offers regarding where & when for the next X9A10 meeting

Comments were submitted by

KPMG - no
Griffin Consulting - no
MasterCard = no
Spyrus - no
Entrust - no
AT&T - yes

Short summary as possible starting point for answers

KPMG ... answer in document

Griffing Consulting

corrent ASN.1 & no messages.

... possible answer about no messages ... X9.59 has defined signed payment objects which may be carried in newly defined messages and/or incorporated into existing message protocols. It isn't defining message protocol.

MasterCard

business requirements ... ? administrative discussion

Spyrus

SET, message authentication, scaling, ... charter for x9.59 was to define signed payment object that preserved integrity of financial infrastructure with just a digital signature

several of the comments are explicitly outside the scope of the X9.59 definition

in the x9.59 reference document, there is a appendix section that maps the x9.59 signed payment object to payment card infrastructure. the mapping shows an end-to-end authentication model with the issuing institution doing the authentication and authorization of the consumer's transaction. the appendix is not describing a X9.59 "system" ... it is describing the X9.59 signed payment object operating within the existing payment card infrastructure. Issues of scalability of that infrastructure Issues regarding the scalability of that infrastructure is not specific to X9.59.

Entrust

syntax does not explicitly allow for certificates.

X9.59 defines a digital signed payment object. The payment object can be incorporated into existing or new message flows. Part of various digital signed object message flows include the option of combining a digital signed object with a digital signed certificate as part of protocol that allows relying party to obtain the signer's public key for digital signature verification. Such protocols nearly all allow for the digital certificate giving the public key binding to not be transmitted if it can be assumed that the public-key binding is available to the relying party (the is most readily seen in protocols involving certification trust hierachies where the CA's public key binding certificate need not be transmitted in order to verify the digital signature on digital signed certificate objects signed by the CA).

In the x9.59 appendix example of mapping the X9.59 digital signed payment object to existing payment card message flows, a situation is used where it can alwas be assumed that the issuing relying party alwas has access to the consumer's public key binding and therefor (as per existing certification standard business policies, practices and protocols) it is not necessary to redundantly transmit the public key binding.

AT&T

consider specification of an XML encoded digital signed payment object in addition to the current X9.59 ASN.1 encoded digital signed payment object.

In the past, encoding conventions have normally been characteristic of transport/message protocol interoperability. Nominally, once transmitted the messages are decoded in order for the encapsulated data to be used and operated on. Interoperable encoding mechanisms have also come into play for digitally signed object authentication since the digital signing technology requires exact bit-for-bit match between the signer and the verifier.

Since this is a interoperable issue between the signer and the verifier, there seems to be no reason why industry standard encoding mechanisms should not be supported.

Stealing cards easy as Web browsing

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Stealing cards easy as Web browsing
seems like there has been a spate of these stories past week or so ... stealing information off merchant/commercial sites.

this particular one is the MSNBC story at

http://www.msnbc.com/msn/357305.asp

this is one of the specific exploits that X9.59 was designed to address. with the increasingly large number of places that store information ... it becomes extremely problamatically that they all can be 100% secured.

Security breach raises questions about Internet shopping

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Security breach raises questions about Internet shopping
X9.59 was specifically designed to protect accounts from "in-flight" attacks (i.e. numbers flowing around the network) as well as "at-rest" attacks (i.e. numbers sitting some place ... whether on harddisk and vulnerable to intrusion ... or in lists on paper and vulnerable to things like dumpster diving).

Security breach raises questions about Internet shopping
BEN FOX, Associated Press Writer
Thursday, January 20, 2000


http://www.sfgate.com/cgi-bin/article.cgi?file=/news/archive/2000/01/20/financial0142EST0158.DTL&type=tech_article

(01-20) 01:42 EST SAN DIEGO (AP) -- Internet retailers have worked hard to squelch consumer fears of credit card number theft, using sophisticated encryption and other high-tech strategies to make online shopping safe.

But the industry's security image took another blow with the disclosure that the credit card database of a health products supplier was open to hackers for a few hours this week.

Word of the security breach at Global Health Trax Inc. comes as credit card companies are canceling thousands of cards because someone pilfered their numbers from CD Universe, a Web music seller. The card companies say the CD Universe case, uncovered Monday, has resulted in the largest mass-cancellation of cards they can recall.

''When someone hacks a site, it raises a lot of questions to the consumer,'' said Chris Merritt, of the Atlanta-based retail consulting firm Kurt Salmon Associates. ''They are thinking, 'You told me that you have a secure site, but how do I really know if it is secure.''

Internet shopping doubled last year to $15.6 billion, said David Schatsky, an Internet commerce analyst for Jupiter Communications in New York. But security remains the top concern of consumers and could slow the industry's growth.

It could also prompt consumers to gravitate toward the established Internet retailers and away from lesser-known start-ups, Merritt said.

Global Health Trax, based in Poway, east of San Diego, is one of the less-established retailers. The company sells dietary supplements to about 3,500 distributors nationwide and has annual sales of about $3.5 million, executive vice president Lorin Dyrr said.

Distributors can go to the company's web site, www.ghtonline.com, and enter their credit card number on an order form that is e-mailed to the company.

On Monday, account information on several hundred distributors, including home telephone numbers and bank account and credit card numbers, was open to hackers on the company's old web site, www.globalhealthtrax.com, Dyrr said. That site was abandoned a year ago.

The company said it believes the breach was a case of corporate sabotage by former employees -- and few people accessed the numbers.

The customer files were exposed because the person who helped design the Web site left the files on an unsecured part of the site, the company said. Anyone with the correct Web address could have accessed it. It was unclear how the address was publicized, if at all.

The customer information was available for a few hours and at least two people accessed the site, including a reporter for the Internet/cable TV news service MSNBC who contacted the company Monday about the glitch, Dyrr said.

The reporter said he was alerted to it by a ''concerned technology worker,'' who Dyrr believes is one of the culprits and the other person who visited the site.

Dyrr said five distributors canceled their accounts after MSNBC reported the breach Tuesday. Other customers said they had noticed odd account transactions or credit card charges in recent months, some for as little as $70.

''This kind of sabotage can happen in any type of company, Internet or not. If we didn't have a computer system, they could take this information and fax it all over the planet,'' Dyrr said.

This is a different scenario from Connecticut-based CD Universe. In that case, an unidentified hacker, who described himself as a 19-year-old from Russia, claimed to have stolen 300,000 card numbers by exploiting a flaw in security software.

He said he sent a fax to the company last month offering to destroy his credit card files in exchange for $100,000. When the company refused, he used a Web site called Maxus Credit Card Pipeline to distribute up to 25,000 of the stolen numbers.

Since then, credit card companies and banks have worked with CD Universe to locate their customers who used the online retailer.

Wachovia, the nation's 16th largest bank, offered to reissue 2,000 cards to its customers who bought from CD Universe, but found no cases where the cards had been fraudulently used, said Charlie Hegarty, a bank executive.

''You could say it was a bit of overkill at this stage of the game, but we wanted to give our customers that extra bit of assurance,'' Hegarty said.

Credit card users are generally liable for only $50 of unauthorized charges. The issuers pay the rest.

Discover Financial Services is reissuing cards for more than 10,000 customers, spokeswoman Cathy Edwards said. Visa and MasterCard are working with banks, which issue their cards, to identify CD Universe customers.

American Express is also reissuing cards, but spokeswoman Judy Tenzer declined to specify how many customers were affected.

Security breach raises questions about Internet shopping

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Security breach raises questions about Internet shopping
... resend

Part of the problem is the magnitude of the problem.

... a great quote that I borrowed
> "in theory there is no difference between theory and practice, but
> in practice there is."

Lets assume there is a design goal of 20 million merchant servers around the world and assume that there are 10 people associated with each of those merchant servers that might have access to account numbers located at a web server.

As per posting 2000/1/16 at 16:22 "Stealing cards as easy as web browsing" ... it becomes "extremely problamatical that they all can be 100% secured" (i.e. 20 million mechant servers have had no mistakes and background clearances on possibly 200 million people).

X9.59 mnimizes the level of security and integrity requirements that would have to be enforced on 20 million webservers and 200 million people to provide a level of comfort for account protection.

There was a talk given at RSA conference this year about secure & encrypting filesystem by an old friend that we've worked with on & off over the past 20 years (we first worked together on a project for the IMS database group at the IBM STL lab). Such a methodology reduces ... but doesn't eliminate the number of failure modes (i.e. some of the random intrusions attacks can be thwarted ... but there are still various trojen horses, numerous buffer-overflow exploits, less than perfect configuraton setup and/or less than perfect people).

Which reminds of a SET story (since SET was brought up in the X9.59 mailing list) ... About feb. 1996 I was doing a detailed analysis of the SET specification. The individual (that presented the encrypting filesystem at RSA) had just completed a 4* speedup of the BSAFE library and was doing extensive benchmark testings on various platforms and preparing to return the enhancements to the BSAFE owners. We got together and did a BSAFE performance profile based on best case scenerio from the SET specification. The interesting thing was that numerous members of the SET community with which I discussed the profile numbers seemed to think that the numbers were 100* too slow (instead of realizing the numbers to be 4* too fast). When there was prototype SET implementions 8 months later using the speeded up BSAFE library, the profile numbers were within a couple percent of the measured prototype numbers.

random references:


https://www.garlic.com/~lynn/99.html#163

https://www.garlic.com/~lynn/99.html#219

https://www.garlic.com/~lynn/99.html#182

https://www.garlic.com/~lynn/99.html#228

X9.59 related press release at smartcard forum

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 related press release at smartcard forum
CyberSafe and Certicom Team In Joint Venture Joint Company To Deliver Smart Card-Enabled Security Products and Services for e-Business Payments and Identity Protection
SMART CARD FORUM, SALT LAKE CITY (Feb. 23, 2000) CyberSafe Corporation, a leading provider of enterprise network security solutions, and Certicom, a leading provider of mobile e-business security, today announced that they have formed a joint venture. The new company will develop and market turnkey solutions that secure the payment systems for e-business applications by combining smart card-based user identity systems with digital signatures, using the existing payment system infrastructures. These solutions, available Q3 of this year, will benefit e-commerce merchants and customers by virtually eliminating the opportunity for on-line fraud and ensuring consumer privacy when using the Internet. Each company is contributing key technology, management expertise and start-up funding.

"This year, we expect to see a significant growth of smart card solutions in the market," notes Steve Van Fleet, a senior vice president at First Data Corp, a leading electronic commerce and payment services provider internationally. "The latest smart card technologies and standards allow transactions to be communicated securely over the existing networks while ensuring the privacy and identity of the consumer. The combination of transaction security and identity protection should enable many new applications."

The new e-business security solutions to be provided by the joint venture feature improved technology based on "real-world" business examples and are expected to be the first widely deployed implementations of on-line identity in payment systems. Specific expected benefits include:

Ease of deployment because the approach uses as much of the existing payment infrastructure as possible Rapid start-up phase because enrollment uses the same process for account registration as that currently used in issuing credit cards Fraud reduction benefits which outweigh the cost of deployment Low cost smart cards, less data to transmit, and smaller signature size for storage based on the Certicom encryption technology used Options for 'virtual smart cards' which enable transition to hardware and lowers the per-user cost of on-line IDs and payment vehicles Limited infrastructure investments as compared to that of many public key-based solutions.

"The joint venture gives CyberSafe an opportunity to combine our strength in identity management with Certicom's leadership in elliptic curve cryptography (ECC) and cost-effective smart cards to address a critical market need," stated Jim Cannavino, CyberSafe Chairman and CEO. "Our customers in the financial industry have asked us to develop this technology, based on our activity in the X9 standards arena, as a solution to the fraud potential associated with current on-line use of credit cards."

The products developed within the joint venture will be based on the draft ANSI X9.59 digital payments standard, and provide strong authentication, authorization, and accountability for financial institutions, internet service providers (ISPs) and application service providers (ASPs) and e-Commerce merchants. The technology also will provide easy to deploy and manage identity management systems, for privacy and integrity to on-line transactions.

"The solutions being developed through this venture are new products that will leverage the benefits of public key technology and smart cards with a practical approach to interfacing with legacy payment systems," said Rick Dalmazzi, president and CEO of Certicom. "The partnership enables Certicom and CyberSafe to develop digital signature solutions that are extensible to the Internet, traditional point-of-sale environments, and the emerging world of wireless e-commerce."

CyberSafe and Certicom were joined by First Data Corporation, Compaq Computer Corporation, Transaction Systems Architects (TSA) Corp., and InterWorld Corporation in announcing support for the Accredited Standards Committee (ASC) X9 digital payments standard. Formation of this joint venture is an important step towards commercial products and services in this area. Specifics from the joint venture on customer deployments, product availability and pricing are expected to be announced later this spring.

About CyberSafe CyberSafe is a privately held corporation founded in 1991. Its award-winning TrustBroker ? Security Suite, Defensor®, and Centrax? product lines are designed to enable secure electronic business, while reducing administration costs. Leading investors in the company include Accel Partners, Deutsche Bank London, Financial Technology Ventures, OAK Investment Partners, and Polaris Venture Partners. CyberSafe is headquartered in Issaquah, Wash., and is on the World Wide Web at www.cybersafe.com. For additional information, please send requests to info@xxxxxxxx.

About Certicom Certicom is a leading provider of mobile e-business security technology used to build strong, fast, and efficient security solutions. Major computing and communications companies, such as 3Com/Palm Computing, BellSouth Wireless Data, Hewlett-Packard, Motorola, Pitney Bowes, QUALCOMM and VeriFone, incorporate Certicom's technology into electronic commerce software, wireless messaging applications, and smart cards. Certicom is a leading source for a complete range of OEM security products and services, including cryptographic toolkits, custom implementations, and security integration services and consulting. Certicom's worldwide sales and marketing operations are based in Hayward, California, with cryptographic research and product development in Toronto, Canada. Certicom shares are traded on the Toronto Stock Exchange under the symbol "CIC." For more information, visit Certicom's Web site at
http://www.certicom.com.

Internet Fraud

Refed: **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Internet Fraud
from a recent cebit news story on internet technology. Passwords and PINS are too easily forgotten or forged. Almost a third of passwords are family members' names or birthdays, according to a study on data security released last year by the Weizman Institute. The study also estimated Internet fraud cost consumers and businesses as much as US$108 billion in 1998.

... regardless of who pays/liable directly ... it is eventually paid for by the consumer one way or another

X9.59 Reconsideration Ballot

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 Reconsideration Ballot
The X9 process calls for a reconsideration ballot regarding no vote comments and the associated responses (even when the ballot passes).

There will be a X9A10 meeting at the New Orleans Federal Reserve the day before the X9A/X9 meetings to prepare the responses to the no vote comments (hosted by Mike Versace) for input into the X9.59 reconsideration ballot.

X9.59 Reconsideration Ballot

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 Reconsideration Ballot
attached is summary of no vote comments for the first two X9.59 ballot. The new no vote comments start at #81 & will be reviewed for responses at the X9A10 meeting at the New Orleans Federal Reserve in a couple weeks.

some past bearing on the comments can be found at:


https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

and


https://www.garlic.com/~lynn/ansiepay.htm#simple

Approximation to text in Annex B (mapping x9.59 fields to existing business processes) is also available at:


https://www.garlic.com/~lynn/8583flow.htm

(See attached file: x959comments.doc)

possible response text for some of the comments

(See attached file: x959resp.txt)

the X9.59 draft has been previously posted to this mailing list (and might also still be found in the mailing list archive).

<see http://lists.commerce.net/archives/ansi-epay/200003/msg00001.html

Some high-level concepts related to the X9.5p mapping outline in Annex B

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Some high-level concepts related to the X9.5p mapping outline in Annex B
ASN.1

ASN.1 provides a standardized way for encoding data. Two parties, posisble unknown to each other and operating with non-homogeneous data processing equipment can exchange data over distributed networks by using ASN.1 to encode the data prior transmission (convert internal representation to some normalized & deterministic format). The destination can recieve the transmission and decode the data into their internal data processing representation. This is a generalized mechanism for handling the situation where two end-points have unknown and possibly non-homogeneous data processing equipment with possibly different internal data representations.

X.509 has also adapted ASN.1 encoding of certificate data fields prior to digital signature. The receiving party can verify the integrity of the certificate data object prior to decoding the certificate data fields into internal data processing representation for internal operation.

Certificates

Public key digital signature authentication requires the receiving party to have the sender's public key in order to authenticate the transmitted data objects. For environments where there is no prior knowledge between the sender and the receiver, certificates have been defined that can be appended to the transmitted object which provides the receiver with the sender's public key. Certificates have also been defined to bind some sort of sender identification information to the the sender's public key in the body of the certificate data object.

The combination of certificates and ASN.1 encoding works well when there is no prior knowledge and/or relationship between the sender and the receiver ... and they are operating unknown and possibly incompatible data processing equipment with potentially incompatible internal data element representations.



In the Annex there is a mapping of X9.59 defined fields to existing financial network messages.
    for the specific messages, there is already a specied field encoding definition.

    Also in the business processes implemented for these transactions
    there is an existing business relationship between the parties sending the message and receiving the message, and
    the party receiving the message already has an existing information binding infrastructure that represents the sending party


The business requirements that ASN.1 encoding and certificates were intended to address (a lack of existing infrastructure related to data representation transmission between the sending and receiving parties and a lack of information binding infrastructure at the receiving party) turns out to not exist in the case of the specific financial infrastructure used in Annex B for the X9.59 data field mapping. Since the business requirements addressed by ASN.1 encoding and certificates (i.e. lack of encoding definition and lack of information binding at the receiver) didn't apply to the specific situation addressed in Annex B, it was easier to use the solutions that already in existed in the financial infrastructure targeted by the Annex B mapping.

Suggested changes to Annex B, 8583 mapping

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Suggested changes to Annex B, 8583 mapping
Some high-level concepts related to the X9.59 mapping outline in Annex B, for update see


https://www.garlic.com/~lynn/8583flow.htm

reflecting EC/DSS and LUID discussion ...

the EC/DSS mapping is changed from 40 byte (two 160 bit numbers) to 42byte (two 168 bit numbes)

the LUID is changed from a 128-bit mapping to a 16-bit mapping

The binary opaque object is changed from 88 byte total to 76 byte total

The wording with respect to "stand-in" in the considerations section is changed to read:

The X9.59 account number (PRC_C) is defined to require digital signature authentication. Any interchange stand-in (approval, in case the CFI is not available) process needs to be configured for account-level public key authentication and clearly indicate if public key authentication was performend in the authorization response.

the following ref:


https://www.garlic.com/~lynn/ansiepay.htm#simple

should also show up in the nov. archives between my post on 11/8 on micropayments and anders response ... but for some reason it doesn't.


http://lists.commerce.net/archives/ansi-epay/199911/

Simple 8583 mapping

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Simple 8583 mapping
Process steps for X9.59 mapping to 8583
    ASN.1/XML encode (X9.59 fields) for signing
    Sign ASN.1/XML encoded (X9.59 fields)
    8583 encode (X9.59 fields)
    transmit 8583 encoded (X9.59 fields) in 8583 message
    receive 8583 encoded (x9.59 fields) 8583 message
    decode 8583 encoded (x9.59 fields)
    ASN.1/XML encode (x9.59 fields) for signature validation
    validate signed ASN.1/XML encoded(x9.59 fields)
    process decoded 8583 (X9.59 fields) 8583 message
    respond to decoded 8583 (X9.59 fields) 8583 message


It should be clear that the X9.59 signed encoded data object ... does not define a new financial infrastructure and/or financial message, although nothing in the X9.59 signed encoded data object precludes using the X9.59 signed encoded data object as part of a new financial infrastructure with new financial messages.

It should also be clear that the X9.59 signed encoded data object ... also does not define a X9.59 centralized infrastructure (with or without any associated scaling issues). To the extent there are scaling issues associated with the X9.59 signed encoded data object, they would primarily be associated with the financial messages and the financial infrastructure that the X9.59 signed encoded data object is mapped to. To the extent that there is scaling issues with the mapping of X9.59 signed encoded data object to an existing ISO8583 financial infrastructure, they would be primarily be scalling issues with the ISO8583 financial infrastucture (and not the X9.59 signed encoded data object).

Note that in the above example, the 8583 receiving party, reconstructs the original signed X9.59 encoded data object from the X9.59 fields carried in the 8583 message (step 7). This has the effect of validating both the signed X9.59 encoded data object as well as validating the 8583 processed fields (that are common between the 8583 processing and the X9.59 processing).

It should also be clear that the X9.59 signed encoded data object does not mandate and/or does not preclude mapping the X9.59 signed encoded data object to new financial infrastructure with new business processes that require the use of certificate based information binding to provide sender's public key for message authentication. The definition of the X9.59 signed encoded data object also does not preclude the mapping of the X9.59 signed encoded data object to existing financial infrastructures with existing business process information binding infrastructures that already support sender authentication material.

misc references:

https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
https://www.garlic.com/~lynn/ansiepay.htm#simple
https://www.garlic.com/~lynn/ansiepay.htm#x959ansr
https://www.garlic.com/~lynn/ansiepay.htm#reconsid
https://www.garlic.com/~lynn/ansiepay.htm#reconsid2
https://www.garlic.com/~lynn/ansiepay.htm#highlev
https://www.garlic.com/~lynn/ansiepay.htm#mapchng
https://www.garlic.com/~lynn/ansiepay.htm#attackpki

Misc 8583 mapping cleanup

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Misc 8583 mapping cleanup
there was a X9A10 meeting last week at the New Orleans Fed, the day before the X9A meeting. The meeting was held to draft responses to the no vote comments. At the meeting we also reviewed various clarification suggestion from vendors based on 18 month implementation experience. I've also retrofitted some of the changes to the 8583 mapping description ... which can also be found at garlic.com

URL:


https://www.garlic.com/~lynn/8583flow.htm

changes include ... changing variable names to be consistent with the ASN.1 definition, adding a couple references for SHA-1 and DSS, changing LUID from 16 bytes to 2 bytes, changing EC/DSS from 40 bytes to 42 bytes, and some additional clarification text in the consideration section.

some of the specific changes:
SHS
secure hash standard (FIPS-180)
ANSI X9 31-2: 1996, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, The Secure Hash Algorithm -1 (SHA-1).
DSS
digital signature standard (FIPS-186)
ANSI X9 31-1: 1996, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, The Digital Signature Algorithm (DSA)X9.30-1
ANSI X9.62: (Draft) Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)


.... 

StandardVersion
   OBJECT_TYPE
Paycode
   PrcC
LUID
PrcM
PaydataC
   DateS
DateE
   SHS{OD}
There is end-to-end integrity between the consumer and the CFI, with the CFI being able to do audit trail of the transaction (and associated data elements), validating/verifying the consumer's intention as to the payment instruction, and executing the payment instruction. The end-to-end integrity of the transaction is bracketed with the consumer's digital signature and the verification of that signature on the transaction at the CFI (the CFI has a complete, consistent journal of the transaction).
The consumer preregisters for an X9.59 account with their CFI and at the same time registers their consumer public key for the X9.59 account. This can involve the consumer transmitting the public key to the CFI encoded in a public key certificate. The CFI may also distribute personalized cards and record the associated public key in a manner similar to PIN recording today. The CFI is able to verify the digital signature on a X9.59 transaction using the account's registered public key. The CFI will maintain the status of the consumer's public key as part of overall consumer account management.


x959 Postings and Posting Index,
next, previous - home