X9.59 mailing list

x959 Postings and Posting Index,
next, previous - home

The Thread Between Risk Management and Information Security
AADS & RIsk Management, and Information Security Risk Management (ISRM)
Half of Visa's disputes, fraud result from I-commerce (more)
XML, encryption and certificate comments
gaping holes in security
(my) misc. additional comments on X9.59 issues
[ISN] Card numbers, other details easily available at online stores
open CADS and closed AADS
SSL/SET from usenet group
SSL/SET from usenet group
AADS related information
AADS related information ... summary
X9.59 LUID comment resolution
Passwords don't work
Risk Management in AA / draft X9.59
Risk Management in AA / draft X9.59 (more)
Risk Management in AA / draft X9.59 (more 2)
Risk Management in AA / draft X9.59 (more 3)
9.59 reference implementation
Smart Cards with Chips encouraged
X9.59 discussions at X9A & X9F

The Thread Between Risk Management and Information Security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Thu, 21 Jan 1999 04:39:28 -0800
Subject: The Thread Between Risk Management and Information Security
At the two day AADS workshop last week there were nearly 70 participants including one of the leading technology and financial law firms.

I've attached a perspective by one of the participants on the success of that workshop. In the early 90s, I was looking at high integrity business processes and did a definition for business science ... even looking at copyrighting the term. The following takes a serious look at the integration of information security and risk management that would be fundamental to business science.
(ref: 2nd wave?)

The Thread Between Risk Management and Information Security

Last weeks Compaq Workshop was a great success for SITI, First Data, Compaq & Cybersafe. As so often is the case random events churn out some interesting results. I realized when we parted company that your awareness of risk management was not what risk management is in the traditional context of a risk manager.

This is a recap of our discussion over the weekend to begin to craft a migratory path to merge information security with risk management. In its' proper context information security will become a subset of firmwide risk management, called asset liability management or called corporate risk management in the corporate world. The practitioners of this body of science are generally called risk managers, risk czars, asset liability managers by their peers. They are the corporate treasurers, CFO's, COO's, CEO's, traders, portfolio managers, quant jocks, financial analysts, and members of the Board. Some organizations like Fidelity cause their risk managers and information security experts to work together. Pretty soon the functional lines and job definitions will blur. Risk management is the core of an organizations overall business strategy or strategic plan. Regulators codify the high integrity value of these necessary plans, actions and processes.

I would like to begin with an executive context. Remember, if we elevate information security to the domain of risk management, where it properly belongs, we will be dealing with the key decision makers in any corporate or financial entity. From our point of view this is the optimal point of entry into any client, i.e., The Board or Executive level. At this level there is also a whole field of Board and Executive level activities which are defined as the fiduciary responsibility of these players that supports risk management and will also warmly receive the essence and importance of information security. Here is also where the decision making and budgeting issues for these business solutions will originate. These corporate leaders are also the ones incented by their organizations to perform this function.

These best practices are supported/defined/redefined by Regulators like the OCC, FDIC, SEC, NASD and are the heart of the audit context of the CPA's that review these practices, as well as, the ilk of the rating agencies like S&P and Moody's. Expect intrusion detection information to one day be a public disclosure matter released by the Rating agencies, much like an airline accident report is public information. This will become an investor and consumer requirement. One should further anticipate insurance premiums as a business relative to corporate information security profiles. These practices are also the gist of many high end management texts, books, seminars etc., as they are shaped and re-shaped to find new ways to enhance and create corporate earnings. Information security risk management will simply be a new chapter.

For banks the risk management global anchor is called the Basel Regulations which were set up by the G-7 in the late 80's. Today this is the high court of global risk management for all serious players and is chartered by the Heads of Finance ( usually Ministers of Finance, Secretary of the Treasury, Heads of Federal Banks or Federal Reserves of a country) of the Group of 30 (G-7 being the core leadership Group) which are the reps of the top 30 economies. G-7 can be viewed as analogous to the UN Security Council. FIPS laboratories are already being told to learn as much as possible about the Basel Regs and align to the spirit and context of these regs. ANSI committees are writing information security standards designed to be sanctioned by the Basel members. The fact that the very first bank certificate authority, DST was required to be FIPS 140-1 compliant is an indication that information security and risk management regulations are intended to be intertwined. Product vendors should pay particular heed to the portent of this policy. Senior managers and Board members will discover that high levels of information security valuation will become part of their overall fiduciary responsibility. At a baseline minimum expect all financial intermediary vended products whenever possible to require FIPS 140-1 Level 3 compliance to insure tamper resistant products reach the consumer end users. The 5C consortium has already missed this directional arrow and will pay a heavy price to retrofit their pki architecture so these products, though security enabled, will be acceptable and price competitive in a regulated environment.

Firmwide risk management includes, interest rate risk, credit risk, and other lessor subsets. It can be summarized as the task of managing earnings which is the ultimate responsibility of the Board and the Execs of an organization. Hence risk management processes are a top down implementation methodology. This again gives you a good path to integrate information security into an existing corporate structure.

The information security kernel is the information security risk factor as it applies to risk management. A pki is nothing more than a tool or methodology for generating earnings. For this tool to be used well it must be harnessed by the existing risk management policies and procedures of an organization. Information security needs to be incorporated into the science of risk management so that organizations can find a handle to develop leadership and competitive skills in Internet centric business environment. This marriage is happening and is essential because of the three main capabilities and corollary attributes of the Internet; 1) communication, 2) brokering, and finally, 3) mass customization. The Internet is the origin of a new economic model, never before seen or imagined, on an unprecedented scale. Organizations will ignore the Internet's impact at their peril. For the technology to function effectively and efficiently a common set of business driven ROI practices must evolve to support the Internet's singularity. Everyone will be touched by this technology. That is a phenomenal statement about this technology. The nature of the information security risk profile from the corporate point of view is that an organization has a dual responsibility of, a) making money with this technology, i.e., creating ROI, while b) protecting it's own and its customers information security risk.

First the historical context and Executive Summary:

Risk management is the art of managing earnings. A good description of the process would be to develop the ability to hindsight as much in advance, before an event occurs. Essentially senior management has to address the task of managing earnings in an uncontrollable environment. Managing a corporate entity is a process of making decisions based on insufficient data, of inadequate quality, facing an unknown future, within an uncontrollable environment. How well an organization accomplishes this feat is the essence and definition of fiduciary responsibility. Most earning profiles and subsequent results are based on a correlation between a business strategy and an interest rate cycle. These cycles in interest rates are uncontrollable, but the EFFECTIVE structure of the balance sheet --irrespective of the CONTRACTUAL maturity of the assets and liabilities -- can be managed to react favorably during each phase of an interest rate cycle.

Earnings are determined by how the balance sheet responds to changes in interest rates. A constant balance sheet will not produce earnings or profits during every phase of the cycle ( I can't help but restate the significance of the AADS strawman chip as a radar blip that is a traceable evidence trail monitoring the individual transaction level detail in real time that is necessary to manage the interest rate risk associated with a company's risk profile or overall balance sheet, this level of granularity is essential for competent risk management). Overall it is a dynamic process in a constant state of flux. This science was created in 1978 when the tools, technology and instruments for risk management were created. Today, this practice of financial theory is the navigational sextant of most organizations and a primary function of a company's Board.

In short, earnings from a liabilty-sensitive balance sheet suffer during rising rates; earnings from an asset-sensitive balance sheet suffer during declining rates; a fully "matched" balance sheet may result in unacceptable low earnings. The Board and Execs are charged with dealing directly with 1) the causes of poor earnings, 2) fixing the problem without a reduction in current earnings, 3) creating a manageable methodology to retain control and flexibility throughout the interest rate cycles.

Does it matter if interest rates cycle? The difference between small cycles and large cycles is the difference between reduced and negative earnings. If the cycle is small, earnings are likely to be reduced by rising/high rates but most associations would continue to operate. If the cycle is large and the rising/high rate phase causes operating losses for more than a brief period few associations will continue autonomous operations. Technology is a necessary component of creating the navigational sextant necessary to manage cycles. Imagine extending what you know today as your vision of end-to-end information security architectures to integrate with the risk management valuation models. This presupposes that there will be information security risk valuation models, which I think you can count on.

These models are measuring risk, on a real-time basis, of the embedded options of all of the corporate assets and liabilities. These measurements are based on the greatest granularity an organization can afford. Once the base calculations are complete the models then simulate corporate earnings over various possible event horizons looking for a company's exposure to various interest rate scenarios. The most prevalent current methodology for doing this type of analysis is called Option Adjusted Spread (OAS) analysis. This is in essence a simulation valuation methodology. It's actually like a pilot learning to fly in a flight simulator. These models simulate earnings in time across various interest rate scenarios to capture the impact on an organization. Regulators even allude too and sometimes require specific rate scenarios. Some regulations actually go as far as to cause additional net worth capital to be set aside by an organization based on likely cyclical trends. These regs are anticipatory in nature. The key question can be summarized as "What is the value of the organization over X interest rate scenario?"

There is a correlation here with the Chief Security Officer of an organization as she/he thinks through related issues in a company's day-to-day business operation as well as any dynamic business process like e-commerce which is essentially hosted outside the physical boundaries of a company and as a business process contains complicated liability and information security risk. Once data used by a corporation becomes intelligence, it is by definition a risk management related issue. As long as data can be used to produce earnings or ROI then it must be recognized for it's risk factors. These factors traditionally include interest rate risk and credit risk and with the advent of the Internet they now include information security risk.

The greatest audience for our work to date are the risk managers doing OAS analysis. They will get every bit of the AADS, X9.59, ECC message.Why? Because information security is a) an internal security risk management process which enhances earnings (if done properly) is the domain of the risk managers and, b) any dynamic business process, specifically e-commerce, which "impacts", "grows", "is the source of earnings", "is an asset growth strategy", falls under the prevail of risk managers who must model the process in the overall firmwide risk management process of the corporation. Why? Because failure to do so could expose an institution to unexceptable levels of risk that could threaten the survival of an organization. Currently, much like the early days of risk management our models are primitive. The necessity for a full scale corporate deployment of a pki to manage information security risk is only present in corporations that have experienced a realized loss due to the lack of security. Vendors to date have not been able to provide a solution set that comprehensively addresses this firmwide risk. By definition a CA based pki won't work. To date the AADS ECC model is the only functional model that has a chance of proving itself successful. The reason is because the model was designed from the outset to be scalable and to fully address the firmwide information security risk issues. Corporations are already exposed to levels of information security risk that Boards, senior management, and regulators would deem unacceptable and fiscally irresponsible. They will continue to be exposed as they attempt to deploy partial CA-pki solutions that only address a portion of the overall security risk while introducing a host of other risk factors. Our lack of awareness and sophistication won't prevent organizational failure. Education and the creation of successful business methodologies for information security is one of our greatest challenges and a legacy worth the individual commitment.

These dynamic business activities must be included in the Phase 1, the risk measurement phase, of the overall process. As we have come to know, intrusion detection alone can demonstrate significant risk management exposure which can impact corporate earnings. The entire methodology from a risk managers point of view can be described in three phases. Phase 1 is measuring the risk. Information security is clearly a Phase 1 activity when viewed through the lens of a risk manager. Phase 2 is developing strategies for managing the risk. Phase 3 is managing the risk. Information security as a complete body of professional practices is part of firmwide risk management and has a role in each phase.

Historical evolution of risk management as it applies to information security:

In the late 80's the US financial intermediaries collapsed. We commonly refer to this as the S&L crisis. It was much more. The resolution to this crisis was the FIRREA Act of 1989. From a corporate point of view the question was, "What caused this widespread dissipation of earnings and broad industry failure?" One of the answers was discovered in the way we measured risk on a corporate balance sheet. Essentially, the models were discovered to only be as good as their data.

Prior to 1989, institutions aggregated their assets and liabilities into generalized pools. Not much attention was paid to transaction level detail. The most common product and generalized pools were Adjustable Rate Mortgages (ARMS). Everyone assumed that an ARM was and ARM was an ARM. Not so when you consider there are hundreds, perhaps thousands of different ARM products all booked at various times with different coupons and varying teaser rates. All behaving in completely unpredictable, uncorrelated fashion depending on a specific interest rate scenario. To magnify the problem imagine a situation where the analysis superimposes instrument credit risk valuations along with interest rate risk valuations of the ARM as part of the analysis to fully dimension the transactional and overall institutional risk profile. Each individual ARM behaves differently in a particular interest rate scenario relative to its interest rate risk component and credit risk. A risk manager must also calculate the credit risk profile of each ARM along a particular interest rate curve for a complete valuation process to be accurate. Hence each dimension of risk management is calculated in the risk measurement valuation process.When institutions began to create financial models measuring the entire individual transaction level detail of their portfolios they discovered the gapping error. No one could predict a) the multitude of embedded options that were going unmeasured across an organizations entire balance sheet, b) the individual portfolio behavioral characteristics of these embedded options, c) the unmeasured aggregate earnings impact of these options across a multitude of interest rate scenarios. In one example, Citicorp failed to recognize that a 2% rising rate phase would cause an 80% loss of core holding company earnings. If the cycle was to occur for an extended period Citicorp would fail. This discovery caused Citicorp to get out of the mortgage business in 1989. At the time the company was the largest player in the mortgage market. Coincidentally, Citicorp's stock traded at an all time low of $ 6.00/share and needed a private bailout to continue functioning as an entity. Board and senior execs have learned to take risk management very seriously. In an Internet centric business model what is the proper assessment and valuation of information security risk? How does this component of risk management integrate with other factors like interest rate risk and credit risk? In general what is the nature of information security risk? How is it measured? How does one develop strategies to manage this risk? Finally, how do I manage this risk?

The pre-transaction level detail era is referred to as the "garbage in, garbage out" risk management period. In essence the models reflected what the Board and Execs wanted to hear. The analogy is that in the current business environment pki's have about the same credibility as these early risk management models. Their ability to contribute to the overall risk management strategy of an organization is nil because they can't be scaled 100 %. Therefore, they have NO predictive, don't enhance fiduciary responsibility or create any intrinsic value. Unless they can scale and be used to measure a complete business strategy they are worse then toys they are irresponsible. Especially if they cause a perceived level of information security comfort that can be breached. As the number of hackers and intrusion attacks become larger and more predatory they have the potential to cause an associations failure. If a pki can not address this issue, why build it? If the goal of the pki is not married to risk management we will create a situation where there is a false level of security and confidence that these technologies are bullet-proof. When they are found to be penetrable AND cause significant earnings loss these activities they can cause organizational failure. We already have case histories of the Secret Service, FBI and DEA having entire law enforcement capabilities corrupted by a single errant hacker. Instances where the objective of the hacker was self preservation not necessarily tied to destroying an organization. This is new terrain for corporations and they will have to craft the answers for themselves. Given the current state of the art of information security it would behoove organizations to take this threat much more seriously than they currently do and not look for answers to be developed for them by law enforcement or industry Regulators. These organizations are reactive not proactive and more often than not a company is very likely to find itself thrown into the information security risk arena for reasons that are usually unimagined.

The failure rate of the "garbage in, garbage out" strategy was so high that it correlates to the level and cost of the S&L bailout. Institutions that knew their data were more likely to survive. The legacy of the 90's has been the era of intermediaries owning their data. Some of these projects have been expansive and reached overall costs in the hundreds of millions of dollars for a single holding company. These projects originated as competitive processes as organizations realized the value in their data. A similar awareness is developing as the early information security adopters realize their individual earning risk and calculate losses due to poor information security practices. In the case of SITI reviews of existing pki designs we have already seen instances where breaches in information security have caused serious dollars at risk losses, i.e., $ 40M in oil for one corporation, and $ 200M in internal theft in another. The press is reporting higher and higher dollar losses for bank related intrusion cases. This year the NISSC Report announced a five fold increase in dollars lost due to information security related acts alone. The current estimates are in the billions of dollars and I would suggest very low due to the lack of sophistication of our information security practices and general lack of knowledge and awareness. This won't go on unnoticed for very much longer by industry Regulators. As is quite frequently the case, it might take a failure due to security related issues to cause a policy shift. In the literature of hackers it is simply amazing how quickly intrusion activities can bring and organization and its' customers to their knees.

This cost of this error in the 'garbage in, garbage out era', was not lost on the Regulators of the day and formed the basis of another important decision. In the case of financial intermediaries which include, banks (FDIC), S&L's (FDIC), Wall Street firms (SAIC - not much here), Insurance companies (state regulated - in general there is NO back-up for failures), pension funds ( no fund), credit unions (FDIC), each one of these specific industries is backed by a fund in the event of a fiscal crisis. Because of the severity of the 1989 banking and S&L failures the funds at the time, FDIC & FSLIC, went bust (Note: these were the biggest back-up funds, now that they are recapitalized, which is what WE did, they have been combined into the FDIC) . Congress had to write legislation to pay for the failure (FIRREA). For the first time the mismanagement of these institutions, i.e., the lack of fiduciary responsibility at the Board and Exec levels responsible for the failure caused the bailout to be funded by the US taxpayers. In a very real manner every individual wants to make sure that information security is driven to the highest levels possible not just to protect their own security and privacy but to also protect their pocketbook. This should be unquestionably a public and corporate policy.

To date the last reported dollars I have seen for each one of us to perform our refunding of the banks and S&L's exceeds 100K per person. Whether you like it or not, in a rather benign interest rate environment you will pay over 100K in your lifetime of taxpayer dollars to pay for this bailout. The dollars are so high that they are carried as an off balance sheet number so as not to capsize the US budget or cause attention. At one point they exceeded $ 1 trillion. This is what I mean when I say that ALL of the moneys gained by individuals in the asset appreciation (real estate) of the 70' & the 80's went in one pocket and the pay-out of the costs for the S&L industry came out of the other. The result - a zero, if not negative, sum game. The horrifying part of all of this was that it happened over a very benign interest rate cycle. Institutions were toast overnight because of a short term rate spike. Today prevention and anticipation are the order of the day and the keys to good regulations.

Regulators know that this structure is a house of cards and if they don't do their job well they will be the gatekeepers accused of being asleep at the wheel in the crisis. Regulators love rules that cause higher levels of net worth to be posted by an institution in an anticipatory manner. We can create an anticipatory edge for this technology just by making Regulators and companies aware of the deep, quick, risk factors related to information security. Intrusion issues can be as devastating as a huge bond trading loss. They happen quickly and cut to the core of earnings. As a taxpayer that's exactly the guidelines you want in regulations. Anticipatory regs go further in protecting you the taxpayer. When I see regs like those designed for the Health Care and Insurance industries I view it as a total waste as far as solving the problems goes. The focus is on the wrong constituents and masks the fact that if there is wide spread failure in the Insurance industry who cares if the privacy issues have been handled well, if the organization fails you can bet you'll get a piece of the bill.

FIRREA caused a significant shift in US regulatory policy. Today, laws are written to protect the US taxpayers from any other future bailout role. The institutions mandate is second to protecting the individual taxpayer. Risk managers, Boards and Execs must align their business strategies and policies to this regulatory goal.

FIPS 140-1 can be viewed as a way to protect the individual token holder, maintaining the high integrity of the overall process and working within the confines of firmwide risk management. FIRREA was extended to a global context with the creation of the Basel Regs. Regulators all over the world can now compare apples to apples when it comes to analysis of corporate balance sheets. They will need to extent this risk management practice to include information security risk.

Japan which was the farthest off when it came to risk management issues is suffering the most under the burden of compliance. For years in Japan the official policy has been NOT to record loan losses. Hence their corporate earnings policy allowed their institutions an unfair advantage over their global competitors. The Basel Regs changed all of this when they CAUSED a uniform playing field so that everyone can measure the counter party risk of any other entity they might choose to do business with. The Basel regs also captured the policy shift of the US Regulators in that they recognize that the ultimate source of a bailout in any country are the taxpayers of that country. Currently, the Japanese taxpayers are also on the hook for the first time for the bailout of their country's banking institutions. The Basel Regs are also driven to protect these very same taxpayers. The upper limits of this strategy is being tested in countries like the former USSR and South Africa where the ability of the taxpayers to finance the bailout is questionable at best. Both of these economic environments are experiencing extreme interest rate volatility with nominal rates in excess of 50%. It will be a long time before economic conditions can support these societies. The true nature of global economies will be discovered as we collectively solve these indigenous local problems. Intuitively, these economies might be the best place to deploy pki's for mass customization of manufacturing processes as a new economic model. This is a very proactive but welcome solution to a difficult problem. If pki's can be used in conjunction with telerobotic technology to simultaneously decentralize the means of production while simultaneously creating 24 X 7 fully utilized manufacturing processes there is a possibility we could give Henry Ford's assembly line production techniques a whole new life while creating individual and community empowerment. Again, for all of this to be possible an Internet centric, pki, ROI business process that is scalable and secure is necessary.

Today, in Japan the taxpayers are for the first time paying for the financial crisis in that country. This causes an immediate and significant attitudinal change relative to Regulatory policy. No one wants to be individually caught up in this twice. Our best arguments for information security can and will be made along this front, protect the taxpayers. Once Regulators pick this up in the US or for that matter any other country the attitude towards information security will radically shift in the direction we are leading it. The shift will be powerful and overnight. This is soon to be a fait accompli. I would without hesitation say to you again that the risk managers and the Regulators are our true audiences as they are the ones charged with the mission of protecting the taxpayers while generating earnings. Their fiduciary responsibilities along this path are very well defined. Our notions of digital signature technology, secure transactions and high integrity business processes have a home here. What we are really creating is the science of information security risk management. This science is composed of advanced information security technology and portfolio theory. It will be the basis for the creation of whole new product markets and new trading markets. Digital bond trading will be created out of this body of knowlegde. Without the ECC, AADS, X9.59, pki's, secure chip cards, hardware accelerators, intrusion detection capabilities, information security valuation models, secure information technology architectures ( digital distributors), digital rights management systems, etc. you can't create the cashflows and the contracts to create the bonds. The next important step is to educate the Regulators. At the end of the day it would do you well to understand just how little dollars back the various industry groups and this will give you an idea of how serious the Regulators take their job. They have very little room for error in a volatile interest rate environment. The DOI's proper context vise-a-vise information security lies in how well it protects the California fund. If the earning at risk due to information security issues can be shown to be high in this industry then we have won the implementation battle. Dollars at risk while protecting the individual customers privacy and security is the key graphic we want to develop.

The gap today is to map information security to risk management. The ultimate migratory path needs to show the end-to-end information security, Internet centric ROI driven business processes while protecting the ultimate source of any business failures, the taxpayers. Once the plumbing, policy decisions, risk management, and taxpayer protection issues are addressed then we can build on the foundation new processes like digital bond trading or any number of new pki business models. At some point soon Regulators are going to cause the whole process to come to a grinding halt until they are sure that the foundation is laid properly and their constituents are protected. Wall Street current information security business model which is devoid of any FIPS 140-1 like context looks to be a likely battlefield due to customer losses that lead to a fight between industry participants and Regulators. In the first phase of a bailout industry participants are asked to pay higher premiums to finance the failures so all of the members within a specific industry have a vested interest in insuring a safe and sound level playing field. If the necessary kernels are not "signed off" and "bought into", then I suggest that the pace of a standards process will look like warp speed in comparison. The Regulators are going to want to see demonstrable confidence in the scalable, secure, efficient, pki information security methodology. If these Regulators botch it they have to answer to Congress. None of them wants to do that. Their mission and charter is clear, a good strategy would be to give them or build them a pki monitoring capability.

AADS & RIsk Management, and Information Security Risk Management (ISRM)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Thu, 28 Jan 1999 05:53:14 -0800
Subject: AADS & RIsk Management, and Information Security Risk Management (ISRM)
more work relating Risk Management in the wake of the AADS workshop ... from one of the participants at the AADS workshop:.

If the efforts to map Information Security Risk Management (ISRM) to risk management there has been a search for ways to bind ISRM to risk management and asset liability management. The obvious doorway for real time ISRM is intrusion detection. The thinking in support of the AADS ECC pki solution is directed at creating an architecture that can scale to 100% of the information security needs of an organization. Then deploy intrusion detection capabilities to craft the necessary and needed protection to insure the safeness and soundness of financial intermediaries and business processes. The answer won't be perfect, as with any valuation model we will have to improve our tools with time. The immediate goal would be managing on a real time basis the information security risk of an organization. If this is possible then it can be demonstrated that information security risk is an important component of firmwide risk management and will become part of the net worth regs of a financial institution. The theory is that without a scalable pki you have a hole in your information security hence in your firmwide risk management. Where this issue becomes critical is when the integrity of a critical earnings component of an organization becomes corrupted due to a breakdown in information security policies, procedures and practices. In the world of information security one continuously seeks to avoid what is referred to as single points of system failure that could cause a whole system to be collapse. When you think about an information security pki in a financial intermediary relative to single points that would be targets for systems failure it's easy to envision key intrusion targets. Two for me are; 1) corrupting the integrity of the secondary market by altering term contracts via intrusion and 2) a trading desk environment via intrusion. The second problem while painful and probable is manageable. It is the first problem and the lack of a proper methodology to address the problem that I find challenging. If we cede widespread degradation of the secondary marketplace it will be difficult to eradicate. Managing the problem and assuring the business processes will happen. The key question based on the timeliness of industry actions is at what cost. It would be wise to address this issue sooner rather than later. Any degradation without a solution will have a systemic effect on the market reflected in every pricing structure we know from bond prices to stock prices

I suggest that information security risk management is going to factor into net worth regs based on the scalability and capability of a pki model. I wonder what kind of advise a CPA firm would give a financial client regarding a pki that only managed 40% of the corporate risk of an institution. Especially, if this information is published as part of an annual report. I suggest to you that regulatory policies, pool insurance, rating agencies, servicing companies, even CPA firms are soon going to recognize this issue. At some point their will be pre-pki asset pools (that will trade at a discount) and new pools that were created in an information security risk management environment that deploys scalable architectures with digital signature technology, secure transactions and high integrity business processes. I also propose that intermediaries are going to give away smart cards, chip card and readers to be able to have an evidentiary trail to asset securitization pools that are traded in the secondary market. It will be necessary to track pool degradation due to information security intrusion related events. The management and inclusion of information security risk as part of firmwide risk management is going to cause the rewriting of not only our net worth regs but cause a whole body of policies and procedures to be codified to support this science. It could turn out that information security risk becomes the foundation of asset liability management as it guarantees the integrity of firmwide risk management and business processes. I am working with some intrusion detection experts. I have as yet to discover the levels of the problem in a banking, wall street or trading environment. In the commercial marketplace pki and intrusion design projects are turning up some alarming details. Especially since 80% of the problems are internal in origin. If any of you have worked with an such companies I would like to know about it.

The second thread that I am seeking to draw out the elegance of the AADS ECC model is legal. The fundamental issue is whether legal standards should be build from either a given technology or from business practices associated with the use of that strategy. This insight is the essence of the wisdom of the AADS model created by the Wheelers of First Data. Prior to the explosion of the Internet e-commerce has been conducted on a large scale over closed networks, the age of the main frame. Today we are operating in open networks of distributed client-server computer systems. Creating advanced technology that maps into existing commercial practices and business models is what separates the AADS model from the CA model. At the end of the day we have to find the best information security model that addresses our need to predict information security risk, hence, firmwide risk, with the highest degree of certainty. Because of the AADS ECC model design it accomplishes this goal. Furthermore, because it is based on standards it can be used by various e-commerce systems transactors and unlike the CA model has a very fast rate of adoption cycle. I encourage you to read the work of Jane Kaufman Winn;
!! NOTE moved to !!
now gone also, but at wayback machine:
Especially the UCC letter and her articles: 1) Couriers Without Luggage: Negotiable Instruments & Digital Signets and 2) Open Systems, Free Markets and Regulation of Internet Commerce. The missing piece to complete her argument is the methodology of information security risk management as part of the firmwide policies and procedures and risk adjusted net worth capital regs. At some point soon, there will be a convergence and alignment of protecting the rights of the consumers and protecting the rights of the tax payers when a complete methodology for information security is put in place that protects what initially looks like disparate tracks. The problem that needs to be solved is for the leadership of the industry to establish best practices and methodology for the financial industry to have a context to address information security risk management. Causing FIPS 140-1 product compliance is a good example of sound policy. Any regulatory solution should contains business and regulatory goals that must be addressed by the technology answer and not cause the opposite result, i.e., technology driving the business and regulatory processes. Irrespective of any vendors viewpoint or products we can set high water marks for information security risk management that will do more to prevent unimagined problems then we are giving ourselves credit for. It is possible to address the complex problem of information security risk given the state of existing technology. Enough of the pieces are there to be a strong deterrent. The context needs to be established to deploy these technologies. Vendors could use a constructive context from which to drive their product ques. This context has to be established, otherwise we get piecemeal, ineffective technology solutions at the risk of challenging the financial soundness of the system. No one benefits if this process extends itself to degradation of the secondary market. At the moment, the AADS ECC pki technology driven by a business focus, has jumped out in front of the level of awareness of the business leadership. It is time to raise the level of industry awareness of information security risk management so we can maintain the high integrity business practices that our industry depends on. It would be of great benefit for all of us; financial institutions, regulators, vendors, to work together to demonstrate a competent solution set as soon as possible to the marketplace. This solution set needs to include best practices that support business processes, regulatory policy and the best advances in information security technology.

Half of Visa's disputes, fraud result from I-commerce (more)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: "Tom Jones (DRM)" <tomj@xxxxxxxx>
Date: Thu, 1 Apr 1999 08:01:15 -0800
Subject: Re: Half of Visa's disputes, fraud result from I-commerce (more)
seems that this is getting a bit of play on a number of different mailing lists
Please respond to Digital Signature discussion <DIGSIG@xxxxxxxx>

To: DIGSIG@xxxxxxxx
Subject: Re: Half of Visa's disputes, fraud result from I-commerce

At 04:38 PM 3/29/99 -0700, Bob Jueneman wrote:

>Interesting article originally posted to the SET-discuss mailing list....
>Half of Visa's disputes, fraud result from I-commerce
> By David Legard InfoWorld Electric Posted at 10:24 AM PT, Mar 24, 1999
>SINGAPORE -- Although only 2 percent of Visa International's credit card
>business relates to Internet transactions, 50 percent of its disputes and
>discovered frauds are in that area, the company said here Tuesday. It is
>consumers who are responsible for most of the disputes and fraud, not
>merchants, Mark Cullimore, director of emerging technology at Visa
>International Asia-Pacific, said

It seems silly to blame an emergent property of a fundamentally insecure system on people who had no role in the design of the system. One might even use words like "emotional" and "irrational".

The VISA number is complete on the card, and on receipts. Staff members of every vendor who accepts a Visa card in a transaction get all the information that they need to fraudulently reuse that card number in some other transaction.

Is it negligence on the customer's part that this system was designed in a way that provides any criminal who can get access to the data from a single transaction with all the information s/he needs to create many new transactions?

Banks, at least, have a variety of stop-loss measures that they can employ to detect fraudulent-looking patterns of use of a card number and they can suspend the card until they check with the customer. (For examples, see my Insecurity of the Digital Signature paper at www.badsoftware.com).

The digital signature system doesn't provide the customer with these stop-loss safeguards.

One of my core issues with the current fashion of digital signature legislation is that, like Visa, we blame users who had no role in the design of the system and who have no access to security methods that were designed out of the system, for any compromise of security in the system.

Cem Kaner, J.D., Ph.D.
P.O. Box 1200, Santa Clara, CA 95052


Author (with Falk & Nguyen) of TESTING COMPUTER SOFTWARE (2nd Ed, VNR)
Author (with David Pels) of BAD SOFTWARE (Wiley, 1998)

This e-mail communication should not be interpreted as legal advice or a legal opinion. The transmission of this e-mail communication does not create an attorney-client relationship between me and you. Do not act or rely upon law-related information in this communication without seeking the advice of an attorney. Finally, nothing in this message should be interpreted as a "digital signature" or "electronic signature" that can create binding commercial transactions.


Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Sun, 23 May 1999 12:13:51 -0700
Subject: AADS NWI vote
Attached is vote closing for AADS NWI and the comments from the four no votes.

Additional information will be available shortly.

Dear X9
cc: X9F
cc: X9A

We are pleased to announce that the ballot has closed on NWI, Account Authority Digital Signature
(AADS) X9/99-LB#12

Date out: 4/06/99
Close date: 5/18/99
Actual close: 5/20/99

18 yes
4 no
0 abst.
40 voting members

Therefore, per Section 14.3.4 a reconsideration ballot will be conducted.


Date: Tue, 13 Apr 1999 16:55:46 -0400
From: Blake Greenlee <blake.greenlee@xxxxxxxx>
Subject: X9/99-LB-#12
To: dschuber@xxxxxxxx

Dear Darlene:

M. Blake Greenlee Associates, Ltd. votes Negative with reasons on the subject letter ballot.


Failure to require the use of certificates in conjunction with signatures may seem like an operational advantage, yet, this approach is not extensible, and does not support the transparent migration of these types of transactions to the web.

If the proposal is submitted for a full security review by X9F1, X9F3, X9F4, X9F5 and X9F6 and is updated to conform to the recommendations of such a review, then I may reconsider my vote.

M. Blake Greenlee
M. Blake Greenlee Associates, Ltd.


From: "Jerry Rainville" <jrainvil@xxxxxxxx>
To: "Darlene Schubert" <dschuber@xxxxxxxx>
Subject: Votes
Date: Wed, 14 Apr 1999 07:44:16 -0400


NSA votes affirmative on X9/99-LB#11

NSA votes negative on X9/99-LB#12

NSA will change its vote on X9/99-LB#12 to an affirmative vote if two changes are made: 1: The work item be assigned to X9F. (X9A participation is of course welcome, but to ensure that X9 produce consistent security guidance, X9F should lead the effort.) 2: The scope and application for this work item must be more fully and carefully defined to limit the applicability to those circumstances that would benefit from this use of certificates.

Jerry Rainville
Director, Center for Standards
National Security Agency
Vice Chairman, ISO TC68/SC2


Date: Sat, 24 Apr 1999 13:46:09 -0400
From: "Phillip H. Griffin" <asn1@xxxxxxxx>
To: Darlene Schubert <dschuber@xxxxxxxx>
Subject: X9/99-LB#12


Griffin Consulting votes Negative on this NWI. This work is not needed and similar work on short certificates is already being progressed in X9F1 as X9.68 and interested parties could participate in that work.

Phillip H. Griffin Griffin Consulting
asn1@xxxxxxxx Secure ASN.1 Design & Implementation
+1-919-828-7114 1625 Glenwood Avenue, Five Points
+1-919-832-7008 [mail] Raleigh, North Carolina 27608 USA --------------------------------------------------------------


From: "Stapleton, Jeff" <jstapleton@xxxxxxxx>
To: "Darlene Schubert (E-mail)" <dschuber@xxxxxxxx>
Cc: "Mannal, Robert H" <rmannal@xxxxxxxx>,
"Van Ranst Jr., Alfred F"
Subject: X9/99-LB#12 NWI AADS
Date: Tue, 20 Apr 1999 00:52:01 -0400

KPMG LLP votes negative on X9/99-LB#12 for the following reasons:

The NWI does not provide any significant business or technical benefits beyond existing X9 standards or current industry practices and the draft AADS RFC does not provide any technical detail to warrant a separate X9 new work item.

There are too many implicit business and technical assumptions and too many explicit and substantiated claims to warrant a separate X9 new work item.

We are in favor of the AADS model, however the financial industry would be better served if the RFC was submitted to the X9A10 working group for the working draft X9.59 Account-Based Secure Payment Object. Attached are further details.

Jeff Stapleton

(my) long winded observations regarding X9.59 & XML, encryption and certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: (my) long winded observations regarding X9.59 & XML, encryption and certificates
The objective of X9.59 was to define a signed payment object format that didn't require encryption, preserved integrity of the financial infrastructure and could be applied to all account-based payments.

Some of the issues:
  1. the payment object was general enough that it could apply to all account-based payments and infrastructures
  2. no encryption was necessary or defined
Because of the large number of different environments that the X9.59 payment object would apply to, various considerations were:
  1. compact and efficient
  2. support end-to-end authentication for all financial account-based transactions and do not separate authentication and authorization (which has in the past been demonstrated to create fraud opportunities)
  3. only define the signed object format and allow different environments to transport the data elements (specified in the signed object) in the whatever manner appropriate for that environment, specifically avoid specifying transmission related characteristics in order to not limit the applicability of the X9.59 signed payment object.
  4. support existing legacy and point-of-sale as well as Internet/WEB and other types of environments
Some issues raised:
XML signing/authentication format

XML has tended to be a WEB-specific solution as well as currently dependent on the exact XML document flowing end-to-end. FSTC in similar e-check work (where the signed object may only exist at the end-points, and the data elements may take totally different formats during the transporting phase) found that XML didn't have a single deterministic representation for data elements. The FSTC solution was to define SDML (at the time of the X9.59 standards work, and possible still, has not been released). SDML defines a deterministic representation for financial data elements and does allow for the object data elements to take other formats during transmission between the end-points. The solution chosen for X9.59 data object was to use ASN.1 encoding of the data elements. The X9.59 data object can be generated in ASN.1 format at the time of signing, the data elements of the object can then be decomposed and transmitting in whatever form determined by the financial transaction, and then the same exact bit representation can be recreated at the end-point for signature authentication. This deterministic bit-representation recreation has not been a feature supported by XML.

Also see "encryption" description of the end-to-end transmission of the X9.59 digital signature.
The X9.59 work on signed data object format was specifically directed to avoid requiring and/or specifying encryption. Encryption may be a characteristic of a financial infrastructure transport that moves X9.59 data elements from one location to another, but is specifically not part of the X9.59 signed data object format. In fact, typical transport of the X9.59 data elements can require two-three different transport mechanisms with some types of intermediate processing at various locations. Specifying a encryption method for X9.59 when X9.59 is to be applied to a large number of different environments becomes impractical (besides being beyond the scope).

A trivial example is payment card at point-of-sale (for more detailed reference see Payment Card reference in the X9.59 appendix):
  1. X9.59 object is created and signed
  2. X9.15 message is created (data elements in ASCII alphanumeric)
  3. X9.59 digital signature is inserted into a X9.15 binary addenda field
  4. X9.15 message transmitted by merchant to acquiring processor (MFI)
  5. Acquiring processor generates ISO8583 message from the X9.15 message (data elements in EBCDIC alphanumeric)
  6. the X9.15 binary addenda field is copied to an ISO8583 binary addenda field
  7. ISO8583 message transmitted to the consumer's financial institution (CFI)
  8. CFI extracts various ISO8583 data elements, recreates the X9.59 data object and verifies the X9.59 digital signature
Since there is no X9.59 message, there is no X9.59 message to specify encryption for. To the extent that such messages (that might be adopted to carry X9.59 digital signatures) should or should not be encrypted, should be taken up in the respective standards activities for those messages. Those messages already exist and currently already carry the payment transaction.

While it is theoretically possible to build a new payment infrastructure that used X9.59 data objects as the end-to-end message format, there are tremendous advantages to limiting the X9.59 standard to a specification that can be implemented in all (including existing) account-based payment infrastructures. Encryption is an issue with respect to the characteristic of those payment infrastructure operations. Adding a X9.59 digital signature field to those existing payment messages is hardly a privacy concern (since the binary bits in a digital signature field hardly represent a privacy issue).

Also, see EU privacy issue reference below and how the addition of X9.59 can be used to address EU privacy concerns of existing payment infrastructures (because of X9.59 enabling changes to existing business process).
X9.59 work established that digital signature authentication using public/private key technology is a basic business process. The use of certificates for communicating the signer's public key to the authenticating agency was found to be a subset of that digital signature authentication business process.

Up until now, certificates have been primarily an Internet and WEB based solution that could be deployed quickly needing little or no infrastructure. There is some indications that a major original design point for certificates were offline email authentication, with the receiver have little or no inplace resources to authenticate incoming email. A certificate manufacturing infrastructure (subset of full certification authority infrastructure) has been pretty much straight forward to deploy for non-critical operations. The manufactured certificate, appended to the digital signature provides a method of communicating the signer's public key to the authenticating agency (receiver). At issue is that offline email had little or no authentication infrastructure or authentication material handling business processes. The financial industry has significant investment in authentication business processes and authentication material handling business processes which could benefit from upgrading to digital signature authentication (without necessitating building totally independent infrastructures as seen in the offline email case).

X9.59 was specifically given the scope to define a generic signed payment object that could apply to all account-based payment environments. Some number of these environments have significant difficulty supporting certificate-methodology for communicating the signer's public key to the authenticating agencies. Furthermore, large number of cases anticipated for X9.59 deployment, the authenticating agency for the financial transaction will already have the signer's public key on file (making the communication of the signer's public key as part of the transaction redundant and superfluous).

Furthermore, just like X9.59 does not specify the transport format for the data elements (either with regard to XML or encryption), it also doesn't specify the transport format for the X9.59 signed payment object (including no requirement regarding digital certificate as part of the transaction that moves the data elements between the end-points). In that sense, X9.59 is agnostic with respect to the method that the digital signature authenticating agent (i.e. the consumer's financial institution or CFI) obtains the consumer's public key.

There is passing reference in the X9.59 document to the possible use of merchant certificates and consumer certificates as part of WEB-based shopping experience, but that is outside the scope of the X9.59 signed payment object definition and doesn't apply to things like point-of-sale payment transactions. These are considered "comfort" certificates since they are typically associated with signed messages intending to establish some sort of identity but aren't involved in messages that actually effect the transfer of funds. In part, the Internet shopping experience is being addressed by IETF and W3 specifications (like the IETF OTP work which includes provisions for payment protocol "plug-ins" which can make use of X9.59). Even, the (non-standard) SET specification doesn't flow certificates and digital signatures through to the consumer's financial institution as integral to the payment operation.

Generically, certificates are a subset of the digital signature authentication business process ... describing one method that can be used for reliably communicating the signer's public key to the authenticating agency. In order to not limit and confuse the wide-spread deployment of digital signature authentication for all financial transactions, it should be kept in mind that a certificate methodology is only one subset of the authentication business process.

A case in point has been certificate-based financial transactions targeted specifically for the Internet/WEB environment. The digital authentication and certificate processing has been done at a Internet gateway, which then strips off all the digital signature capability and forwards the transaction (w/o digitial signature) through the legacy financial infrastructure. This has negated a basic security tenet, end-to-end authentication, as well as creating fraud opportunities because different business entities are now performing authentication and authorization (i.e. the business separation of authentication and authorization has frequently been shown to lead to fraud opportunities). In part, this unfortunate circumstance may have come from viewing certificate-based methodology as a superset of digital signature authentication business process (rather than a subset).

From another perspective, the financial and payments infrastructure have business requirements for authentication. Current business processes supporting authentication are primarily shared-secret based (PINs, mother's maiden name, SSN#, etc). shared-secret has the disadvantage that the shared-secret can both originate as well as authenticate a transaction (existing business infrastructures need extra levels of security to prevent divulging the shared-secret). Upgrading these existing authentication business infrastructures to public key is straight-forward and eliminates the vulnerability associated with divulging the authenticating value. Furthermore these are integrated and robust authentication business processes (as compared to the certificate design point for offline email which had no authentication infrastructure). In other words, the existing financial business processes for managing authentication material can be leveraged for managing public-key authentication material.

The privacy mandates (initially from the European Union) are also starting to further complicate certificate use. The traditional certificate has bound the public key to "identity" attributes (like name). The European Union objective is to make electronic payment anonymous (both for WEB/Internet as well as other types like point-of-sale).

I believe that with the appropriate assurance for a digital signing chipcard, such a chipcard without any identity information (no name on the card) can provide a higher level of assurance (even at point-of-sale) than existing cards containing people names. In that sense, X9.59 achieves a very high level of personal privacy as a business process solution (that is not addressed by identity certificates and/or encryption methods) and would meet the EU objectives.

A knee-jerk, certificate-based response to the privacy mandates for financial transactions has been relying-party-only certificates. These certificates contain only the public key and the account number (limiting the privacy information exposed at the various processing stages).

The scenario is:
  1. key-owner registers their public key with the financial institution for their account (in theory, leveraging existing business processes in place for managing authentication material).
  2. the financial institution creates a replying-party-only (RPO) digital certificate for the key owner containing only the account number and public key
  3. stores the original RPO digital certificate in the account record and returns a copy of the RPO digital certificate to the key owner
  4. the key owner creates a financial transaction (including account number and amount), signs it, and appends the RPO digital certificate copy and transmits for delivery to the key holder's financial institution
  5. the combined transaction arrives at the key holder's financial institution
  6. the financial institution extracts the account number from the financial transaction
  7. the financial institution uses the account number to read the account record
  8. (at least) both the account balance and the original RPO digital certificate is retrieved (from the account record)
  9. the public key from the account record is used to verify the digital signature on the financial transaction
  10. if valid, the indicated financial transaction is performed.

In such financial transactions, it is easily seen that the key-owner's copy of the RPO digital certificate is not involved in the payment transaction and therefore redundant, superfluous, and unnecessary, i.e.:
  1. account record must be read to perform the financial transaction
  2. account record contains the original RPO digital certificate for the account
  3. hundreds and thousands of financial transactions will be sent to the financial institution for processing
  4. sending a copy of the RPO digital certificate appended to every financial transaction back to the financial institution where the transaction will be processed using the original RPO digital certificate stored in the account record (instead of the key-holder's copy) is unnecessary

Furthermore, it isn't actually necessary to store the complete key-owner's RPO digital certificate in the account record since most of the information (except for the public-key) is redundant (with existing account record fields) and/or deterministically recreatable.

In any case, since X9.59 only specifies the format and data elements in the payment object, it is possible for X9.59 to be used in all account-based payments, all account-based payment methods, and all account-based payments infrastructures (regardless of whether certificates are used, practical, and/or necessary for communicating the signer's public key to the authenticating agency).

gaping holes in security

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: gaping holes in security
recent AP news article on "gaping holes in the security webs of more than 100 small internet retailers" ... exposing credit card numbes & personal information

one of the problems with relying on information hiding to provide itntegrity is that it leads to complexity ... and there can be still be people that have access to the information. "Hiding" based infrastructures are in part a problem when trying to generalize to millions of instances ... in that they tend to be complex and based on idea that no mistakes will ever be made by anybody.

one of the objectives for X9.59 was to provide integrity w/o having to hide information. one result is that no encryption is required for transmitting the information to maintain integrity. the additional result is no information hiding is required at the intermediate stages.

a better solution to the gaping holes problem ... is to eliminate it as a problem ... rather than coming up with even more complex and exacting processes ... which are even further prone to mistake.

as mentioned early ... a good objective for X9.59 has been KISS ... where elimination of the problem is a better solution than trying to solve it with ever more complex solutions.

(my) misc. additional comments on X9.59 issues.

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: (my) misc. additional comments on X9.59 issues.
The X9.59 payment protocol specifies the hash of order detail (SHA-1). This is nominally provided by the merchant. The merchant can create a merchant order in any manner they see fit (which may include a merchant order ID). The hash of the order detail can be used to tie the payment to an specific order.

Merchant correlation between the payment and the order is currently handled by existing merchant mechanisms. The hash of the order detail establishes a way in the case of a dispute what valid order the payment was associated with. Also, note that MOID would typically expected to be merchant unique number and assigned at the time of the order. Such a requirement could preclude single round trip implemenation as outlined below.

X9.59 does not specify a length for data items that may be generated by the ASN.1 object signing procedure.

The example mapping of data elements in the X9.59 signed payment orject to payment card infrastructure does specify data element sizes. The purpose of the LUID is to allow the consumer to specify a number that can be passed with the electronic transaction and eventually printed on the consumer's payment statement so that the consumer can organize their payment transactions in much the same way they organize consumer check register (using sequentially numbered consumer checks). For the mapping to the payment card infrastructure, a 64-bit number was chosen, allowing these "virtual" consumer checks numbers to have a significantly larger numbering range than can be found in any use today (a 32bit number would be enough to enumerate 4billion payment transactions for the consumer). While the LUID is not critical to the integrity of the financial infrastructure, any significant proliferation of electronic payments could contribute to customer confusion correlating what they have identified as performing and what might show up on the consumer's statement from their financial institution. Even the difference between 64-bit number to carry the LUID versis a 16-bit number raises payload weight concerns in some existing infrastructures. A 16-bit number (64K) might, in some cases result in transaction identification truncation (in manner similar to existing Y2K problems). The result would be that any consumer statement reconciliation application would need to combined transaction date with transaction LUID to uniquely identify a transaction.
Message implementations
The basic signed payment object, in its original scope was to be able to protect the integrity of the financial infrastructure using only a digital signature (not requiring encryption and/or information hiding techniques to achieve this goal).

Furthermore, the protocol exchange was not to preclude a single round trip implementation (some of the existing payment specifications that assume a WEB/internet environment require multiple round-trips for a single payment). This would allow things like shopping from offline CD-ROM (or settop box), creating a single e-mail including both the order and the signed payment object ... sent to the merchant. The merchant after validating the correctness of the order and data elements in the signed payment object could execute the transaction and send a single response. In order to support widest possible applicability for the X9.59 signed payment object, the data elements needed to be such that the operation could be implemented as a single round trip (while not precluding multiple round trip message exchanges). Any merchant supplied data elements in the transaction needed to be of the relatively general/static variety that could be distributed in mass-mailings and/or broadcast.

The primary objective of the standard is to establish a signed paymentobject that can work in all payment environments for all account-based payment mechanisms.

An optional consumer transaction response object was defined where the consumer acknowledges receiving the merchants response.
Certificates (X.509, PKI, scalability, misc additional)
X9.59 specifies a digital signed payment object and in order to maximise he applicability of X9.59 payment object to all payment infrastructures, there is no mandate on how the X9.59 payment object (or its individual data elements) is communicated from the consumer to the consumer's financial institution. It a similar vain, there is also no specification of how the transaction authentication material (aka public key) is communicated between the consumer and the consumer's financial institution.

It is possible that a brand new, end-to-end payment infrastructure might be built which communicates a payment message in the X9.59 signed data object format and that this new payment infrastructure include the appending of a X.509v3 identity digital certificate to a transmitted X9.59 signed data object. The X9.59 signed data object specification neither mandates nor precludes such a deployment.

However, it is also feasable for an existing payment infrastructure to be upgraded from a shared-secret authentication material to public-key authentication material, with the existing payment messages having the addenda of the minimum necessary additional data elements so that the authenticating and authorizing agency for the payment instruction can recreate the original X9.59 signed data object for digital signature validation. The largest scaling existing payment authentication business process is the debit infrastructure which currently manages shared-secret authentication material. This infrastructure scales to at least a couple orders of magnitude larger than any existing Certification Authority PKI (there are possibly some certificate manufacturing operations within two orders of magnitude of the existing debit infrastructure, but I know of no fully blown out Certification Authority PKI that has operations on that order).

The advantage to the existing debit infrastructure to upgrading from shared-secret authentication material to public-key authentication material is that shared-secret authentication material can be used to both originate and authenticate; public key authentication material can only be used to authenticate a transaction. Such an upgrade has the advantage of lowering the integrity exposure associated with managing the authentication material.

As mentioned before, the X9.59 signed payment object specification neither mandates/precludes the building of a brand-new payment messaging infrastructure for end-to-end authentication nor mandates/precludes minimum modifications to existing end-to-end payment messaging infrastructure.

[ISN] Card numbers, other details easily available at online stores

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: [ISN] Card numbers, other details easily available at online stores
misc related information regarding if somebody makes a mistake at a web server and doesn't appropriately hind all the information from access ... exposing information for all customers that might happend to have transacted with that web site.

there was also news note on testimony before House subcommittees on identity theft problems becoming more common and sophisticated ...

one of the features of x9.59 is eliminating the account number as a method of attack/exploit ... not requiring encryption and minimizing need for large, complex, pervasive additional information hiding and security infrastructures that are frequently prone to errors and mistakes.
Card numbers, other details easily available at online stores 6.38 a.m. ET (1039 GMT) April 22, 1999

FOOTNOTE: LOS ANGELES (AP) There are gaping holes in the security webs of more than 100 small Internet retailers, allowing anyone with a little computer savvy to obtain shoppers' credit card numbers and other personal information, a technician warned.

open CADS and closed AADS

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: open CADS and closed AADS
some references in the past have contrasted "open" CADS to "closed" AADS ... seemed to be incorrect semantic characterization ... a more accurate representation would be to clarify that CADS is designed to work in offline environment and AADS is designed to work in online environment (as opposed to open/closed).

Both certificates and accounts bind information and public keys. Certificates can be packaged with signed messages ... such that message and the means of authenticating the digital signature is self-contained and can be performed in offline environments. This is the presumed original design point for certificates and certificate infrastructures ... the offline email environment.

In the offline email world is that there wasn't a preexisting authentication infrastructure and facilities for handling authentication material. Certificates, Certication Authorities and authentication binding infrastructure had to be created to fill that void for the offline email environments.

By comparison, the online financial infrastructure has used account records for binding information for ages, including binding authentication information. This has been shown to be an open infrastructure (in the sense that it is in common use by operations around the world) and scalable to the hundreds of millions and billions.

The downside for an independent, authentication-specific business process is that it isn't sharing its cost infrastructure ... and therefor the economis of its operation has to be completely covered by the perceived value of the authentication services that it provides.

By comparison, most existing financial authentication processes are integrated into the core business process, where authentication isn't an independently operated and stand-alone (i.e. authentication isn't being performed solely for the fun of doing authentication ... but authentication is performed as part of executing some useful business function). The econmic advantages of an integrated account-based authentication infrastructure is that the cost and overhead is shared with the business processes that it is part of.

Fundamentally ... at some level ... both certification authority operation and account-based infrastructures ... are all account based with significant expense in operating and managing those accounts. The integrated account-basd paradigm has the advantage of cost-sharing extensive account operation expences across multiple business functions (and doesn't treat authentication as a stand-alone business operationg where authentication is done purely for the sake of doing authentication).

Additional characteristics are now started to emerge ... with the evoluation of an online environment and the desire to have more timely knowledge of the state of the binding of information found in a certificates ... there are starting to evolve structures dependent on online access to current information (either as CRLs or like OCSP). However, as been demonstrated in the analysis of relying-party-only certificates, one there is presumption of timely and online access, the online, timely account information is used and the offline, stale, static certificate can be ignored (and in many case, totally eliminated).

This characteristic in some sense gave rise to the characterization of "comfort" certificates, i.e. using the certificate for authentication purposes can give some level of comfort .... but for real business transactions it frequently accepted practice to obtain timely information (and not sale information represented by a certificate). In fact, in situations where online and timely status is the state-of-the-art, and the common accepted business practice ... it may be difficult to show that use of stale, static informatioin represented by certificates even meets acceptable business practices (unless augmented by timely status procedures, and of course, any requirement for timely status from online account records can obsolete the need for carrying stale, static information represented by a certificate).

misc. privacy

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: misc. privacy
not taken terribly out of context .... the following quote appeared in the alt.folklore.computers newsgroup today: If you really want personal freedom, you would be better off banning credit cards than espousing guns.

as descussed previously X9.59 can provide the strong authentication necessary to eliminate personal identification requirement from all payment card financial transactions .... meeting the various emerging mandates on personal privacy.

along with AADS it meets business requirement for end-to-end authentication in all environments .... including those supported by existing legacy networks (where payload weight tolerances is currently measured in bytes ... creating interesting challenges).

"SSL & SET Query" ... from usenet group

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: "SSL & SET Query" ... from usenet group
tony has pointed out that the dual cryptographic paths in SET from the consumer (one under the merchant key and one under the acquiring gateway key) was not to prevent the merchant seeing consumer information ... but to prevent the merchant seeing the consumer information until after the payment transaction was done.

this allows that the consumer only has to know the real time status at the acquiring certificate at the time of the transaction ... but not to have a similar infrastructure with full blown PKI supporting the merchant certificate (i.e. the merchant certificate can be a simpler manufacturing process). Effectively the payment gateway can do either an explicit or implicit validation of the merchant business process as part of the payment transaction and delay reflecting the consumer personal information to the merchant until after that is completed.

This way the consumer only has to check on the up to date status of the acquiring certificate and not have to check on the up to date status of the merchant certificate (relying on the acquiring gateway to validate the merchant status and reflect the consumer private information back to the merchant ... if appropriate).

Supposedly the inclusion of the "private information" flag in the merchant certificate was an after thot of the design process ... but it was never the intent of the original design to preclude consumer private information from being reflected by the gateway back to the merchant (after the gateway had peformed whatever implicit/explicit validation it thot necessary).

"SSL & SET Query" ... from usenet group

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: "SSL & SET Query" ... from usenet group
... the SET alternative could have been ... creating an infrastructure where the consumer could trust the merchant certificate (at which point the consumer's awareness of the payment gateway and the payment gateway certificate could be eliminated).

consumer would only have to
  1. validate merchant certificate (instead of acquiring certificate)
  2. transmit all data under the merchant public key

merchant is then solely responsible for awareness of the acquiring gateway (since the consumer could trust the merchant because the merchant's certificate could be trusted)

in that sense ... i was incorrect in assuming that the additional complexity in set was due to a requirement to not inform the merchant of the consumer's personal information .... the additional complexity in set and the primary goal achieved by the basic set function is (only) delaying informing the merchant of the consumer's personal information until after the acquiring gateway has validated the merchant (as part of SET being able to avoid requirement for the deployment of a real certificate-based PKI in support of the merchant certificate ... although adding the requirement to deploy a real certificate-based PKI in support of the payment gateway certificate and requiring the consumer to be aware of the payment gateway at all).

given that explanation ... the SET business requirement for its core function to not inform the merchant of consumer personal information until after the merchant was validated ... could also be met with a SSL infrastructure with a real certificate-based PKI (including possibly OCSP) in support of merchant certificates (replacing requirement for there to be consumer awareness of the payment gateway and a real certificate-based PKI available to the consumer supporting the payment gateway certificates) ... if the consumer could trust the merchant up front .... then it could send all the related consumer private information to the merchant under the protection of the merchant's public key (not requiring a separate payment gateway public key to protect the consumer information from the merchant ... until after the payment gateway had validated the merchant).

Within the X9.59 infrastructure ... X9.59 addresses the end-to-end authentication of the consumer payment instruction (and is applicable to all account-based payment infrastructures and methods ...not just credit or not just internet). That is orthogonal to the SET business requirement to delay informing the merchant of consumer sensitive information until after the merchant has been authenticated (with the slight caveat that the sensitivity of the consumer's X9.59 account number being drastically reduced since it is no longer a point of compromise ... no longer being useful w/o X9.59 digital signature).

The X9.59 payment object specification does not in any ordinary way address the issue of whether the consumer can trust or not trust the merchant before beginning the transaction (except as stated the senstivity of the information going to the merchant is drastically reduced ... and that the X9.59 digital signature should be usable in lieu of AVS and considered much stronger than AVS for authenticating consumer transactions i.e. checking to see if the consumer supplied name/address is the same on record for the account ... address verification).

This still leaves open the issue of consumer providing the merchant name/address information for hard goods shipment (or possibly calculating applicable sales tax?) before the consumer haves some level of trust in the merchant.

Some approaches
  1. real certificate-based PKI supporting merchant certificates ... so consumer has some level of trust before sending the merchant their name/address
  2. AADS online data-base akin to OCSP ... but analogous in the real world to something like the better business bureau
  3. Signed "shipping object" and shipping accounts ... analogous to X9.59 for payment accounts ... where shipper picks up package from the merchant identified with shipping account number ... and the shipper does the mapping to name/address just prior to deliver (i.e. routing to final delivery truck done by bar-code related to account number and only final deliver phase needs actual name/address)

still leaves open taxing authority requirements for at least consumer's zip code available to the merchant for sales tax calculations.

it has the advantage of significant simplification compared to SET ... since there no longer needs to be any consumer awareness regarding a payment gateway aas well as the consumer reliance on the payment gateway to reflect consumer private information back to the merchant after validating the merchant.

AADS related information

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: AADS related information
Some misc. issues facets looking at the issue around CADS and AADS infrastructures
payload and certificate compression
payload and X9.59
service operation
AADS is straight-forward upgrade to all existing shared-secret authentication business processes (upgrade from shared-secret to digital signature using existing business processes).

The CADS infrastructure grew up out of requirement for some sort of authentication processes for offline email which lacked not only an authentication infrastructure ... but any infrastructure what so ever (other than simple address to routing). Part of the problem with working on the Internet infrastructure from mid-80s until now was the lack of any origination verification. When I was putting together a payment gateway for the Internet in the '95 timeframe, as well as shooting a resource exhaustion problem in summer of '95 for one of the largest online service providers (nearly a year to the day when it hit the press in '96 for a similar type of problem) was the lack of anything to do with origination. Even when the Internet made the transition from fully-meshed routing to hierarchical routing ... there was no serious consideration of the ISPs verifying that the from IP-address on incoming packets corresponded to the subnet that they were suppose to originate from (similar to boundary packet filters checking to see that incoming packets from the internet don't have spoof'ed from IP-address of internal subnets).

For some references see:


The CADS certificates provide two useful functions:
  1. free-standing authentication infrastructures for operations that don't have any infrastructure of their own (typical of most offline email implementations)
  2. free-standing technology demonstration platforms.

Rather than starting with the premise that CADS is the answer and searching for the question, it has been useful to look at existing financial industry authentication business processes and look at what aspects of technology that is in use by CADS platforms that could be easily and directly applied. Almost all financial industry authentication transactions are integrated with business transaction that reference an account record as part of executing the transaction (i.e. authentication isn't being performed solely for the sake of doing authentication but as part of some business operation). The existing deployed authentication technology is primarily based on some form of shared-secret (PIN number, mother's maiden name, social security number, birth date, address, etc, although many of these shared-secrets are not so secret).

Public key technology provides an opportunity for directly and easily upgrading all the existing authentication transactions to a more secure level. Public key technology has the immediate obvious advantage that the value used for authenticating a transaction is not the same as the value used for originating a transaction. Recording a public key in place of an account record secret key has the advantage that people that view the account record, no longer can originate fraudulent transactions just by knowing the recorded value.

This potentially has consumer ease of use implications. Current use of identical shared-secrets across different domains is inhibited because of the lack of cross-domain liability i.e. protections are in place for mis-use of a shared-secret within a specific business domain, but their is less protection when a shared-secret learned in one domain is then fraudulently used in another domain. There are situations of people actually listing different "mother's maiden name" in every domain that they register. Public key registration has the advantage that just knowing the public key does not allow fraudulent transactions to be originated.

In that sense, every existing non-face-to-face, authenticated transaction (electronic, ATM, credit, debit, telephone call center) could be upgraded to a higher integrity level by converting from shared-secret paradigm to a public key paradigm. AADS describes a methodology for this simple and straight forward integrity upgrade while maintaining the existing business processes.

The business justification for an AADS upgrade to an existing authentication business process is an inexpensive integrated business solution with stronger integrity and lower risk.
payload and certificate compression
Fundamentally a certificate binds various attributes to a public key for authentication purposes. As noted, this provides (nearly) a free-standing authentication environment for processes that don't currently don't have their own authentication business processes.

For eons, businesses have used account records to bind attributes, including the binding of authentication information (typically shared-secrets).

Sometime in the '96(?) timeframe there was an IETF PKIX thread that looked at certificate compression, including data compression, information compression and knowledge compression methodologies. The objective was to satisfy both transmission overhead (redundant transmission of identical certificate information appended to every transaction) as well as the storage of a certificate copy in an account record at the registration authority (regardless of whether it was a CADS or AADS registration authority).

The higest level of transmission compression came on transactions with a central authority. This has since been typified by the financial institutions in the European Union meeting privacy mandates and other business requirements with "relying-party" only environment.

If all transactions are being sent to a party for which there already exists a business relationship and where a corresponding account record exists, then the highest level of compression is achieved by just using the account number (since all other information has already been registered in the account record). Resending any additional information (other than the account number) is a redundant and superfluous traansmission of information that has already been registered in the account record.

Furthermore, for financial infrastructures, the base transaction will already contain the account number ... therefor appending it after the digital signature (in addition to having it in the body of the transaction) is also redundant and superfluous.

  1. sending more than the account number is redundant and superfluous for account-based transaction
  2. sending the account number twice in a message is redundant and superfluous
  3. appending anything after the digital signature to an account-based transaction is redundant and superfluous
payload and X9.59
The opportunity can also be looked at from another aspect. For all consumer account-based payment transactions that X9.59 covers, the existing legacy infrastructures measure payloads in terms of bytes and tens of bytes. The information-based template methodology for certificate compression is attempting to reduce certificate payloads from thousands of bytes to hundreds of bytes.

One of the X9.59 mappings has shown a knowledge-based compression methodology that meets the business requirements of the existing financial infrastructures and provides end-to-end digital signature authentication. This recognizes that once the information is registered in the account record, it is redundant and superfluous to transmit it again (in this case, the certificate knowledge-based compression reduces the size of the transmitted certificate on every transaction to zero bytes ... not hundreds of bytes).

Note that while it is possible to do a AADS mapping for X9.59 consumer financial account-based payments, consumer account-based payments are not the only kind of financial transactions that currently have authentication infrastructures that would benefit from an AADS upgrade methodology.
service operation
One of the interesting things is how various CADS-based technology demos back into an AADS-like infrastructure.

There have been some certificate-based technology demonstrations for consumer payments. They've had the characteristic that

  1. stripped off digital signature at Internet boundary
  2. did not provide for end-to-end digital signature authentication
  3. didn't involve consumer's financial institution in digital signature technology
  4. optionally involved shared-secret methodology for end-to-end authentication (in addition to digital signature authentication)

The interesting characteristics is that the consumer financial institutions considered that they operate a consumer service business primarily and that electronic financial transactions are secondary.

While the technology demonstration may not have involved the consumer's financial institution in digital signature authentication, in consideration for migration to any sort of production operation, the consumer service nature of the business required that the financial institution be able to interact with the consumer with respect to their digital signature, i.e.
this was not related to the consumer's financial institution performing digital signature authentication on electronic transactions
this was related to the financial institution believing it is a consumer service operation and being able to support the consumer executing a digital signed financial transaction on an account at the financial institution.

The net was that even if financial institutions didn't implement technology for verifying digital signed transactions, they still registered the consumer's public key and provided service support related to digitally signed transactions (i.e. the call center could answer qeustions related to digitally signed transactions against the consumer's account).

What then became obvious, was that once the service operation registered the consumer's public key in the financial account record (regardless of the reason that it was registered), it was no possible to implement AADS-based authenticated transactions. One scenerio has the financial institution "WEB-enabling" their call center so that (nearly) every transaction that could be transacted via the call center could also be transacted via AADS, public key signed, WEB transaction.

The other aspect of this was that the account registration and customer support aspects for supporting digital signature transactions represent the majority of the infrastructure expense. The cost of infrastructures in support of doing digitally signed transactions is actually a small percentage what is required to provide account-based consumer support infrastructure.

With respect to #4, the financial infrastructure eventually realized for production operation that they had support both a consumer public key in the account record (the service nature of the business required it, even if the technology aspect of transaction processing didn't) and a consumer shared-secret. From the infrastructure cost standpoint, registration, recording, updating, maintaining, servicing two different fields with all the associated call center support screens associated with the field maintenance as well as being able to answer questions when things went wrong.

The net is that AADS is a methodology that can be used to optimally upgrade existing authentication business processes while optimally integrating into existing account-based business process methodologies.

CADS approaches have been demonstrated to be useful in upgrading existing environments that lack authentication and account-oriented operations, especially when no prior business relationship exists.

AADS related information ... summary

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: AADS related information ... summary
  1. CADS certificate infrastructures are not inexpensive and represent unnecessary expense when they duplicate existing financial account-based business processes.
  2. AADS public key is a perfectly valid method of upgrading any existing financial secret-key-based authentication business process ... for instance AADS upgrade of the ATM DES infrastructure should be as valid a consideration as triple-DES.
  3. European Union has noticed that privacy mandates and other legal concerns are driving the financial institutions to relying party infrastructures
  4. service operations of financial institutions are also driving the environment towards relying party infrastructures
  5. account-based, prior business relationship operations are effectively already relying party infrastructures.
  6. Concerns about certificate payload weight are driving various certificate compression schemes ... data compression, information compression as well as knowledge compression. It is relatively trivial to show that nearly all digitally signed transactions in a relying part infrastructures can use knowledge compression to drive certificate size to zero bytes.
  7. Providing end-to-end digital signature authentication that includes use of legacy infrastructures exaserbate the certificate payload weight issue (where transaction payload weight is measured in bytes and tens of bytes). Again, digitally signed transactions can be created that involve minimal increase in transaction payload weight and knowledge compression for relying party &/or account-based environments can be used to drive appended certificate size to zero bytes.

X9.59 LUID comment resolution

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution
One of the X9.59 comments was about increaing the size of the LUID mapping to the payment card infrastructure from 64bits.

The current mapping is 64bits which results in an authorization X9.59 addenda record of 80 bytes.

The LUID is to allow a consumer unique transaction identifier (akin to the checkbook register providing unique check numbers). The draft had specified a 64bit number (a 32bit number allows for 4billion numbered transactions or 4x10**9 ... a 64bit number should be roughtly 10**19 uniquely identified transactions per consumer account).

The current resolution is to increase the LUID mapping in the payment card world to 128bits or approximately 10**38.

This increases the binary blob addenda record from 80 bytes to 88 bytes. The restriction in the Mastercard bit field is 99 bytes ... so that leaves 11 byte headroom for new/additional features.

There are some merchant/acquiring interfaces that do transactions in 80byte chunks. A typical authorization might be 50 bytes with an optional 20 bytes or so if AVS is selected (and padding supplied to fill the record out to 80bytes).

In the 80byte flavor of the x9.59 addenda record ... there would be an X9.59 option indicated in the auth, the auth record padded to 80bytes and the X9.59 addenda record transmited as a 2nd record.

It is still possible to do the 88byte flavor in two records. A basic contention is that X9.59 transaction should eliminate the necessarity of (also) doing an AVS transaction. In that case, it would be possible (for those systems with such implemenations) to use the optional AVS area for the first segment of the X9.59 binary blob ... carrying the remainder of the blob in the secondary record. Using this method, such systems should be able be handle up to possibly 110byte X9.59 binary blob before being forced to pad out a 3rd record. Using such a methodology (in those systems that require it), the 88byte binary blob definition leaves possibly 22byte headroom for new/additional features that could be added in the future to X9.59 mapping to payment card infrastructure.

There would be a AVS/X9.59 flag in the basic auth field indicating whether the optional data contained AVS information or portion of the X9.59 blob.

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution (addenda)
a separate issue with the X9.59 binary blob in implemenations that span two (80-byte segmented) records involves acquiring systems that pull the record directly into a (EBCDIC) mainframe host and automatically perfrom ascii->ebcdic character transaction on the whole record (by transport services) prior to application processing.

If the first fragment of the X9.59 binary blob occupies an optional X9.59/AVS space (in most current implementations defined as ascii-127, alphanumeric) and ascii->EBCDIC translation is being automatically performed ... then an inverse ebcdic->ascii table will need to be used by the acquiring application to revert to the original binary blob value as part of reconstitution and passing to interchange in the X9.59 addenda bit field.

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution (addenda)
.. and finally ... typical mainframe character translation is typically done "in-place" using the TR instruction that references a 256-byte "mapping" table. Many of the ascii->ebcdic alphanumeric mapping tables won't map all 256 possibly incoming (ascii) characters to different, unique values. Since the TR instruction replaces (destroys) the original information in place ... if a translation table is used that doesn't provide for mapping uniquely all 256 incoming values ... the translation process won't be reversable (for the non-unique byte map ... negating the ability to correctly recover incoming binary data).

... and the reminder/footnote from draft ... since the LUID is part of the X9.59 signed object, any "lost bits" that might occur in a LUID truncation as part of transport ... would prevent the original X9.59 signed object for being exactly bit-for-bit recreated at the end-points and result in failure to validate the digital signature (i.e. the exact signed object ... bit-for-bit ... must be recreatable for correct digital signature validation to occur). As a result, code that is used for X9.59 signed object creation has to be sensitive to any implementation limitations that are part of a X9.59 mapping to specific payment environments

Passwords don't work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Passwords don't work
Password problems account for 20-50% of all calls to help desks, costing about a million dollars per year for a typical mid-sized company. About time we start taking the human factors of security seriously.

Passwords don't work: except for certain circus performers, nobody can remember a large number of random strings. And yet, how many security groups include a usability expert? (New York Times article: access requires free registration.). (August 5)

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Passwords don't work
the reference quote is from an article on human factors related to security infrastructures ... i believe the article made some reference/suggestion regarding having human factors expects involved in designing security infrastructures.

the problem in general is related to shared-secrets ... whether passwords or symmetrical encryption keys. in distributed environments.

there has been extensive discussion of the AADS chip strawman in various newsgroups ... part of which i've archived at

... and the referenced archived notes typically contain pointers to full archives of the related mailing lists.

in the card scenerio ... there is pin activiation and biometric activation ... both of which represent "privacy" information ... but implemented in such a way that the privacy information (pin or biometrics) flows between the person and the card that the person owns. in that sense there is symmetrically unique information that doesn't have to be distributed across wide area ... but jjust between the person and the something the person owns.

Risk Management in AA / draft X9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/15/99 03:58:24 PM
With regard to minor changes .... X9.59 mapped to ISO8583 is a minor change in the transaction processing part of the system. Even looking at the work item changes going on next year in acquiring and issuing, ... X9.59 support is 5% or smaller than individual work item changes (and way under 1% of the total work item changes scheduled). This is remarkable when we believe that X9.59 could be applied to all transaction environments ... and some of the large work items are only applicable to small subset of the transaction environments (and/or involve only small number of transactions).

Also, the nice thing about the X9.59 mapping to ISO8583 infrastructure (compared to some other electronic payment methods) is that it actually is mapped inside the current existing business processes ... including software development, testing, verification, certification and deployment. Any electronic payment protocol not mapped within the existing issuing & acquiring software methodology needs to develop its own independent verification, authentication, certification and deployment process. The X9.59 work item changes to existing ISO8583 issuing and acquiring implementations is way less than 1% of work items changes scheduled for this year. Furthermore, the X9.59 work item changes mapping to ISO8583 issuing and acquiring implementations are also way less than 1% of what it would cost to create an independent testing, verification, authentication, certification, and deployment software process.

The work on X9.59 was done such that it could be used for all consumer account based payments in all environments (internet, pos, settop boxes, etc) ... i.e. some characterisitic of the protocol would practically preclude its use in any of those environments ... and as been noted elsewhere eliminate significant amount of risk that exists in the current infrastructure. The question then is with regard to the X9.59 cost/benefit equation ... i.e. can the X9.59 costs be made low enuf that for any specific environment, the X9.59 risk reduction (for that specific environment) outweighs the X9.59 incremental costs.

In the work on the AADS chip strawman (mentioned in previous note) ... it would appear that extraordinary cost reductions are possible ... and with that an expansion in the number of environments where it would be feasible to apply X9.59. As for restaurant operation ... within the last two months ... at a local medium sized restaurant, I had 30 minutes added to my check processing time because something went wrong with credit-card electronic authorization and the restaurant needed to be given a card that they could get a voice authorization on. Is that justification for saying that all mag-stripe credit cards and all POS swipe terminals should be eliminated?

Somewhat referred to in the article The Thread between risk management and Information security ... and various work on doing parameterised risk management for 50+ lifetime infrastructure (see various articles and postings archived at
... it is possible to parameterize financial transactions and establish what level component assurance is needed for what level of risk ... (and in the credit card area ... establish what level of component assurance results in what level of merchant discount .... i.e. credit card transactions currently can have different discount rate depending on whether track 2&3 is readable).

With regard to business-to-business ... there was some discussion that X9.59 charter was specifically with regard to consumer/merchant mapping. There has been work done on mapping an X9.59-like AADS protocol to business-to-business ... which may or may not result in new work item in X9.

Risk Management in AA / draft X9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/17/99 05:46:51 PM
actually all X9.59 & AADS is talking about doing is end-to-end per account authenticatioin using digital signatures ... bank debit cards already do end-to-end per account authentication ... but with DES cryptography. Given the appropriate price/performance it is not unreasonable to consider upgrading DES authentication to digital signature authentication.

given the appropriate price/performance and human factors .... then it is not unthinkable to upgrade bank credit to a similar such level as bank debit (end-to-end per account authenitcation using digital signatures). i don't see why it would be unthinkable to see bank cards using AADS authentication .... since (at least) bank debit cards already are doing "AADES" (i.e. account authority DES) authentication ... and the difference between AADES and AADS is the type & strength of cryptography. So unless you know some serious flaw in DSS making it weaker than DES-MAC, there doesn't seem to be any reason for not considering AADS as a strong authentication upgrade to the current bank card AADES infrastructure.

given that financial infrastructure seem to be deploying end-to-end per account authentication into consumer point-of-sale locations (not just cash dispensing machine) ... it would seem that there has been advances in availability technology

as to EC privacy direction ... i was talking to somebody at the RSA conference early this year that had been issued a bank card that only contained an account number ... and had no name on it at all.

as to the internet &/or MOTO with regard to name/address privacy ... in addition to my discussion of hard good shipments using an AADS structure (so merchants don't have name/address) that you should be able to find at
https://www.garlic.com/~lynn/ ... there possibly has been half-dozen or more similar proposals from other people/organizations.

One could also consider that the current bank credit card infrastructure has a poor man's DES-MAC in Add Verification System (AVS). AVS is accocunt specific, no standin and (somewhat) end-to-end authentication, e.g. an AA-AVS infrastructure. There is even been some proliferation on the internet of the use of $1 AUTHs with AVS (where no settlement is actually done) for various types of authentication purposes. Unless you know some serious flaw in DSS, it wouldn't seem unreasonable to consider AADS as a strong authentication upgrade option for the existing bank card AA-AVS infrastructure.

I don't know of anywhere that there is a claim that current stand-in significantly increases the fraud and risk of the existing credit card transaction authorization. The issue is that providing end-to-end strong authentication (along with things like the AADS strawman and various chip activiation methodologies) would, in fact, eliminate a lot of the existing types of fraud. At that point, standin might become the only non-strong authentication, non-end-to-end authentication for many types of transactions ... and as such, representing the weakest link, then become a point of attack. This could even include all point-of-sale environments where debit is also deployed ... and they would share a common card acceptor device and other infrastructure characteristics.

The assertion is that end-to-end account authority authentication is already pervasively used in the bank card infrastructure (both credit and debit) ... and that AADS would not be introducing new account authority processes ... but represents a technology upgrade of the existing account authority authentication mechanisms. Futhermore, the upgrade to AADS methodology could help address privacy issues related to name & address information (even in cardholder not present transactions involving hardgood shipments)

Risk Management in AA / draft X9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/20/99 10:07:33 AM
actually the ECC signing was somewhat the easiest part ... 18 months ago some of the design point that i put out (somewhat repeated in the AADS strawman archived at

preferably beat (but at minimum met) the geldcard standard for integrity (i.e. immune to all known smartcard attacks, etc)

same chip be able to deploy no-activiation, pin-activiation and biometric activation (i.e. chip needed capability to do the biometric calculation and matching)

same chip be able to deploy contactless or contact

for contactless I used the spec for the sony card supplied by mitsubishi for transit ... except it had to do the ECC signing within the same time as the sony card does a symmetric operation in the transit case; 10cm proximity, 100ms max. elapsed time, trick was the power envelop for the ECC calculations available from the RF at 10cm proximity in 100ms. i would guess that the most innovation was both in ECC calculation innovation, biometric calculation innovation as well in chip power consumption to meet the proximity power profile

and chip had to be dirt cheap in large quantities.

Risk Management in AA / draft X9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/20/99 05:54:25 PM
at this assurance level ... other threats start to be worried about ... like for any specific chip ... can the risk managers depend on the associated transactions not coming from a copy-chip. Certified processes in this area can run $500 per (design, foundary, test, assembly, delivery)

being able to have certified assurance process (including not dealing with copy chip) very close to dirt cheap per & that the risk managers can actually depend on is one of the more interesting opportunities. while this process is more than neglibile cost compared to current magstrip card cost ... the certified process can be made close to neglible increase on the current fully-loaded magstrip delivery cost (i.e. looking at very high assurance chip that be added to every magstripe card at as close as possible to magstrip cost ... and very high assurance certification processes that can be economically added to existing fully loaded magstripe delivery process).

some amount of this has been discussed before and archived under aads strawman at

X9.59 refeence implementation

From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 reference implementation
Date: 09/19/99 01:33:08 PM
The performance numbers are starting to look real good and everything is on track to being able to do demos at the X9 meeting in a couple weeks.

Issues for a SDK cdrom are:

Smart Cards with Chips encouraged ... fyi

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Smart Cards with Chips encouraged ... fyi
------- Forwarded by Lynn Wheeler on 09/20/99 09:57 AM -------------------
"Ricki Boyle" on 09/20/99 09:06:09 AM wrote:

To: cryptography@xxxxxxxx
Subject: Re: Smart Cards with Chips encouraged As someone involved in the US smartcard arena, a little more background is offered for those interest in this emerging technology......

>I remember Ian, Adam, <someone else> and I talking about the
>card-in-a-floppy thing at CFP '96.
>Soulda, woulda, coulda, and all that...
>New Hardware Could Help Web Merchants Cut Fraud
>Credit card companies love the Internet, since they pocket a share of most
>e-commerce transactions. But like everything in the world of revolving
>credit, that love has limits. Stolen cards used to make purchases online,
>in particular, cost credit card issuers millions each year -- pushing the
>price of doing business on the Web higher for banks, merchants and,
>ultimately, users.

Transaction fraud is important to credit card companies as are the liability issues. Credit card companies are in legal hot water over card holders payment of illegal internet activities such as gaming in states where gaming is not permited. In recent action on a case in California, a credit card user is sueing over $70,000 debt because the credit card company allowed them payment access to gaming services.

So even as the major credit card companies and the banks that issue those cards explore ways to build Internet market share, they are also looking for creative ways to limit fraud.

Consumer and merchant authentication is also high on the agenda.

The recent launch of the American Express blue card, which comes with an embedded computer chip, is an example of both efforts. Since the card's chip can access a user's personal information, it will eliminate the hassle of typing in that data in every Web purchase -- and, American Express hopes, encourage people to use its card. At the same time, the chip limits the fraud by guaranteeing the shopper's identity and offering greater protection to the buyer's information during the transaction.

The AMEX Blue Card is the start of a flood of bank smartcard initiatives. The smartcard "chip" opens up alternative business opportunities to banks, provide card market differentiation and establish a smartcard infrastructure.

Loyalty, electronic purse, micropayments, authentication, security etc as well as desktop preferences, browser bookmarks and even software licensing will migrate to smartcard technology. Smartcards will also appear in internet appliances in the future as they do today in GSM mobile phones and satellite TV receivers.

The cards also have very sophisticated crypto capabilities. We are constantly in process of overseas and domestic export applications addressing both hardware and software crypto issues.

Those interested can check out smartcard industry sites such as www.smartcardforum.org or www.smartcardcentral.com as starting points. Both SUN and MSFT have sites dedicated smartcard OS and Visa has info on bank related smartcard standards.

Ricki Boyle.

X9.59 discussions at X9A & X9F

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 discussions at X9A & X9F
At the X9F meeting this week there was some discussions about perceived negative characteristics of the draft X9.59 standard for signed payment object.

One of the issues was misunderstanding that the various appendix discussions regarding the mapping of the x9.59 signed object to various legacy infrastructures as being part of the standard. Several people pointed out that the appendixes that discuss various ways that the x9.59 digital signed object draft standard might be used are not part of the standard. The standard defines a signed payment object. Standards issues are with respect to the standards definition of that signed payment object. It was also pointed out in the X9A meeting that the X9.59 standard was to define elements that were to be signed using standard techniques.

Separately there were discussions with regard to some of the appendixes that present how the signed payment object might be mapped to legacy infrastructures, specifically the AADS definition that doesn't transmit the certificate along with the data elements in the infrastructure mapping.

The AADS appendix (and not part of the X9.59 standard) has a discussion mapping the signed data elements transmitted thru legacy systems in situations where the registration authority, the certification authority and the relying party are collapsed into the same entity. This work relies on previous work having to do with 1) certificate caching &/or obtaining certificates via independent paths, 2) compressed certificates, 3) certification authority repositories for certificates, and 4) registration authority verification of signed objects.
  1. cached certificates

    there has been much standards work going into allowing for not transmitting the whole certification chain under the assumption that the relying party may have the certificate(s) cached and/or the relying party can retrieve the certificates independently. AADS demonstrates a scenario where it is shown that the relying party always has all necessary certificates cached and available and/or can obtain them independently and so it isn't necessary to redundantly transmit certificates known to be in the possession of the relying party. For instance, a signed certificate object can be transmitted without the Certificate Authority's certificate under the assumption that the relying party may be capable of obtaining the certification authority's certificate via other methods (and/or already have the certification authority's certificate cached). The perceived situation where a signed object meets the objective of always being transmitted with the corresponding certificate(s) ... is if the signed object is a self-signed certificate.

  2. compressed certificates transmission

    There is ongoing standards work in the area of certificate compression where certificate information in abbreviated form. Also when it can be shown the relying party already always has the necessary field, the field can be truncated altogether. AADS demonstrates a scenario where the relying party has a superset of all certificate fields and therefor the certificate can be truncated to zero bytes. In fact, stipulating that a digitally signed object and the corresponding certificate(s) can only be transmitted in their original bit string representation would preclude using signed objects and certificates in networks that included hardware compression devices.

  3. certification authority as relying party

    There has been much work done involving efficient certificate repositories for a certication authority (storing the fields from a certificate in compressed form i.e. it is not necessary for the certification authority to store the exact representation of the certificate if it can reproduce the original bit representation on demand). In an AADS scenario, where the relying party is also the certification authority, it is not necessary for the certification authority to maintain the stored certificate fields in their exact bit representation.

  4. registration authority validating a digital signature

    An assertion has been made that digital signatures are never authenticated w/o a certificate. However, much of the registration authority work defines a process where the user transmits their public key and signs an object with their private key. The registration authority verifies the digitally signed object using the transmitted public key (w/o having a certificate). This process occurs before a certificate is manufactured. To comply with the assertion, the registration authority work would have to be changed such that it only allows registration from entities when they've generated self-signed certificates which are then sent to the registration authority in order to obtain a certificate.

AADS asserts that in situations where the relying party is also the registration authority and the certificate authority it can use:
  1. certificate caching standards work to not transmit certificates with the transaction
  2. certificate compression standards work to compress certificates to zero bytes
  3. collapsing registration authority, certification authority and relying party into a single entity, where the certification authority is not required to store the original certificate in its exact bit representation, then a relying party can make use of the stored certificate representation that was done in its role as a certification authority.
  4. collapsing registration authority, certification authority, and relying party into single entity has precedence where digital signed objects can be verified using a public key ... which can be obtained from the repository that is part of its role as registration authority and certification authority.
Many of the existing certification and certificate standards work apply to situations where there are different operating entities involved int the registration authority, certification authority, and relying party. This standard work promotes interoperability between independent operating entities.

x959 Postings and Posting Index,
next, previous - home