AADS discussion from the dcsb mailing list

20030101 - 20021231 - 20020630 - 20010311 - 20011230 - 20011110 - 20011005 - 20011002 - 20010615 - 20001215 - 20001118 - 990730 - 990509 - Collected postings: 2003- , 2001-2002,
1993-2000 - home

Attached is a series of postings (and responses) that I made to DCSB mailing list on the subject of Account Authority Digital Signature model.

AADS & X9.59 Overview
Followup Postings
Variations on model
AADS/CADS Complexity issues
Parsimonious implementation
AADS & X9.59 performance and algorithm key sizes
More Performance; Paradigm shift and liability
Comfort certificates, Identity and Privacy
Certificates create fraud potential
AADS, X9.59, security, flaws, privacy
authentication/authorization flaws/liability
Law vs Economics
Statistical Attack Against Virtual Banks (fwd)

X9 is working on x9.59 electronic payments in the x9a10 working group.

In support of x9.59, I've been working an account authority digital signature (AADS) model.

In the financial industry it combines the characteristic of a digital version of the signature card, the "mother's maiden name" field and the next generation replacement for PINs.

The registration of the public key in the account record allows the a digital signature to verified electronically (analogous to the way a written signature is verified against the signature card). A registered public key allows a digitally signed transaction to be authenticated in much the same way a telephone transaction would use knowledge of "mother's maiden name".

The public/private key methodology is also the next generation replacement for PINs. One of the current problems is that PINs are shared-secrets and PIN recording at the financial institution requires special handling. Public keys have the advantage that they can only be used for authenticating a transaction (but not for originating a transaction).

I've also been working on both a payment and a security taxonomy and glossary; they are at:



they are similar ... but different to the stuff that I've done with the ietf rfcs (in part what goes into section 6.10 in std1):


Digital Signature Model Overview

Three digital signature models are described; the original "offline" model (Certification Authority Digital Signatures; CADS) and two newer "online" models (Account Authority Digital Signatures; AADS). It is expected that the two "online" models become the prevailing modes of operation for online financially-related and/or electronic commerce transactions.

Digital Signature Model 1:

The traditional PKI infrastructure talks about issuing certificates that are signed by a certification authority which attest to the:

validity of the public key
    preferably checking validity of the private key
possibly some identity information of the entity
       that the certificate is issued to.

The associated PKI-use model has an entity "digitally signing" a document with their private key and "pushing"

the transaction/document
the digital signature
a copy of their digital certificate

to another party. The receiving party presumably will validate the authenticity of the digital-signature and the originator's public key via the contents of the associated digital certificate. Originally the contents of the digital certificate was assumed to be sufficient such that digital signature validation could be performed without any additional electronic transmissions. As the methodology matured, it became apparent that more and more complex verification mechanisms were needed, if nothing else various status could have changed between the time that the certificate was originally manufactured and the current moment. Certificate revocation lists (CRLs) were one such development in an attempt to partially address the issue of current real-time certificate status in the offline verification model.

Digital Signature Model 2 (or account-based PKI):

This is a proposed implementation for the X9.59 framework. An account-holder registers their public-key (and verification of their private-key use) with the account authority. In a transaction the account-holder digitally signs a transaction and pushes the transaction, the digital signature, and the account number. Eventually the transaction arrives at the account authority and the digital signature is verified using the public key registered in the account record. The account authority maintains the status of the holder's public key as part of the overall account management process. The transaction therefore requires neither a certificate nor some complex status methodology (like CRLs) since the account authority maintains current validity status as part of account management.

This is effectively the X9.59 check and credit-card models where the receiving entity/business forwards the payment instruction to the account issuing institution. The payer's digital signature is forwarded by the receiving business to the issuing institution; the issuing institution authenticates the digital signature using the registered public-key in the account record. No signed certificate attesting to the validity of the public key is required since the public-key is on file in the account record.

An account-authority performs the majority of the same functions performed by a certification authority, but the processing costs are absorbed by the standard business process ... not by charging for the issuing of a certificate. It is possible that an account-authority might also wish to become a certification authority since it potentially could be undertaken at less then 5% additional business costs.

Digital Signature Model 3 (positive authentication):

This is actually a slight variation on #2, although it bears some superficial resemblance to #1. The initial designs for positive authentication PKI, used the credit-card authorization model to replace CRLs. However they kept the rest of the infrastructure; the originator's certificate was still pushed around with the transaction. The receiver validated the CA's signature on the certificate, then sent off a certificate status request and validated the CA's signature a second time on the status response (and then validated the original digital signature).

Model #3 looks very much like model #2 in that the originator's certificate is not pushed around with the transaction. However, rather than sending the digital signature in the authorization request, just the certificate identifier (account number) is sent to the CA. The CA signs a status response that includes information regarding the real-time validity of the account along with a copy of the account's public key. In effect the real time status response becomes a mini-certificate. The entity that will act on the transaction now only has to verify the CA's signature on the status response (i.e. mini-certificate, it doesn't also have to verify the CA's signature on a certificate manufactured at some point in the past). It then uses the public-key returned in the status response to validate the originator's digital signature.

Superficially this resembles digital certificate model #1 but the actual operation is much more like model #2. Including the account's public-key in the real-time status response creates, in effect, a mini-certificate. It also eliminates a redundant and superfluous validation of the CA's digital signature (on both the manufactured digital certificate and the real-time status responses).

The biggest operational difference between #2 and #3 is that the account authority verifies the originator's digital signature in #2 and in #3 it just returns the value of the account's public key for the requester to validate a digital signature. If the requester can send the document or even the secure hash of the document to the account authority along with a copy of the digital signature, then the account authority can verify the digital signature. If not, the request just identifies the account and the mini-certificate is returned allowing the requester to validate the digital signature.

The positive authentication model presents a number of revenue opportunities for the CA to charge for various levels of detail returned in real-time status responses (and/or approval levels associated with the transaction).


Digital signature model #1 was originally developed to allow "offline" verification of a digital signature. A manufactured certificate was pushed along with the signed document and the digital signature could be verified using just the contents of the certificate that was passed along with the document.

Offline signature verification using a certificate manufactured several months in the past (and by implication relying on status that was several months stale) turned out to be inadequate for various kinds of transactions. This has led to the definition of more complicated processes in the certificate-push model in an attempt to provide more timely status and verification.

There has also been the implicit assumption that only the certificate authority is performing registration services for digital signature processes. As the concept of digital signatures have become more acceptable, it has also becoming apparent that existing business processes (already performing account registration functions) can be simply extended to add public-key registration.

Revisiting the PKI basic architecture, it became apparent that there were several optimizations possible if it was recognized there were significant numbers of online PKI operations (compared to earlier models that started out assuming offline PKI and later tried to graft online features afterwards).

The offline validation and certificate push model is still valid for some types of transactions and shouldn't be precluded. However, real online validation (models #2 and #3) can eliminate some number of superfluous operations.

It should be noted that the "offline" validation is different than the "offline" purchasing referred to in X9.59. X9.59 assumes that the purchaser/payer can be offline and transmits an order and payment instructions via methods like email (not requiring real-time, online interaction with the business). In the validation process, there is an issue whether the business is also offline at the point that it approves the transaction. If the business is offline, then it needs a payer's certificate to validate (and authorize) the payer's transaction. If the business is online, then either model #2 or model #3 is used (and it is not necessary for the consumer to push the certificate with the transaction). Furthermore, in the case of model #2, either the business can perform its own PKI registration function and/or it can rely on a financial account infrastructure to have implemented a PKI registration function.

It is expected that digital signature models #2 and #3 become the prevalent modes of operation for at least financial transactions.

Denial of service attack addenda

There is a hypothetical case (that can be made for certificate pushing in the online world) which is associated with anonymous denial of service attacks. The existing Internet infrastructure provides significant opportunities for electronic terrorists to anonymously (and/or under assumed identity) launch denial of service attacks (flooding a web site with enormous number of bogus requests). These are undertaken with the assumption that it is nearly impossible to trace the source of the attack.

One of the techniques for dealing with denial of service attacks is to recognize and eliminate bogus requests as soon as possible. If a certificate is pushed with a request then some preliminary screening of requests can be performed during initial processing and possibly eliminate some number of bogus transactions.

The downside is that public key operations are extremely expensive; preliminary screening of a request using the certificate (and still doing the online validation later) could be more expensive than allowing bogus transactions through and recognizing them via the standard mechanism.

Most of these are simple band-aid solutions. The real problem is that existing Internet backbone operation makes it simple to impersonate a network address. As a result it is usually very difficult to trace back to the originator of an electronic attack.

Followup Postings

variations on your account-authority model (small clarification)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model (small clarification)
I don't see this as two different methods of public key ... the basic principles of public key are the same in both AADS and CADS models.

One way of viewing the scenerio is to decide whether the inclusion of a certificate (especially from a 3rd party) increases the trust among the parties of the transaction.

In the offline and/or NPR (no prior reliationship) scenerio ... a 3rd party participation and the use of a certificate can increase the trust in the operation.

However, I don't really see where a 3rd party certificate improves the trust in a transaction between an account-holder and their financial institution. The addition of a public-key registration field to an account-record provides both a general solution and doesn't involve the introduction of unnecessary participation by parties not involved in the business operation.

The verification of the digital signature ... should be the same whether or not the public key is obtained from a certificate or an account record. The integrity of the network operations should be the same whether or not a certificate flows with the operation.

For account-based transaction ... intergrating a public key field into the account-record shouldn't adversely affect the integrity of the account record or the execution of the transaction.

Where complexity really comes into play are all the business processes and trust relationships that are related to an account. Looking at the operation of an account-based service ... the parts of the business processes that account for the registration and issuing the account may represent less than five percent of the total operation. Translating that into an hypothetical Certification Authority service; the processes currently proscribed for registering a public key and the manufactur and distribution of a certificate ... would only account for five percent of the processes of a full-blown service operation.

It would be a foolish business strategy to introduce into a complex account-based business operation with a strong trust basis the risk and liability of a 3rd party certificate that can't increase the level of trust and/or security (and actually introduces new systemic risks).

The benefits of 3rd party certificates in a NPR (no prior relationship) &/or non-trust environment can outweigth the costs of new systemic risks. However, it would be poor business strategy to force the use of certificates where they add no value and increase the systemic risks.

I don't view there being a hundred-odd AADS scenerios any more than CADS, which has been relatively successful in normalizing a large number of different NPR, offline &/or non-trust operations. I do belive that in terms of value and number of uses, the AADS operations will strongly dominate the use of public key ... far outstripping the CADS, NPR, offline &/or non-trust uses.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model (small clarification)
in AADS, a public key is registered with the account-authority ... effectively the digital equivalent of the signature card; technically it is analogous to the way a public key is registered with a CADS ... but no certificate need be issued ... since it is never necessary to push a certificate along with a payment instruction; the issuing bank is able to validate a signed payment instruction with the public key registered for the account (the purpose of the certificate supposedly is to allow a digital signature to be validated w/o resort to any additional mechanism ... especially in the NPR/no-prior relationship scenerio).

in the financial scenerio ... seperating the authentication of the payment instruction (from the approval/execution) via the certificate (possibly stale &/or dependent on large number of complex network operations) creates (at least) both liability as well as a systemic risk problem ... which are unecessary.

In CADS, a pushed certificate (accompanying a transaction), supposedly relies on the certification authority signing of the certificate (indicating a valid public key for the transaction). The financial authority, executing the transaction, supposedly would use the public key in the certificate (after verifying the certificate digital signature of the certification authority) to validate the signature on the transaction.

CADS is a reasonable model for the offline & NPR operations ... possibly providing an improved sense of security for two otherwise anonymous (to each other) parties (and hopefully risk). A trusted 3rd party certification authority can improve the integrity of an otherwise somewhat random event.

In the financial account transaction operation ... where there is already a significant relationship ... inserting dependencies on a 3rd party into the process, increases the risk (rather than decreasing risk ... in contrast to the NPR scenerio)

The word/lawyer example turns out to be bit of a red herring ... if really comparing apples-to-apples ... it would be not whether or not "legal options" were available for word documents ... but instead the legal option not only had to exist ... but a legal attachment (aka certificate) had to sent with every document (whether it was needed or not).

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model
the trivial business process scenerio isn't that it is a central IBM mainframe, or it is a clusterd-distributed open system and/or whether or not there is back-up. The X9.59 model (and AADS) is that the signature authentication is done at the point that the transaction is approved. seperating the authentication of the transaction and the approval/execution of the transaction is one of the things that creates systemic risks.

Seperating the authentication from the transaction approval/execution doesn't improve the availability of the system ... because if the decision point that executes the transaction is down ... having the authentication part up and running does nothing.

This isn't a centralized or decentralized issue ... this is coupling the approval, authentication, and execution into a single business operation ... which actual improves the availability as well as reducing systemic risk.

Having three different things that all must be up is the product of their individual availability ... it is only when the three things all can each complete the operation that you have availability of "one minus the product of their invididual non-availability". Three serialized processing units each with .95 availability have a business process availability of ,86. Three independent operations, each capable of completing, and each having a .05 non-availability has a business process availability of five-nines (i.e. .999998).

This isn't an issue of private & public CA .... AADS just integrates digital signatures into the standard financial business processing model ... instead of creating an independent authentication process.

At the same time ... it doesn't preclude or exclude CADS for non-financial processing transactions. A person, if they wanted to, might choose to register the same public key with multiple authorities ... in the same way they open multiple accounts and sign multiple signature cards.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model
There are several differences between a Certification Authority Digital Signature model (CADS) and an Account Authority Digital Signature model (AADS).

Model two or AADS has the account-holder registering a public key with their financial institution almost identical to the way a public key is registered in CADS ... but no certificate is issued; the public key just goes into the database. While the technical processing looks like CADS ... the AADS business process just mimicks signing a signature card when opening an account.

From a financial business standpoint, the AADS is really only an electronic version of a signature. There is no reliance on a certificate by the financial business process ... AADS strictly emulates the existing business process but with a digital signature. There is no worry about any liability associated with somebody attaching meaning to a certificate/credential since there are none.

In a CADS scenerio, with a certificate playing some role in a financial transaction authentication process, the AADS model eliminates extraneous computational intensive cryptographic operations associated with validating the certificate (and/or any certificates in a CA-hierarchy). The X9.59 payment object requires a single digital signature and a single digital signature verification.

Also in a couple meetings with some very smart financial folks this past week, it was pointed out that the lack of certificates and Certification Authority (especially one independent of the financial house) eliminates systemic risks to financial infrastructure associated with various kinds of Certification Authority &/or certification private key failures. Compromise of individual private keys can still occur but there is no systemic compromise of the infrastructure.

NSCC relying on a certificate (and therefor the real-time integrity of the CA's infrastructure) only for registration (and not for any financial transaction approval or processing decisions) could significantly mitigate the systemic risk to the financial infrastructure (except possibly attacks involving re-keying of accounts).

To some extent X9.59 (and my work on AADS) has been:
exactly mimick the existing financial business processes where possible
eliminate unecessary computational intensive cryptograpic operations

i.e. looking at how signatures operate in the existing account-based financial business processes and simply translating that into digital signatures resulted in realizing that certificates were superfluous (in this specific instance).

X9A10 is a working group in X9A (some information at
http://www.x9.org/). At the moment on the web there is only a presentation by chair of X9A10 (Tom Jones) given at the July EPF meeting (check July presentations at

For financial transactions, my guesstimate has been the trade-off is some where around 5% participation of accounts where independent certification pilot implementations and core-processing integration cross over. AADS-model assumes core-processing integration, so it requires more upfront commitment by a financial institution (but the business costs should scale much better since it is now part of the normal operation).

I can take your CAIP invitation to the appropriate FDC business people.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

AADS/CADS complexity issue

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS/CADS complexity issue
There is no need for the registration authority (AADS) to communicate any compromise if there has been no trust propagation via a certificate.

We have looked at three registration options/scenerios for financial AADS:
    owner generates random seed and random public/private key pair. owner communicates the public key to the AADS along with some proof of knowing the private key
    interactive session between the account-authority and the owner, where the account-authority provides part of the random seed that goes into the public/private key generation. there are some hardware boxes that provide extremely strong random seed values. A financial institution might decide that the such of such a box would improve the key generation.
    A financial account-authority may use a hardware box to generate strong private/public key pairs and transmit both keys during a session. Assuming that the specific private key is only used in financial transactions at the account-authority there is no issue of non-repudiation (i.e. there are more easier ways for an untrustworthy financial institution to generate bogus transactions against a customer's account ... than going to the trouble of a private key transaction).

A purpose of a certificate is trust propagation. If an AADS is not interested in trust propagation, then it doesn't gain anything by signing a certificate (and in fact, opens itself to trust propagation when none was intended). Not signing a certificate eliminates the possibility that an AADS's trust is propagated.

Whether or not an AADS chooses to support trust propagation should be strictly a business decision, and therefor the manufacturing of a signed certificate should be a business decision.

Furthermore, there is nothing that would prevent a user from generating a self-signed certificate or for the user to use the same public/private key pair in registration with multiple different authorities (some of which might support certificate signing).

I've theorized that the issue of liability insurance for CADS might be viewed as a bug in the business model. Certificates potentially open the authority up to an unlimited number of uses for unconstrained types of uses. An AADS choosing to operate w/o certificates totally eliminates that bug. All transactions come to the AADS for approval, and therefor it knows each instance and type of use (eliminating trust propagation and the potential unwanted liability side-effects).

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS/CADS complexity issue
The AADS/CADS complexity issue is actually quite trivial from the technical standpoint ... it is whether the certificate flows thru with the transaction or not ... and is very straightforward option to support. The business process implications of depending on the certificate infrastructure which reduces the integrity of the transaction and introduces additional unnecessary systemic risk is significant..

The real complexity of the domain of x9.59 transactions isn't in the AADS/CADS option but in providing the virtual document processing necessary to compensate for existing legacy networks (that will carry the transaction). For the different types of transactions and networks, they do seem to share the characteristic of supporting optional fields for transactions.

X9.59 examines the types of existing fields in transactions arriving at the financial institution for execution and determines which of the fields contain values known to the originator of the transaction. This is going to be different for the different types of financial transactions and networks. For each type, X9.59 defines a virtual document that consists of
    canonical representation of the values known to the originator (and to the financial institution)
    additional values necessary for the integrity and/or cryptographic strength of the transaction.

The originator of the transaction creates the x9.59 virtual document (appropriate to the type of transaction) and signs it. The originator then creates an x9.59 opaque object that consists of the signature of the virtual document and any of the necessary additional values. The transaction-type unique x9.59 opaque object is pushed with the transaction. At the point where the transaction enters the legacy network, the x9.59 opaque object is placed in some type of addenda field.

When the transaction and x9.59 opaque field arrives at the financial institution, the same virtual document must be rebuilt from a combination of transaction values and values from the x9.59 opaque field. Then the digital signature of the virtual document can be verified from the public key in the account record.

The AADS/CADS option processing (i.e. certificate or no certificate) in the transaction is technically trivial compared to the virtual document complexity processing that will be unique to each kind of legacy transaction.

Note x9.59 is only defining the payer to payee formats. However, the x9.59 opaque field will tend to be unique to the type of payment transaction. For the rest of the processing, X9.59 is only defining the integrity requirements and that the x9.59 opaque field is carried with the transaction through to the payer's financial institution (and that the payer's financial institution perform digital signature verification on the transaction using the contents of the x9.59 opaque field).

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".


Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: parsimonious
i afraid i spent some amount of my career on processor and kernel products ... it left a legacy of reducing things to atomic units ... that with a long career supporting business operations ... results in a tendency to forcing a match between atomic units and business processes (and making sure they are industrial strength ... so preferably they never fail and/or all their failure modes are well understand and manageable/recoverable).

if there is a real reliance on certificates in a business process ... then from a industrial design point-of-view the certificate infrastructure may have to meet the same industrial engineering requirements as the rest of the business process implementation. this also relates to my previous comments about removing systemic risks from mainline financial business processing.

I once had a hostile I/O environment which generated hundreds of faults per day (normal operations wouldn't see these faults more than once a year). An industrial strength mainframe system tended to fail within 15 minutes of coming up in this environment. I undertook to completely rewrite the input/output subsystem so that all possible fault scenerios were handled and the IOS could never be a cause of a system failure ... even after they significantly increased the size of the hostile environment.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

AADS & X9.59 performance and algorithm key sizes

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: AADS & X9.59 performance and algorithm key sizes
An interesting analysis of AADS is the incremental delta of EC-DSS (see recently passed x9.62) in an account authority environment. Given a 200-300 byte account record, there is a major incremental difference between a EC-DSS public key field and a RSA public key field. The impact is not only to the difference in relative disk space increase for the account file size (possibly a 10% increase vis-a-vis a 100% (or more) increase ... i.e. to add a public key field to every existing account record) ... but also the impact on I/O bus utilization as well as hardware, system, and DBMS cache efficiencies (&/or requirements) when the records are read, processed, updated and/or written.

AADS & X9.59 performance and algorithm key sizes

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS & X9.59 performance and algorithm key sizes
part of the problem is that lots of the real numbers are business sensitive.

not too long ago come off a small pilot project involving introducing new type of processing for 60 million of the accounts ... overall infrastructure might avg 1000 trans/sec during peak hrs ... the 60 million is only subset of the total environment. One of the interesting things is that the few cents is somewhat variable depending on what the client has selected for the accounts in their portoflio ... and therefor what they are charged for a trans. there are something like 170 optional features (before we started our project) that might be selected for processing for an account in particular portfolio ... and that is even further broken up with different groups of accounts within a portfolio having different processing options (like gold cards might be slightly different from platinum cards might be slightly different from regular cards). The feature selection somewhat varies the processing costs as well as what is priced on a per transaction basis.

i can relate to your new technology scenerio. several years ago i was doing something for the largest online system in the world (i.e. at the time they would avg upwards of 4000 trans/sec during peak hrs) ... they had an application that represented something like 25% of the system and they had a list of ten impossible things that they needed to do. I went away for 2 months and taking a totally different paradigm approach redesigned and re-implemented their application from scratch and came back and demo'ed it. I had also speeded it up by a factor of 100 ... but since one of the 10 impossible required 10* the processing ... it only netted about 10* performance increase (although I did collapsed 4 human transactions into a single operation so the elapsed human time improved by a much larger factor). They didn't know what to do with it. Part of the problem was that they possibly had upwards of 1000 people supporting the application as it was ... the new paradigm reduced the support requirements to possibly 25-35 (in part, some of the impossible things were impossible because they had 1000 people involved). To introduce the revised application would have had enormous organizational impact. This turned out to be more significant than not being able to perform their ten impossible things.

The key-length field size is just one of the issues raised in a CADS->AADS paradigm shift.

Another issue that sometimes has been hard to come to grips with is the liability issue ... it becomes much simpler.. Without certificates there are no certification authorities, without certification authorities there is no certification, without certification there are no relying parties relying on certification done by trusted third parties, without relying parties relying on certification done by trusted third parties there is no liability, without liability there are no legal discussions, government CA associations, state legislation, federal legislation, UN guidelines, CA policies and practices statements, liability limitation statements, etc. It is remarkable what happens sometimes when you shift the paradigm.

All of this is propagated when the CA digitally signs a certificate that attests to some binding between a public key and some identity or set of attributes ... that a relying party becomes dependent on (and can totally disappear in a AADS infrastructure). There still may be individual liability depending on how their digital signature on a transaction is treated. If signature is on a financial transaction ... then it could be treated as a more secure form of pin authentication ... in which case it can fall totally within existing regulations. For deployment then some of the hardest becomes where to sprinkle a couple hundred lines of code in several different places (all dependent on, of course, on a highly trusted crypto library).

AADS & X9.59 performance and algorithm key sizes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: RE: AADS & X9.59 performance and algorithm key sizes
the scenerio goes both ways ... government providing identification certificates that population use when opening accounts and therefor meeting government "know your customer" mandates. problem is that government would have a hard time funding an infrastructure for such a single use. the other side is that financial institutions are less concerned about DNA-like identity and more concerned with "credit-history" identity ... these are somewhat a disjoint set.

the major scenerio proposed for certificates so far are the "comfort" certificates for internet electronic commerce. merchant electronic commerce servers present a "comfort" certificate indicating an entity that represents a great deal of comfort to consumers stands behind the merchant (and certified that the merchant meets certain standards). In fact, consumer comfort certificates seem to be applicable to wide-range of webservers.

Comfort certificates are view as part of electronic commerce but outside the x9.59 payment architecture ... since the comfort certificate isn't necessary to guarantee the integrity of the financial infrastructure. The consumer's digital signature on the payment instruction (with the rest of the processing) is sufficient to guarantee the integrity of the financial infrastructure. Another property is that since there is no consumer certificate ... the associated privacy exposure has been eliminated.

Major objectives of x9.59
stronger integrity than other payment protocols
integrity achieved w/o requiring encryption
maximize privacy while working efficiently (and not requirig encryption)
work in all electronic payment environments, not restricted to just internet/web ... but also support things like POS, ATM, settop boxes and new forms not yet thot of.

and one of my favorites: KISS

Human Nature ... a little cross-posting

From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject:  Re: [E-CARM] Human Nature ... a little cross-posting
original premise was somewhat that a purchase order authorization system could be re-engineered to be certificate based ... effectively with certificates carrying authorization attributes necessary for the PO infrastructure to operate

From: Lynn Wheeler
To: <e-carm@xxxxxxxx>
Subject:  Re: [E-CARM] Human Nature
certificates provide a new way of binding a set of attributes together ... typically in conjunction with a public key.

for years business has used account records to perform similar functions, attribute binding ... and frequently in conjunction with authorization and even authentication attributes (even for non-face-to-face transactions, pins, id-numbers, mothers-maiden-name, etc have been used as mechanism for authentication). even if a small number of these attributes were moved from account records into a certificate ... there haven't been many proposals so far indicating that all attributes could be moved to a certificate and account records done away with. For instance real time status attributes, current disposition of the order, has it left the loading dock, what is the shipping tracking number, has the order been billed net-30, net-60, net-90 ... would there be aggregation of orders for billing and has the bill been sent and/or paid ... possibly hundreds of attributes in total ... only a small number of which have been considered for re-engineering into certificates.

conversely it is relatively straight-forward sequence to go the other way ... rather than binding re-engineering all the attributes of business into certificates ... add public key registration to an account record ... so that account record bindings include a public key for authentication ... so that public key is added to the other forms of authentication and digital signature is added to forms of authorization.

certificates do have the seductive quality of apparent ease of adding attributes in a non-centralized, distributed manner. a problem crops up in real-world business where subtracting/nullifying is as important and sometimes more critical than adding. technology for flushing nullified certificates has been moving more & more towards centralized operation ... resulting in certificate operation looking more and more like account management ... at which point it is account-based management with this thin veneer of superfluous certificate wrapping.

From: Lynn Wheeler
To: "e-carm" <e-carm@xxxxxxxx>
Subject:  Re: [E-CARM] Human Nature (example)
lets say that individual has PO signing authority for individual purchases up to $1000 with a specific supplier to not exceed $10,000 a month with that supplier ... assuming that at the supplier the company has had its bills paid and the "account" is in good credit standing. furthermore, the individual's departmental monthly budget is $50,000/month and $400,000/year (across all supplier's).

scenerio is that digitally signed purchase order goes to the accounting office for verification that the account that the overall accont numbers are in good standing ... at which time the accounting department updates the departments account record and digitally signs the PO and sends it to the supplier.

The supplier checks the account department's digital signature against what is on file ... and verifies the company's account is in good credit standing. The supplier then updates the account record for the company and cuts a order.

The supplier doesn't really need to know the public key of each individual able to cut purchasing orders ... just the public key of the authorizing department (since it isn't likely the supplier can making any authorization judgements about internal corporate budgeting proceedures)

Going with just a certificate binding with an individual's public key as sufficient to both authenticate and authorize a purchase order is usually too simplistic ... since the actual authorization process can involve a multiplicity of highly dynamic & complex states as well as dynamic state aggregations ... effectively impossible to represent in a certificate binding architecture.

Digital signatures provide for strong authentication in an account based environment ... when the public key(s) has been registered in the account record ... and the account record represents the binding of real world complex & dynamic authorization attributes.

Playing out authorization attributes in certificates creates opportunity for fraud because the certificate authorization attributes are unlikely to represent real-time states and/or state aggregations.

AADS, X9.59, security, flaws, privacy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject: AADS, X9.59, security, flaws, privacy
The other fraud play is the separation of authentication and authorization.

Several existing payment protocols separate authentication and authorization and this separation opens up opportunity for fraud. At very high level ... almost all security paradigms recognize that if authentication and authorization are separated ... that represents a hole in the security and a potential for breaches to occur.

In X9.59 protocol mappings, AADS at the consumer's financial institution is used to authenticate the consumer's digital signature (and the transaction) as well as using the rest of the information in the account record to authorize the transaction.

In practice, not only are the merchants primarily interested in knowing that they would be paid ... but if other than the consumer's financial institution authenticate a transaction ... when the same entity isn't also authorizing the transaction represents a security flaw. Furthermore, in a x509 certificate-based scenario ... there will also be privacy issues involved with the consumer unnecessarily divulging personal information to a merchant.

A very fundamental rule of security is never separate authentication and authorization.
A very fundamental rule of privacy is never unnecessarily divulge personal information.

Having a merchant authenticate anything (when it isn't also authorizing it) is at best superfluous work ... assuming that the consumer's financial institution also authenticates the same information and at worst a security flaw (if turns out to not be superfluous).

Use of X509 certificates tend to be a privacy violation ... and since the certificates are available ... there will also be a tendency to perform some sort of authentication; such authentication is either redundant (and therefor superfluous) or a security flaw (if not redundant).

Also, in the X9.59/AADS scenerio there is the efficiency issue ... both from the technical processing stand point as well as from the business process operational stand point. X9.59 simply would add a digital signature to existing payment instruction.

Fron a technical processing stand point there is a very modust increase in resources used (message size, handling, etc) since it basically represents the addition of a digital signature to an existing message.

From a business process operational stand point the efficiency improvement is even more significant. It is effectively the current infrastructure, the same business operations and no new or additional distributed parties (requiring regulatory or other administrative infrastructure changes, including issues regarding liability).

This also leads to the systemic risk issue. Since there is no seperation of authentication and authorization, the associated security flaws are eliminated. Also, since the authentication and authorization are combined there is no distributed operation failure modes (i.e. the authorization/authentication party ... the consumer's financial institution has no responsibility for contacting any outside agent regarding things like CRLs, current status, etc). Furthermore there are no new single point of failure attacks/failures (like the issuing CA and/or the CA's signing key).

AADS & X9.59 performance and algorithm key sizes

From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject: AADS & X9.59 performance and algorithm key sizes
there is sometimes a compelling business reason for creating security holes with seperation of authorization and authentication ... but that doesn't eliminate the basic premise that the seperation opens up security exposures. In a DMV case, driving ability, eye-sight and address are a number of things that might change (although not nomarlly birthdate) .... and have been some of the things assessed as to cost to close the holes against the risk exposure.

Driver's licenses have been used to authenticate check acceptance in totally offline environment ... this is a scenerio where there is a enormous hole with seperation of authentication and authorization; the use of driver's license doesn't eliminate the hole ... it is used to try and make the hole slightly smaller.

In the case of birthdate, much of the liability (created by speration of authentication and authorization; security talks about security holes, business uses liability in similar way) is created by the same government infrastructure responsible for the DMV ... and is much simpler for them to specify that driver's license is sufficient due diligence to authenticate birthdate. The security holes created by the seperation (or the liability when speaking businessees) gets more complex in financial arena since it very likely involves different business entities.

Having legislation limit the liability ... doesn't mean that the liability (created by the seperation) doesn't exist ... just means that government has decided to regulate it for some reason.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

dbts: More on law vs economics

From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: dbts: More on law vs economics
some misc. related factors.

span of control for governments (& corporations) have periodically been considered limited base on speed of communication or travel (ala the roman roads) or management of complexity. Technology applied to areas other than financial infrastructure can improve efficiency and reduce costs in communication & management area ... which would argue for enabling larger organizations ... rather than smaller.

in fact, one current critical, enabling technology at the basis for much of the transition to information age ... is very complicated, very expensive chip fab lines. it is hard to see how any of this would continue to operate w/o massive financial & organizational aggregations that are behind creating & sustaining those fab. lines. W/o the scale, expense and complication of those fab lines ... the necessary technology enablers would be likely be 100* (or more) expensive (and at least one argument is transitions will occur because less expensive .... there is transition to the less expensive alternatives .... but much of this wouldn't exist if the $300 computing devices were $30,000 instead).

While application of new technology in various areas .... may lead to obsoleting various organizations that had been necessary for managing complexity and scale .... the new technology has in turn its own dependencies on large, complex organizations that require massive financial aggregation .... which in tern has various orgnaizational dependencies (design/development, sales, marketing, distribution channels, outlets, revenue aggregation, etc). Would you gamble couple billion on new fab line .... if you weren't confident of operations & conditions in place that would allow recovering the investment? Conversely, it is how to imagine how the current opportunities would have come into being .... and/or will continue to exist w/o massive financial aggregation ... and the organizations that go with its support.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

Statistical Attack Against Virtual Banks (fwd)

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: Statistical Attack Against Virtual Banks (fwd)
i think that a distinction can be made between using digital signature for strong authentication in conjunction with financial transactions and needing a x509v3 identify certificate for validating the digital signature. in fact, x509v3 identity certificattes can introduce unnecessary systemic risks and/or unnecessarily impact privacy information.

i believe design point of public key certificates introduced "binding" of public key and other information for environments that lacked any binding infrastructure (i.e. offline email paradigm from the early to mid 80s). banks & other business operations have long had business processes and high integrity binding infrastructures in their account records ... adding public key binding to account records for online transactions eliminates having to duplicate an extraneous binding infrastructure which can be prone to referential integrity problems and relying on stale &/or out of date information at the time the certificate was manufactured as well as unecessary business processes.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".