X9.59 mailing list

x959 Postings and Posting Index,
next, previous - home

Online Card Fraud Thirty Times That Offline
X9.59 Electronic Payment standard status
X9.59 Electronic Payment standard issue
ANSI X9 Electronic Standards "store"
X9.59 Web site??
Intel Developer's Forum ... fyi
some electronic commerce discussion from dcsb & IDF
implementations of "XML Voucher: Generic Voucher Language"?
implementations of "XML Voucher: Generic Voucher Language"?
harvesting of credit card numbers
shared-secrets, CC#, & harvesting CC#
X9.59 available at the ANSI X9 online publication store
GAO: Government faces obstacles in PKI security adoption
GAO: Government faces obstacles in PKI security adoption
GAO: Government faces obstacles in PKI security adoption
GAO: Government faces obstacles in PKI security adoption
best ketp secrets of money(?)
7th CACR Information Security Workshop
7th CACR Information Security Workshop
assurance, X9.59, etc
Digital Signatures Spark Debate
Announce: Eric Hughes giving Stanford EE380 talk this
Announce: Eric Hughes giving Stanford EE380 talk this
do CRL's actually work?
Electronic Commerce Modeling Language
AADS NWI closed two years ago today
latest credit scam puts plastic in peril ... is your credit card being cloned?
use of digital signatures and PKI
Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi
use of digital signatures and PKI
use of digital signatures and PKI (addenda)
Entrust To Cut 400 Jobs .... fyi
problem with the death of X.509 PKI (forwarded)
use of digital signatures and PKI (addenda)
use of digital signatures and PKI (addenda)
"out of control credit card fraud"
"out of control credit card fraud"
call for new measures: ICH would be glad to help
MS masters NC mind-set (authentication is the key)
MS masters NC mind-set (authentication is the key)
"Gurard against Identity Theft" (arrived in the post today)

Online Card Fraud Thirty Times That Offline

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 08:36 AM
To: ansi-epay@xxxxxxxx
Subject: Online Card Fraud Thirty Times That Offline

Online Card Fraud Thirty Times That Offline


Dec 19 2000 : Online merchants are experiencing fraud rates of 30 times higher than their real-world counterparts this holiday season, according to new research from Celent Communications. The report, "Online Payment Fraud: The Grinch That Stole e-Christmas?", predicts Web stores to lose USD 300 million to fraudulent payments, or 3 per cent of total holiday eCommerce sales, by year-end 2000. However, Celent expects credit card firms to "come to the rescue with a workable solution that reaches critical mass within 3 to 5 years".

For now, Celent predicts a growing number of merchants to adopt score-based solutions to combat online fraud, since merchants "struggling to be profitable" already foot the bill for losses. While Forrester Research predicts eCommerce to grow from USD 8 billion in 1999, to USD 108 billion in 2003, IDC expects aggregate fraud-related losses of USD 200 million from this year's USD 12 billion. In July 2000, Gartner found e-tailers to incur 2.64% online charge back rates, with fraudulent or stolen credit cards accounting for 1.13%.

Odyssey Research also noted fear of credit card fraud to be a significant barrier to on-line purchasing, with 31 per cent concerned about credit card fraud, and 25 per cent not trusting the Internet. Still, a joint survey by Goldman Sachs and PC Data, recorded a 50 per cent growth in online sales during the week after Thanksgiving, compared to the same period in 1999. Accordingly, PC Data concluded that online spending volume was being spread across several weeks, rather than spiking, as in December last year.

X9.59 Electronic Payment standard status

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 09:55 AM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Electronic Payment standard status
The X9.59 DSTU period starts Feb. 1, 2001 and runs through Jan. 31, 2003

The X9.59 DSTU standards document should appear in the next standards publication catalogue:
DSTU X9.59-2001, Electronic Commerce For the Financial Services Industry: Account-Based Secure Payment Objects

X9.59 defines a secure payment object for use in authenticated financial transactions. It relies on existing X9F security standards for payment object authentication. It supports secure payments involving virtual (e.g. Internet) or face-to-face transactions. It applies to card-based (e.g. smart card) financial transactions as well as other forms of electronic financial transactions (e.g. e-check).

X9.59 Electronic Payment standard issue

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 03:26 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Electronic Payment standard issue
One of the complaints about the X9.59 standards document (especially from X9F) is that it doesn't specify key management standards.

X9.59 defines a secure payment object that can be used in authenticated transactions using X9F authentication standards.

As such it relies on X9F authentication standards ... and where X9F authentication standards involve keys (symmetric &/or public/private), protection of keys is somewhat part of the related X9F standard involving that particular authentication standard.

A related issue is that many of the X9F key-related standards are applied to wholesale transactions and/or backroom portions of retail transactions. One of the things that X9.59 is potentially moving into is the direct involvement of consumers with keys. This may be on-par with the existing PINs which is not unusual to find consumers having written on their magstripe card.

while wholesale environments have a little more luxary in specifying a single key management standard across all environments (in part because the cost of key management tends to be only a small percentage of the overall costs) ... retail arenas tend to be somewhat more cost sensitive and ideas like parameterised risk management come into play (i.e. integrity costs proportional to the related values & risk in the envrionment). The issue is that in some cases, incremental integrity costs can be a multiple of existing costs as opposed to a small percentage of existing costs.

Simplifying somewhat, parameterised risk management would indicate that the integirty costs (like key protection) should be proportional to the related transaction values being protected &/or related risk/fraud. This might be an interesting emerging security area, being able to establish integrity costs proportional to risk.

In another area, one of the related advantages of X9.59 is that it specifies that account numbers used in X9.59 only be usable in authenticated transactions i.e. it is not possible to evesedrop and/or collect large numbers of X9.59 account numbers and use them in un-related, fraudulent un-authenticated transactions.

As a result, it significantly mitigates some of the end-to-end integrity costs associated with management of shared-secret account numbers (i.e. account numbers that can be collected and used in un-related, fraudulent, un-authenticated transactions).

ANSI X9 Electronic Standards "store"

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/26/2001 01:33 PM
To: ansi-epay@xxxxxxxx
Subject: ANSI X9 Electronic Standards "store"
The X9 portion of the ANSI standards document electronic store is at:

http://webstore.ansi.org/ansidocstore/dept.asp?dept_id=80 Ansidocstore: Department: 'X9 (ABA): Financial Services'

X9.59 should be showing up there any moment.

current list ....
Document Title

ANSI X9  DSTU-2-1995
EBT Processor Interface Technical Specifications
ANSI X9.1-1991
Bank Cards - Magnetic Stripe Content for Track 3
ANSI X9.10-1992 (R1998)
Merchant Category Codes
ANSI X9.12-1991 (R1998)
Municipal Securities, Specifications for Fully Registered
ANSI X9.13-1999
Placement and Location of MICR Printing, Specifications
                          for the
ANSI X9.14-1983 (R1995)
Securities Transaction Interchange Forms,
                       Specifications for
ANSI X9.15-1990 (R1996)
Specification for Financial Message Exchange Between
Card Acceptor and Acquirer
ANSI X9.18-1998
Paper Specifications for Checks
ANSI X9.19-1996
Financial Institution Retail Message Authentication
ANSI X9.20-1998
Securities - Institutional Delivery System
ANSI X9.24-1998
Financial Services - Retail Management
ANSI X9.27-2000
Print and Test Specifications for Magnetic Ink Printing
ANSI X9.29-1998
Financial Services - Check Carrier Envelope
ANSI X9.30.1-1997
Public Key Cryptography for the Financial Services
Industry - Part 1: The Digital Signature Algorithm (DSA)
ANSI X9.30.2-1997
Public Key Cryptography for the Financial Services
           Industry - Part 2: The Secure Hash Algorithm (SHA-1)
ANSI X9.31-1998
Digital Signatures Using Reversible Public Key
          Cryptography for the Financial Services Industry (rDSA)
ANSI X9.32-1998
Data Compression in Wholesale Financial
ANSI X9.33-1999
Specifications for Bank Deposit Tickets
ANSI X9.34-1993
Asset Sales
ANSI X9.37-1994
Specification for Electronic Check Exchange
ANSI X9.40-1998
Check Strip Extension
ANSI X9.45-1999
Enhanced Management Controls Using Digital
                Signatures and Attribute Certificates
ANSI X9.46-1997
Financial Image Interchange: Architecture, Overview, and
                   System Design Specification
ANSI X9.47-2000
Creating MICR Document Specification Forms
ANSI X9.49-1998
           Secure Remote Access to Financial Services for the
Financial Industry
ANSI X9.5-1988 (R1994)
Financial Institution Numbering System (FINS)
ANSI X9.51-1998
Fraud Deterrent Icon Standard
ANSI X9.52-1998
Triple Data Encryption Algorithm Modes of Operation
ANSI X9.53-1996
Specifications for Check Endorsements Including
ANSI X9.55-1997
Public Key Cryptography for the Financial Services
            Industry: Extensions to Public Key Certificates and
Certificate Revocation Lists
ANSI X9.57-1997
Public Key Cryptography for the Financial Services
Industry: Certificate Management
ANSI X9.6-1991 (R1998)
                     Securities Identification
ANSI X9.62-1998
Public Key Cryptography for the Financial Services
          Industry : The Elliptic Curve Digital Signature Algorithm
ANSI X9.69-1998
Framework for Key Management Extensions
ANSI X9.7-1999
Bank Check Background and Convenience Amount Field
ANSI X9.71-2000
Keyed Hash Message Authentication Code (MAC)
ANSI X9.8-1995
Banking – Personal Identification Number Management
           and Security – Part 1: PIN Protection Principles and
Techniques; Part 2: Approved Algorithms for PIN
ANSI/ABA X9 Data and Information Security Collection

ANSI/ABA X9 Paper Check Collection
           ANSI/ABA X9 Retail Electronic, Security and Electronic
Benefits Transfer Collection
                 ANSI/ABA X9 Securities Collection
X9 TG-10-1994
Signature Guarantee Guideline
X9 TG-15-1997
            Technical Guideline: to aid in the Understanding &
Implementation of Financial Image Interchange
X9 TG-19-1-1999
Part 1: Modes of Operation Validation System for the
Triple Data Encryption Algorithm (TMOVS):
                  Requirements and Procedures
X9 TG-2-1995
Understanding and Designing Checks
X9 TG-23-1-1999
            Implementation Guide for ISO 8583-Based Card
Acceptor to Host Messages - Part 1 - Conveinence Store
                 and Petroleum Marketing Industry
X9 TG-3-1997
Pin Security Compliance Guideline
                              (free download now)

X9 TG-4-1993
Recommended Notation for DEA Key Mgmnt in Retail
Fin. Networks
X9 TG-5-1992
                  Information Security Guideline
X9 TG-6-2000
Financial Services Technical Guideline
X9 TG-7-1995
             Initial DEA Key Dist. for PIN Entry & Transaction
Originating Dev.
X9 TG-8-1995
                    Check Security Guideline
X9 TG-9-1995
Abstract Syntax Notation and Encoding Rules for Inf. Ind.

X9.59 Web site??

From: Lynn Wheeler
Date: 02/12/2001 12:15 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Web site??
happened to stumble across the following (doing a query on x9.59 w/fast search engine)


Intel Developer's Forum ... fyi

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/25/2001 10:07 AM
To: ansi-epay@xxxxxxxx
Subject: Intel Developer's Forum ... fyi
Intel Developer's Forum starts tomorrow in San Jose. I'm on a panel discussion talking about assurance. One of the subjects is e-commerce (and some X9.59 standard)



some electronic commerce discussion from dcsb & IDF

From: Lynn Wheeler
Date: 03/02/2001 10:40 AM
To: ansi-epay@xxxxxxxx
Subject: some electronic commerce discussion from dcsb & IDF
some electronic commerce discussion from dcsb & assurance panel at Intel Developer's forum:


misc. other



implementations of "XML Voucher: Generic Voucher Language" ?

From: Lynn Wheeler
Date: 03/08/2001 12:06 PM
To: iang@xxxxxxxx
cc: Ko Fujimura <fujimura@xxxxxxxx>, Rachel Willmer
<rachel@xxxxxxxx>, dbs@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
note that in the mapping of X9.59 to iso8583 ... the payment transaction isn't being done in ASN.1 ... it is being done in ISO8583 messages.

The encoding mechanism in the standard for digital signing and digital signature verification is ASN.1 ... but the mapping to ISO8583 is basically ISO85893 messages. The small caveat is that fields that are defined in X9.59 and not in ISO8583 are (at least for the mapping example) are package as purely binary and placed in an ISO8583 message "addenda" field.

At the financial backend ... for signature verification the original signed message has to be reconstructed. Since the original encoded signed format was ASN.1, the bits have to be re-encoded in ASN.1 in order to do the signature verification.

The FSML version would be to encode the fields in FSML before doing the digital signature and then at the backend re-encode all the fields in FSML to do the digital signature.

The X9.59 mapping to ISO8583 for the actual financial transaction message would be exactly the same whether ASN.1 or FSML was used for the signature encoding mechanism.

One of the slight twists in FSML compared to XML was that the encoding rules had to be strictly deterministic i.e. the backend needs to be able to exactly reconstruct the original signed message bit-for-bit, in order for the signature to verify. The base XML encoding rules were not exactly deterministic (things like trailing blanks, leading zeros, trailing zeros, misc. other things).

X9.59 does include a version number which could be used to indicate things like additional fields in a message and/or encoding rules for the original message.

Note, that X9.59 mapped to other environments might not necessarily used the decomposition process used for mapping X9.59 to ISO8583; aka the signed message and the transmitted message might be bit-for-bit the same. It is somewhat a toss-up for the backend. In the X9.59 mapping to ISO8583 example, the bits effectively arrived in un-encoded format (i.e. already decoded) and must be re-encoded for the signature verification. In a scenerio where the bits transmitted are the same as the bits signed, the encoded form arrives at the backend, the signature can be verified, and then the message decoded in order for the backend to operate on the fields in the message. Except for the requirement for strict encoding rules ... there is an encoding operation replaced with a decoding operation.

a sense of the financial representation in X9.59 can be found in the mapping from X9.59 to ISO8583 (i.e. ISO8583 defines standard ISO currency codes, regardless of whether it is ASN.1 encoded or FSML/XML encoded).

http://www.garlic.com/~lynn/8583flow.htm (from iso8583 field definition)
bit 2 : primary account number, LLVAR, n..19
bit 4 : amount, transaction, n 12
bit 14 : date, expiration, YYMM, n 4
bit 42 : card acceptor identification code, ans 15
bit 49 : currency code, transaction, a 3 or n 3

there has been some investigation that when mapped iso8583, the transaction amount is limited to twelve digits. This has been identified as a possible problem given the inflation and currency values in some countries ... that some reasonably high-value items might exceed 12 digits in some local currencies.

they are promising that the X9.59 standard should be back from the printer any day now and should show up momentarily on the ANSI/ANS electronic store web site.



there are currently no deployed production implementations of X9.59 i.e. financial processor accepting the X9.59 addenda field in an ISO8583 interchange message, as well as taging account numbers as valid for use only in authenticated transactions ... aka the harvasting of account numbers involved in X9.59 could not be taken and used in fraudulent non-authenticated transactions.

Ian Grigg on 03/08/2001 09:39:42 AM wrote:
lynn.wheeler@xxxxxxxx wrote:
> as an aside, X9.59 financial standard that recently passed (electronic standard
> for all retail payments) also incorporates the message digest of the purchase
> order (or contract) in the body of the payment message.

Right, as an audit trail method. We do that too in the description, as desired by the application.

We are specifically talking here about the money - the value contract is hashed and that becomes the money identifier. What does x9.59 use as its money identifier? An ISO TLA is the most common method, but I've seen all sorts (4 byte integers, telephone prefixes...) ? FSML uses it for example. If x9.59 uses ISO TLAs then it doesn't include a value contract at all, and it will be hamstrung in real finance.

Also, are there any extant implementations of the standard? Any real transactions?

> as specified in the standard, the payment message encoding format is ASN.1 ...
> however the appendix includes an example in FSML (financial standards markup
> language ... precursor to much of the XML financial related specifications).

Doing the payment in ASN.1 is fine, there is only limited applicability IMHO to doing it in XML, notwithstanding the intentions of FSML and others.

> for some fsml related information
> http://www.echeck.org/

I printed out the 1.5. The document formatting rules look like a useful starting point for XML contracts (including the Voucher work).

The rest of the document seems to be oriented to check processing. Even though it claims that it might be used for generic documents, I doubt it, as there are too many assumptions about how checks work built into it, as well as lots of protocol stuff.


implementations of "XML Voucher: Generic Voucher Language" ?

From: Lynn Wheeler
Date: 03/08/2001 01:30 PM
To: ansi-epay@xxxxxxxx
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
note ... as an aside, thread start in another mailing list ... previous message can be seen at:


harvesting of credit card numbers

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/08/2001 05:07 PM
To: ansi-epay@xxxxxxxx
Subject: harvesting of credit card numbers

Large Criminal Hacker Attack on Windows NT E-Banking and E-Commerce Sites

3:00 PM EST, Thursday, March 8, 2001

In the largest criminal Internet attack to date, a group of Eastern European hackers has spent a year systematically exploiting known Windows NT vulnerabilities to steal customer data. More than a million credit cards have been taken and more than 40 sites have been victimized.

The FBI and Secret Service are taking the unprecedented step of releasing detailed forensic information from ongoing investigations because of the importance of the attacks.

shared-secrets, CC#, & harvesting CC#

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/08/2001 07:41 PM
To: ansi-epay@xxxxxxxx
Subject: shared-secrets, CC#, & harvesting CC#
discussions recently on sci.crypt regarding x9.59 being able to effect a transition from a shared-secret environment to a "secret" environment (i.e. x9.59 eliminating CC# as harvesting targets)





from previous postings on this list regarding probability that large number of web servers will all operate perfectly (regardless of any set of security guidelines)







X9.59 available at the ANSI X9 online publication store

From: Lynn Wheeler
Date: 03/08/2001 09:17 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 available at the ANSI X9 online publication store
x9.59 is now available at the ANSI X9 online publication store:


GAO: Government faces obstacles in PKI security adoption

From: Lynn Wheeler
Date: 03/10/2001 08:22 PM
To: ansi-epay@xxxxxxxx, digsig@xxxxxxxx
Subject: GAO: Government faces obstacles in PKI security adoption

GAO: Government faces obstacles in PKI security adoption

(March 05, 2001) The federal government needs to overcome several obstacles before it can implement the public-key infrastructure (PKI) technology needed to deliver electronic government services effectively and securely, according to a report released last week by the U.S. General Accounting Office (GAO).

Though these obstacles can be surmounted, doing so will require a lot of coordination among the different agencies, the report said. And that isn't a near-term prospect.

Key challenges cited in the GAO-01-277 report include the following:

Meshing incompatible PKI technologies across the different agencies.

Ensuring that PKI implementations can support a large number of users.

Reducing the cost of building PKI systems.

Setting policies that maintain trust levels among different government agencies.

A PKI comprises hardware, software and services that enable the secure and private exchange of data and transactions over the Internet. The GAO report, which was commissioned by Rep. Stephen Horn (R-Calif.), details efforts by the federal government to implement PKI technologies for use in its electronic initiatives.

Though a growing number of vendors today offer PKI products and services, there are no common or widely accepted standards for PKI technologies. As a result, there is little compatibility between PKI products from different vendors.

Therefore, "standards are necessary -- but not sufficient -- to guarantee interoperability," said Derek E. Brink, who heads the customer advisory council for one PKI vendor, RSA Security Inc. in Bedford, Mass. Brink is also chairman of the PKI Forum, an industry group of vendors and users advocating the use of PKI as an enabler of online business.

"[Interoperability] needs to be described and understood in terms of component-level, application-level and interdomain interoperability," he said. The only way to address the issue is by profiling standards and conducting multivendor interoperability testing, he said.

Developing a governmentwide PKI network will require systems that work seamlessly with each other across agencies, the GAO report noted.

Also, "since full-featured PKI's are rare, and those that exist are in the early stages of implementation, it is not yet known how well this technology will truly scale," the report said.

The high cost of implementing PKI could also be a deterrent for many agencies, the report cautioned.

Any effective governmentwide PKI implementation program would require well-defined policies and procedures for installing and monitoring the security of each agency's system on an ongoing basis.

The Office of Management and Budget, which has statutory responsibility to develop and oversee policies relating to the security of federal information, should provide agencies with direction for implementing PKI, the GAO report recommended. The policy guidance should relate to the use of PKI and to ensuring that agency PKI implementations meet consistent levels of security, the report added.

GAO: Government faces obstacles in PKI security adoption

From: Lynn Wheeler
Date: 03/12/2001 11:16 AM
To: ansi-epay@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
as an aside, i was a panelist on a PKI session at NISSC 21

one of the other panelist (last to speak) commented that they were responsible for the operation of the largest and longest running (CADS-model) PKI.

one of the panelist that spoke first made some comment about all the stuff you've heard about how hard PKIs really are ... they really aren't

this last panelist opened with something like, all the stuff you've heard about how hard PKIs really are ... they really aren't; they are much, much worse.

random refs:

GAO: Government faces obstacles in PKI security adoption

From: Lynn Wheeler
Date: 03/12/2001 01:32 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: ansi-epay@xxxxxxxx, digsig@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
part of this was when I was working on the original payment gateway:


using a precursor to SSL3 ... I quickly realized that while the two parties had to do mutual authentication ... the certificates that passed during protocol negotiations were redundant and superfluous. The merchant had an "account entry" that gave the authentication information for the merchant processor that it did business with ... and the merchant processor had real-time "account record" for each merchant. The certificates were just an artificial artifact of the underlying code that was being used and other than that didn't contribute at all to the process.


"Anders Rundgren" on 03/12/2001 11:13:09 AM wrote:
By doing that the "PKI-interface" between organizations will be limited to a server-based organization certficate ("digital company paper") which scales several orders of magnitude better than the X500 approach. PKI has AFAIK, commercially and technically failed for global use except for Web-server-certificates which speaks for itself.

There is only one weakness: This is extremely politically incorrect as the general belief is that PKI must follow the original model...

GAO: Government faces obstacles in PKI security adoption

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/12/2001 08:02 PM
To: ansi-epay@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
original (certificate) design point was many-to-many in an offline environm4ent.... i.e. offline email. the analogy would be letters of credit in the days of sailing ships or the business checks with "signing" .limit. It would have also made sense if the credit card industry had gone from offline paper (all of those paper CRL booklets in the 60s) to offline electronic; however the credit card industry jumped from offline paper to online electronic and bypassed the need for TTP offline electronic credential.

The "signing" limit checks found that with a $5000 limit ... people could still sign 200 $5000 checks to make a $1m transaction .... this pretty much jumped from offline paper to online electronic also. Many times the "signing" limit check is now a business card (a special kind of credit card) that has a lot more rules than just maximum credit limit; things like transaction limit at different stores, different limits on which vendors or even which stores ... also rules about SKU codes (i.e. what kind of things that can be purchased, etc).

The many-to-many scenerio for certificates is the offline electronic .... i.e. the original design point for offline email.

It can even be shown that the existing sort-of many-to-many scenerio ... i.e. SSL merchant domain name certificates (SSL merchant domain name certificates probably represent 99.999999% of the certificates server authentication events in the world today) is something of an aberration that become redundant and superfluous with some simple (necessary) upgrades to DNS. As mentioned in some of the prior (URL) refs, one of the justifications for SSL merchant certificates is concern regarding domain name infrastructure. However, who does a CA go to as the authoritative agency for SSL merchant domain name? ... the domain name infrastructure (the infrastructure that concern about justifies SSL merchant domain name certificates in the first place). Simple proposal to "fix" the domain name infrastructure so that CA's can rely on them when validating requests for SSL merchant domain name certificates is to have merchants register a public key with the domain name infrastructure when they register their domain name. Now if the domain name infrastructure was fixed so that CA's could rely on them for validating information that goes into creating SSL merchant domain name certificates ... then that should alleviate many of the concerns that drive people to get SSL merchant domain name certificates. Furthermore, if a public key distribution is really needed, then a "trusted" domain name infrastructure with registered public keys could distribute them at the same time that they are doing IP name resolution (i.e. an online electronic infrastructure that has to be used in the internet envrionment in any case).

The "fix" to create a trusted domain name infrastructure so that CAs could rely on it as part of the domain name certificate issuing process ... also eliminates the requirement to issue domain name certificates.... as well as providing an trusted online mechanism for distributing public keys (if there is a requirement).

Anders Rundgren on 03/12/2001 02:30:10 PM writes:
In many-2-many situation certificates fill a need. Also, if keys are to be renewed unilateraly certs supports that transparently.

AADS makes sense between a client and his/her bank but not between a client a many RP's.

Client certs between organizations like in SET 1.0 is useless. SET 3D OTOH reduces certs to one per FI which is great.


best ketp secrets of money(?)

From: Lynn Wheeler
Date: 03/16/2001 06:05 PM
To: ansi-epay@xxxxxxxx
Subject: best ketp secrets of money(?)
somebody watching the following show


claims they saw a smartcard with the letters AADS on it.

7th CACR Information Security Workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/19/2001 03:55 PM
To: ansi-epay@xxxxxxxx
Subject: 7th CACR Information Security Workshop
possibly of some interest. I missed talking very much about chips at the intel's developer's conference

random ref:


7th CACR Information Security Workshop
Smart Cards: Technology, Applications and Security
University of Waterloo, Canada

This is the second announcement. Please pass this announcement to any
colleagues who might be interested in attending.  Please note the
March 27 cut off date for hotel accommodations.

For updates, including the program, abstract of talks and speaker
bios, please see www.cacr.math.uwaterloo.ca under "Conferences".

April 25, 2001
9:00 am - 4:00 pm
The Sheraton Reston Hotel, 11810 Sunrise Valley Drive, Reston, Virginia

The 7th CACR Information Security Workshop, titled Smart Cards:
Technology, Applications and Security, will be held on Wednesday,
April 25, 2001 at the Sheraton Reston, Reston, Virginia and hosted by
Certicom Corp.  Topics that will be covered include:

- State of the Industry - who are the players, who are the
customers, what are the applications, what are the issues for
     wide scale deployment
- Latest in smart card technology such as multi application
     operating systems, processors, etc.
- Update on active and passive security attacks such as DPA, fault analysis,
etc and the latest and best means to counter these attacks
- Information Assurance
   - Applications such as financial, transportation, and health care
- Integration of biometrics, encryption and smart cards

With the mobility that we have today with anywhere, anytime access to
myriad applications via the wired and wireless Internet and Intranets,
smart cards provide a perfect form factor for storing individual
user's private information such as digital certificates, public and
private keys, and health care and financial details, and for
processing financial and other transactions.

The series of Information Security Workshops is organized by the
University of Waterloo's CACR (Centre for Applied Cryptographic
Research) (url: www.cacr.math.uwaterloo.ca) and has been established
to provide a highly focused and content full program covering topics
of interest to the sponsors' customers, potential customers and
employees.  The targeted attendee is an individual with a solid
background in information security, with two plus years of experience
in developing or deploying information security solutions for
electronic commerce or other applications. This individual understands
some of the issues and challenges (short term and long term) in this
area and attends the workshop in order to gain exposure to different
approaches (including specific vendor's approaches) or technology and
understand the availability of such, thereby expanding the "tools" in
his or her respective tool box.

This workshop is the 7th in the series. Agendas and presentations from
previous workshops can be found at www.cacr.math.uwaterloo.ca under

- Certicom Corp.
   - MasterCard International
- Mondex International Limited
- Pitney Bowes

- Alfred Menezes
Centre for Applied Cryptographic Research (CACR)
University of Waterloo
   - Sherry Shannon
Centre for Applied Cryptographic Research (CACR)
     and SVI Consulting Ltd.
- Chris Fader
University of Waterloo and SVI Consulting Ltd.


April 25, 2001  (Wednesday)

8:30 -  9:00 Registration/Continental Breakfast
9:00 -  9:10 Welcome Certicom Corp. and CACR

9:10 - 10:40 Smart Card Industry Overview
Panel - State of the Smart Card Industry,
Moderated by Steve Howard, Certicom,
Panelist include Charles Cagliostro, Executive Director,
              Smart Card Digital Security Initiative of the Smart Card Alliance;
John Moore, GSA, Chair, Federal Smart Card User Group;
              and others to be confirmed.

10:40 - 11:00 Coffee Break

11:00 - 12:00 Multi-Application Vulnerabilities and Security Update
11:00 - 11:30 The Vulnerabilities of Multi-Application Systems,
11:30 - 12:00 Electromagnetic attacks on smart cards,
Jean-Marc Robert, Gemplus

12:00 -  1:30 Buffet lunch provided at the 57th Street Grill, Sheraton Reston

  1:30 -- 2:30 Hardware Advances
1:30 - 2:00 Nimbus: An Atmel and ARM collaboration,
Julie Krueger, Atmel
2:00 - 2:30 TBD

2:30 - 2:50 Coffee Break

2:50 - 3:50 Information Assurance
2:50 - 3:20  Title to be determined,
Steve Haynes, PriceWaterhouseCoopers
              3:20 - 3:50  Title to be determined,
Perry Luzwick, Logicon

3:50 -  4:00 Wrap Up CACR


There is no registration fee for guests invited by the sponsors
(Certicom, MasterCard, MITACS, Mondex, and Pitney Bowes).
The registration fee for other participants is as follows:
- CAD $400 (USD $200).
   - For participants affiliated with an academic institution:
CAD $100 (USD $50).
Please register as soon as possible as space is limited for this
workshop; registration is on a first-come first-serve basis.

To register, complete, in full, the attached REGISTRATION FORM and
return it along with your payment (if applicable) to:
Mrs. Frances Hannigan,
    C&O Dept.,
University of Waterloo,
Waterloo, Ontario, Canada N2L 3G1.
You may also register by email (fhannigan@xxxxxxxx)
or by phone (Frances Hannigan: 519-888-4027).

------------------------cut from here---------------------------------

Full name:







E-Mail Address:

Telephone #:

Make Cheque/Money Order Payable in
     CAD or USD funds only to: CACR

Credit Card Payments:

[  ] Visa                  [  ] MasterCard

     Cardholder's Name: _________________________________________________

     Card Number: _______________________________________________________

Expiration Date: ___________________________________________________

     Signature: _________________________________________________________

-------------------------cut from here-------------------------------


The workshop will be held at The Sheraton Reston Hotel, 11810 Sunrise
Valley Drive, Reston, Virginia

A block of hotel rooms (under the name CACR)  has  been set aside for
Tuesday, April 24 at the Sheraton Reston at the rate of $229.00 US
plus tax.  Please make your reservations directly with the hotel by
calling (703) 620 9000 or 1 800 392-7666 prior to the cutoff date of
March 27, 2001.  All reservations must be guaranteed and accompanied
by a first night room deposit or guaranteed with a major credit card.
Individual cancellations not made by 6:00 pm the day prior to arrival
will result in a charge of one night's room and tax to the guest's
credit card.  No-shows will be charged.

Transportation is provided to and from the Dulles Airport.  Please
use the hotel telephone in the baggage claim area to call the
Sheraton Reston.  The Sheraton Reston courtesy bus picks up every
half an hour at the designated place.  Please note that there are two
Sheraton hotels near the airport and each hotel operates its own
courtesy bus.  Please make sure that you board the correct bus.

The closest airport is Dulles Washington DC Airport
For further information please contact:
Mrs. Frances Hannigan
Department of Combinatorics & Optimization
University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
e-mail: fhannigan@xxxxxxxx
Fax: (519) 725-5441
Phone: (519) 888-4027

http://www.cacr.math.uwaterloo.ca/ ----------------------------------------------------------------------- Frances Hannigan Editorial Assistant/CACR Administrative Assistant Dept. of Combinatorics & Optimization Faculty of Mathematics University of Waterloo Waterloo, Ontario N2L 3G1 Ph: (519) 888-4027, MC 5027 Fax: (519) 725-5441 Email: fhanniga@xxxxxxxx Web-site: www.cacr.math.uwaterloo.ca

7th CACR Information Security Workshop

From: Lynn Wheeler
Date: 03/22/2001 10:30
To: ansi-epay@xxxxxxxx
Subject: re: 7th CACR Information Security Workshop
oops ...

> http://www.garlic.com/~lynn/aadsm5.htm#asrn1
> http://www.garlic.com/~lynn/aadsm5.htm#asrn4

that should have been



assurance, X9.59, etc

From: Lynn Wheeler
Date: 03/22/2001 05:10 PM
To: dcsb@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: assurance, X9.59, etc
with respect to


and the SRI contention that software assurance could learn a lot from hardware design ....

the logic simulator machine mentioned in


was called the LSM or los gatos state machine and was used for validating chip designs.

This was one of the original such hardware verification engines for chip designs and had some unique features like a timer. Many of the subsequent hardware verification engines (as well as software verification tools) assumed a synchronous chip and so when things stepped ... every thing stepped in unison (and therefor didn't need to implement a timer function in the tool)

The LSM timer was useful for verifying chips that incorporated analog circuits in a digital chip and/or digital chips that didn't have a single uniform synchronous clock. Note that the Los Gatos VLSI lab (where the LSM was developed) was associated with the San Jose disk engineering plant ... where thin film heads were developed (i.e. digital chip with analog circuits).

also in the above, specifically with respect to the high speed backbone (secure, high-speed network)


Lynn.Wheeler@xxxxxxxx on 02/28/2001 10:24:23 AM wrote:
sri speaker said that current level of assurance technology was very primitive ... that the chip industry has much more sophisticated tools for testing for correctness and test coverage and that software could learn a lot from chip design industry

Digital Signatures Spark Debate

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/14/2001 02:42 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: t.c.jones@xxxxxxxx, epay <ansi-epay@xxxxxxxx>
Subject:Re: Digital Signatures Spark Debate
note that banks have migrated to relying-party-only certificates ... for both liability as well as privacy reasons (a generalized "identity" certificate can represent a significant amount of unnecessary and/or unwanted privacy information for the majority of transactions ... especially in the consumer arena).

as a result there has been some amount of personal digital signatures without reguiring any identity information to be divulged, i.e. privacy invasive identity certificates welded to the end of every transaction).

that was part of X9.59 financial standard (i.e. the work product of this X9A10 working group .... which this mailing list was set up as part of X9A10 ) to be privacy neutral ... and not mandate privacy invasive identity certificates welded on the end of every transaction).



some related discussion recently in comp.security.unix


misc other




a good friend introduced the concept of VPN at the router committee meeting during the fall '94 IETF meeting in San Jose. We had been familiar with his work prior to that event.

Up until that time, IPSEC was going to be end-to-end network layer security (authentication and privacy). Eventually things got re-organized into heavy-weight end-to-end IPSEC and subnet-to-subnet light-weight (aka VPN) IPSEC.

Since that time, it has also evolved into personal VPNs (i.e. end-node PC client talking through the internet to a real router/gateway VPN, likely at some gateway between the internet and the corporate intranet). as an aside, our friend also was one of the first to introduce the idea of personal VPNs. These personal VPNs can provide PC-to-subnet authentication and privacy.

One of the downsides that some of the personal VPNs overlook is the use of the PC as a backdoor into the corporate intranet. For a long time there has been a real serious battle in corporation with PCs attached to the corporate intranet and also allowed to have a dial-up modem (frequently used by the employee to access their private internet account). Those PCs have represented a clear-channel backdoor between the dial-up intranet connection and the corporate intranet.

However, by definition, personal VPNs represent the same exact threat. They have a clear-channel into the internet which allows generalized traffic to flow back in forth. In addition, the VPN can create an encrypted tunnel through the internet into the corporate intranet. An employee's home PC with a modem dialed up to the internet is directly the same as his office PC being allowed to have a modem dialed to the internet. At the TCP/IP protocol stack, the PC sees effectively no protocol difference between a office PC also directly attached to a corporate LAN/intranet and a personal VPN software creating a virtual connection to the corporate LAN/intranet. The same backdoor and viruses work in both cases.


it is possible to select the "term" index and then select IPSEC and/or VPN for the IETF RFCs related to the two subjects.
IP security protocol (ipsec)
     see also security
2983 2888 2857 2709 2628 2451 2411 2410 2409 2407 2406 2405
2404 2403 2402 2401 2367 2207 2202 1829 1828 1827 1826 1825

virtual private network (VPN)
see also encapsulate , security
     2917 2857 2764 2735 2685 2547 2451 2406 2405 2404 2403 2340
1851 1829 1827

Anders Rundgren on 05/14/2001 11:59:38 AM writes:
Interesting article,

May I add another even larger piece on the table? Digital signatures comes in different flavors, one which is personal and one which is machine-generated (server).

In Europe the general belief is that personal signatures is the important one.

I disagree as noted in the article the health-care industry rely on EDI through VPN or leased lines. Over the Internet you can achive the same security by using server-signed EDI (or other) messages. This is techically and deployment-wise very simple.

A major drawback with personal signatures is that people's identities come to places they have no control of. And the globally interoperable employee - CA does not even seem to be an issue in the private sector.

So my bet is that "healthy" path for the health-industry is to start with organisation/server signatures before going too fast on the personal signature path. In Europe this will surely be based on mobile phones rather than smart cards etc.

Anders Rundgren

Announce: Eric Hughes giving Stanford EE380 talk this

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/14/2001 04:34 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx,
ansi-epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
Having been involved somewhat in the first round of electronic commerce i.e. my wife and I worked with a small client/server started in the valley on getting the server to point that they could do financial transactions. The small startup went on to change its name from Mosaic to Netscape

random ref:



we didn't find doing it the first time as so hard ... it was getting the next round to displace the first round.

We both worked on financial industry's X9.59 standard for all electronic account-based payments (POS, internet, etc).

One of its characteristics was that it introduced the business concept of authenticated transactions and authenticated transactions account numbers (i.e. account numbers that can only be used in authenticated transactions). One of the side-effects of this was that it eliminates account numbers as shared-secrets (i.e. the requirement that merchants & others keep the master account-number database at the very most highest security and absolutely never make a mistake in order to prevent the harvesting of account numbers that can be used in unauthenticated fraudulant transactions).

I was one of the speakers at the NASA/CMU dependable computing workshop last week and besides talking about several long known issues ... also talked about authentication as a component of dependability (as well as x9.59 for dependable financial transactions ... transition eliminating account numbers as a shared-secret vulnerability).

random refs:




"R. A. Hettinga" on 05/14/2001 02:45:04 PM writes:
To: cypherpunks@xxxxxxxx
Subject: CDR: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
From: Eric Hughes (yes, _that_ EH) <eh@xxxxxxxx>
Date: Mon, 14 May 2001 09:26:52 -0700

In discussions at the Bay Area cypherpunks meeting last Saturday, I was repeatedly asked to forward an announcement. I will be giving the Stanford EE380 colloquium talk this Wednesday, May 16, 2001. The course URL is thus:


The title of the talk is "Design for Commercial Reliance". The theme is a particular reason why innovation in commercial transaction systems is difficult. With the recent sale of the remaining assets of Cybercash to First Data Merchant Services and VeriSign, the initial wave of digital cash businesses is now fully over. The score was 0/3 (Cybercash, First Virtual, DigiCash).

I believe it is instructive to see that the predominant payment system used over the internet (internet payment order initiation) is the credit card system for consumer and the ACH (checks) system for businesses. The internet has been applied to the delivery channel, but the underlying financial mechanisms remain identical. These internet use of these systems has been deeply conservative. Even the only even moderately-successful "alternate" system, Paypal, still uses no new transfer mechanism.

New payment systems are an awful business. They're low margin (they have to be, to meet the competition), so they have to be high volume to succeed. Getting to high volume has lousy financial properties. The "bathtub curve" is long and deeper than you'd like. You have to finance not only the NRE (non-recoverable engineering) costs, including data center build-out, but also a few years of operating costs before you hit volume. Let's just assume you've got the financing in place and also realistically patient financiers who are not dupes. You have five years to break-even from launch, say.

Now you have to do everything possible to ensure that your system has rapid uptake. It has been proven by demonstration at this point (see scoreboard above) that press coverage and cheerleading are insufficient. It doesn't matter how much "RAH! RAH! Go Team!" there is. Wishing doesn't make it so.

Certainly you need brand. Without being able to quickly communicate what the service is about, you won't get rapid uptake, even in the business market. So let's assume your financiers have stumped up for advertising and other brand-building activities. You'll also need differentiation, because otherwise why not just use a check or credit card? Let's assume that, too. (The first wave of internet companies had adequate brand and differentiation.)

My claim is that you're still not done. I'll be talking about a basic design failure that would kill uptake or slow it sufficiently that any new venture would still fail, even having done most everything else right.


Announce: Eric Hughes giving Stanford EE380 talk this

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/15/2001 11:13 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>,
    Digital Bearer Settlement List <dbs@xxxxxxxx>,
dcsb@xxxxxxxx, ansi-epay@xxxxxxxx,
Subject: Re: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
... slightly different slant on "commercial transaction systems" .... slightly more related to industrial strength data processing in transaction systems (although the first ref in following list is specifically with respect to one of the large financial transaction systems).

random ref:






"R. A. Hettinga" on 05/14/2001 02:45:04 PM writes:
The title of the talk is "Design for Commercial Reliance". The theme is a particular reason why innovation in commercial transaction systems is difficult. With the recent sale of the remaining assets of Cybercash to First Data Merchant Services and VeriSign, the initial wave of digital cash businesses is now fully over. The score was 0/3 (Cybercash, First Virtual, DigiCash).

do CRL's actually work?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2001 12:45 PM
To: t.c.jones@xxxxxxxx
cc: ansi-epay@xxxxxxxx
Subject: Re: do CRL's actually work?
note that certificates were originally targeted for offline environment (i.e. not being able to reference the information ... as in the case for DNS IP-address real-time lookup) ... specifically offline email.

originally CRLs were targeted at being broadcast to the relying-party clients to provide more timely information as to certificate status (nominal case, offline email distributed to the set of relying-parties for offline email authentication). as the size of some of the relying-party communities started to get very large it became less and less practical to broadcast CRLs to everybody in a community (recent discussion of broadcasting to possibly 100 million SSL clients in the world that might be relying-party for SSL domain name server certifices).

The alternative to broadcast/push for CRL became a online query/pull model. So for business critical certificates where timely status is important ... but a paradigm targeted for the offline environment then needed to layer an online query paradigm on-top of the infrastructure targeted at working in an offline environment .... aka the certificates represent a R/O, distributed (possibly stale) copy of the informaton contained in a (account) database record at the certification authority. These R/O, distributed copies of database records at the certification authority provide access to certified information when the relying-party is in an offline environment and has no access to the certification authority information.

Layering an online protocol (CRL and/or certificate real-time information access) on-top of the certificate offline paradigm basically negates original assumptions and design point that went into the reasons that certificates were invented in the first play.

Given an "online" design point/requirement ... then authentication information (like public keys) can be distributed by a trusted party in much the same way that the domain name infrastructure distributes IP-addresses, i.e. rather than trying to contort an offline authentication solution into addressing online authentication requirements (by layering online, timely information access on top of stale, offline information copy paradigm); just use an online authentication solution for addressing online authentication requirements.

The comparison is especially apparent in the SSL domain name server certificate scenerios. The domain name infrastructure already provides for timely, query/pull model distribution of IP-addresses. The domain name infrastructure is also the final authoratative agency as to who owns a domain name. Nominally, for a certification authority to issue an SSL domain name server certificate, the certification authority has to verify with the domain name infrastructure that the entity requesting the domain name certificate is in fact the entity that owns the domain; aka in general, a certificate authority has to resort to checking with the authoritative agency associated with the information that the certification authority is "certifying" (in the case of SSL domain name server certificates, the domain name infrastructure is the authoratative agency as to the owners of domain names).

The domain name infrastructure shows that timely, query/pull information distribution can be operated on a large scale. In fact, something akin to the domain name infrastructure implementation could be used to deploy support for scalable CRL operation. However, that is placing an online "fix-up" layer on top of a fundamental offline information distribution solution. For an online environment, it is also possible to show that the domain name infrastructure implementation could be used to address not only the CRL issue but also the certificate stale, static information issue (rather than needing to make availabe timely status information about offline stale, static information, just make available the timely information directly).

random ref:


t.c.jones@xxxxxxxx on 05/16/2001 09:55:40 AM wrote:
read this


Electronic Commerce Modeling Language

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2001 03:06 PM
To: ansi-epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language
Of possibly some interest to X9A and/or TC68

This is going forward as an IETF Informational RFC ... fyi
A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

     Title          : Electronic Commerce Modeling Language (ECML):
Version 2 Requirements
     Author(s)      : J. Parsons, D. Shepherd, D. Eastlake
Filename       : draft-ietf-trade-ecml2-req-02.txt
Pages          : 10
Date           : 08-May-01
This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to XML syntax, data model, format, payment processing, and external requirements.

A URL for this Internet-Draft is:


Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
"get draft-ietf-trade-ecml2-req-02.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html or

AADS NWI closed two years ago today

From: Lynn Wheeler
Date: 05/20/2001 01:30:54 PM
To: ansi-epay@xxxxxxxx
Subject: AADS NWI closed two years ago today
random ref:


latest credit scam puts plastic in peril ... is your credit card being cloned?

From: Lynn Wheeler
Date: 05/21/2001 09:16:40 PM
To: ansi-epay@xxxxxxxx
Subject: latest credit scam puts plastic in peril ... is your credit card being cloned?


use of digital signatures and PKI

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/04/2001 08:36
To: ansi-epay@xxxxxxxx
Subject: use of digital signatures and PKI
note this is similar to the "merchant comfort certificates" that ran here last year




Gcza Zoltn on Thu, 31 May 2001 19:18:30 wrote:

I have just read Jane K. Winn's paper, "The Emperor's New Clothes: The Shocking Truth About Digital Signatures and Internet Commerce".

As far as I can remember, it was mentioned on the list.

I wonder if you could make any comments whether digital signatures are really NOT used worldwide as the paper states! Unfortunately I could not find any research or survey. Any reference would be greatly appreciated

Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi

From: Lynn Wheeler
Date: 06/04/2001 08:25 AM
To: ansi-epay@xxxxxxxx
Subject: Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi
"Carl Ellison" on 31 May 2001 07:56:24 wrote:
One of the problems we face with the lingering demise of X.509 PKI is that the three letter acronym "PKI" is being given a very bad name. I had one product consultant tell me a few months ago that we should never include those letters in anything we're trying to sell from now on.

Since SPKI has those three letters in its name, we may need a new name....

At Intel, we're calling it "relationship management".

That's big and English, not an acronym. Suggestions anyone?

- Carl

use of digital signatures and PKI

From: Lynn Wheeler
Date: 06/06/2001 10:43 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: goczaz@xxxxxxxx, Anders Ekström <anders.ekstrom@xxxxxxxx>,
ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI
actually ... it isn't just a case of trust anchors .... which is much more of a technical concept; part of the issue is the whole idea of the business of depending on very obscure trust relationships provided by other parties ... including, potentially trust values that are totally orthongonal to a relying party's trust requirements

the other issue is that certificate design point is really a piece of R/O copy of distributed information along with some integrity characteristics that was originally targeted for an offline environment (i.e. where the relying party didn't have online access to the original source of the information). It isn't that certs couldn't do what they were originally targeted for doing ... but many of the value propositions for certs that have been attempted over the past couple years involved environments that basically voilated all their original design assumptions.

the SSL server PKI infrastructure is a reasonably good example (even tho the infrastructure is primarily used for encryption not authentication) ...

random ref:

Anders Rundgren on 06/04/2001 08:41:33 AM wrote:
Hi Gcza,

I think that the article is correct in the sense that digital signatures are currently not widely deployed. That this is due to impossible-to-accept deficiencies in the underlying idea and technology is (in my opinion) not the case, it is rather the overly complicated trust models that particularly the governments try to apply to PKI. I.e

use of digital signatures and PKI (addenda)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/06/2001 10:43 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: goczaz@xxxxxxxx, Anders Ekström <anders.ekstrom@xxxxxxxx>,
    ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI (addenda)
... trust should effectively be the same regardless of the technology that is used to deliver that trust.

that is a certification authority that validates/certifies some information .... in theory the level/value of the trust should be the same whether a relying parties directly does an online query to the certification authority ... or relies on a R/O distributed (potentially stale) copy of that some information (embodied in a certificate) that a relying party can depend upon when there is no online access to the same information.

so doing the SSL server certificate scenerio ... in the online "trust" model.

we have a small technology startup someplace with an online database that is effectively copied/validated with the domain name infrastructure. an end user does an online query with the domain name infrastructure and then does a 2nd online query to the SSL certification authority to see if the direct response that the user received from the domain name infrastructure is the same as the online query response from the certification authority (i.e. is the domain name infrastructure online response the same as the SSL certification authority online response ...based on the SSL certification authorities copy of the domain name infrastructure database). That is the same basic "trust" ... but in terms of an online implementation that is done today using stale, static copies (aka certificates) of the certification authorities database (which is basically a copy of the domain name authorities database).

... another relatively recent certificate-based incarnation example ... we have a small technology startup someplace with an online database that is a copy of a bank's account database. the bank receives an online transaction ... does it

1) validate using the stale, static copy of information (aka certificate) from the technology startup which in turn is based on a stale, static copy of the bank's account database?

2) validate by doing an online query to the technology startup checking the technology startup's database (which is a stale, static copy of the bank's online database?

3) validate directly using the banks real-time online database?

The issue of trust and certification should "work" totally independantly of whether the technology to deploy that trust is an online query to a real-time database ... or via offline dependance on an offline stale, static copy (aka certificate) of the same information (modulo potentially how stale the R/O copy might become).

The issue of whether an online or offline implementation is deployed ... and/or whether an online or offline solution is used ... should be based on the target environment ... not based on the trust (aka the trust scenerio should work effectively the same regardless of whether it is offline ... with online queries ... or offline ... with R/O stale certificates).

If it makes sense for a bank to depend on a 3rd party's certificate representing information already in the banks database ... then it should make equal sense for a bank to do online queries to that 3rd party's online copy of the bank's database ... rather than doing the online query against the banks own original database (the difference isn't an issue of trust the difference is whether the bank is operating in an offline or an online environemnt).

Entrust To Cut 400 Jobs .... fyi

From: Lynn Wheeler
Date: 06/06/2001 10:44 AM
To: ansi-epay@xxxxxxxx
Subject: Entrust To Cut 400 Jobs .... fyi


Entrust, a struggling Internet- security company, said yesterday that it would cut 400 jobs - 30 percent of its work force - and close some offices. The company said it would take a $400 million charge in the second quarter to cover the costs of severance packages, office closings and other items. The company, based in Plano, Tex., also changed its name, which had been Entrust Technologies. Entrust was spun off from Nortel Networks in 1997.

problem with the death of X.509 PKI (forwarded)

From: Lynn Wheeler
Date: 06/06/2001 10:44 AM
To: ansi-epay@xxxxxxxx
Subject: Re: problem with the death of X.509 PKI (forwarded)
the other trust scenerio ... continuing posting on the digital signature thread ...

Maintaining the trust constant but comparing the migration from offline to online ... is bank issued credit cards in the '50s/'60s where the credit cards were offline "credentials/certificates" that had names and numbers. The plastic was supposedly hard to counterfiet and contained "name" so that merchant could cross-check with other forms of identification (see if name is the same on a driver's license). They could also check the account number against the montly paper "revokation list".

A magstrip was added to the plastic form factor ... so it could be used in electronic online transactions (totally skipping over offline electronic ... which is where the current CA/PKI paradigm design point was targeted for). The electronic online transaction not only had the benefit of being able to do real-time revokation checking ... some simple authentication ... as well as real-time credit limit ... as well as multiple transaction patterns (not only aggregation of money but aggregation of number and types of transactions).

use of digital signatures and PKI (addenda)

From: Lynn Wheeler
Date: 06/06/2001 10:45 AM
To: Carl Ellison <cme@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, goczaz@xxxxxxxx,
    Anders Ekström <anders.ekstrom@xxxxxxxx>,
ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI (addenda)
electronic financial transactions are operating online already ... i was being somewhat facetious .... but in the past these online electronic financial transactions have been one of the major targets for offline certificate application.

I was trying to separate/contrast between 3rd party certification (whether the service is online or offline via certificates) and online versis offline certificates (whether it is relying party or 3rd party). In theory, 3rd party certification should be able to be examined independent of the technology/paradigm (i.e. online & offline/certificates) used to deliver the certification ... and online/offline paradigm should be able to be examined independent of relying party & 3rd party certification.

"Carl Ellison" on 06/06/2001 01:48:04 AM wrote:
At 10:20 AM 6/5/01 -0700, Lynn.Wheeler@xxxxxxxx wrote:

>If it makes sense for a bank to depend on a 3rd party's certificate
>representing information already in the banks database ... then it should
>make equal sense for a bank to do online queries to that 3rd party's
>copy of the bank's database ... rather than doing the online query against
>the banks own original database (the difference isn't an issue of trust
>difference is whether the bank is operating in an offline or an online

I thought the beauty of X9.59 was that banks are all operating online already, thanks to EFT and credit card processing, so there's no reason to dilute security by having any third party involved in the authorization process. Did I miss something?

- Carl

use of digital signatures and PKI (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/06/2001 10:32:16 AM
To: Carl Ellison <cme@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, goczaz@xxxxxxxx,
Anders Ekström <anders.ekstrom@xxxxxxxx>, ansi-epay@xxxxxxxx,
Subject: Re: use of digital signatures and PKI (addenda)
there are sort of two kinds of online financial transactions that go on the internet today .... the standard (essentially unauthenticated) credit card fincnail transaction (which turns credit card number into a shared-secret) and "one dollar 'auths'".

standard "moto" (mail order/telephone order) credit card transaction have typically included "address verification" (i.e. check to see if the customer's address the same as the credit card billing address).

several elements (including some certification authorities) in the internet today are taking advantage of online AVS transactions to do a form of online authentication. One form is a one dollar credit card authorization with AVS (i.e. verify correct credit card number, name, & address) ... but never do an actual funds transfer (i.e. the one dollar auth never actually shows up on the credit card bill). They then make the assumption that since all that information is correct ... they are dealing with a valid credit card customer that signed a valid contract (and in some circumstances since to sign a valid contract you have to be an adult ... they then make the conclusion that the person is also an adult).

The merchant is charged additonal for an AVS transaction ... so this takes a form of online authentication plus being charged per authentication event. However, most internet operations that take advantage of this AVS transaction feature ... are then recording the information and relying on the recording (and not repeating the transaction) for future use. In some cases, the "merchant" then turns around and provides an "online transaction" authentication mechanism for other entities on the internet (i.e. they charge other internet entities a fee for online access the "AVS transaction" information that they have cached; these entities caching AVS transaction information seemed to be totally unrelated to the financial institutions that provide the basic AVS support).

The Certification Authorities that are using the AVS feature ... are frequently doing it as part of a credit card charge. They may be charging a user $10 or more (on their credit card) for manufacturing a certificate using the information "authenticated" by the AVS transaction aka ... a $10 or greater fee to a user for munging the bits that the user provides into ASN.1 encoding ... after including the AVS information with the $10 charge against the user's credit card. That provides a user with an AVS authenticated certificate information in a CA manufactured certificate ... that supposedly they could present to some other party ... and the other party will possibly put more reliance on the certificate version of the AVS information than in the AVS transaction itself.

There is a similar but different scenerio for SSL domain name server certificates


"out of control credit card fraud"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/11/2001 8:54:59 AM
To: ansi-epay@xxxxxxxx
Subject: "out of control credit card fraud"

Hypercom Launches Attack on Credit Card Skimming; Hypercom Chairman and Chief Strategist Calls for Industry To Combat New Dangerous Form of Skimming

June 8, 2001

PHOENIX--(BUSINESS WIRE)--June 7, 2001 via NewsEdge Corporation -

(Hypercom Corporation)(NYSE:HYC) -- Credit card "skimming" is an alarmingly escalating form of fraud that is victimizing consumers, causing havoc with merchants, and costing the industry hundreds of millions of dollars every year. Skimming fraud takes many forms, but most often involves a cardholder turning over physical possession of his or her card to a retail or restaurant employee, who then swipes the card through a small, illegal card reader, called a "skimmer." The skimmer copies the data encoded on the card's magnetic stripe. This information is then used to manufacture counterfeit cards that are used to rack up illegal charges. Industry sources estimate that the average skimmed credit card will generate some $2,000 in fraudulent charges before being detected.

"out of control credit card fraud"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/11/2001 11:33:41 AM
To: ansi-epay@xxxxxxxx
Subject: Re: "out of control credit card fraud"
full text at:


call for new measures: ICH would be glad to help

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/18/2001 07:59:16 AM
To: "Fred Blommestein, van" <f.van.blommestein@xxxxxxxx>
cc: John@xxxxxxxx, ddjong@xxxxxxxx, fsollish@xxxxxxxx,
kevin@xxxxxxxx, dirk.dougherty@xxxxxxxx,
set-discuss@xxxxxxxx, obi-requirements@xxxxxxxx,
    kaustin@xxxxxxxx.au, Graydon.Smith@xxxxxxxx,
adam.sharp@xxxxxxxx, nick.lewins@xxxxxxxx,
    anders.rundgren@xxxxxxxx, Fulton.Wilcox@xxxxxxxx,
Subject: RE: call for new measures: ICH would be glad to help
how about X9A10 group ... it has gotten the X9.59 standard out and on its way to ISO (financial standards group electronic payment for all account-based (non-wholesale, like fedwire, swift, etc) payments.

it somewhat grow out of our work with a small client/server startup called mosaic in the 94/95 era

nacha has completed its pilot and various networks are looking at production deployments

random ref:


"Fred Blommestein, van" on 06/17/2001 09:52:22 PM wrote:
Hi John,

Initiatives that you certainly should include are:
Rosettanet (adam.sharp@xxxxxxxx)
BMEcat/Opentrans Germany (Oliver.Kelkar@xxxxxxxx)
EP-NL Netherlands (patricia.grijpma@xxxxxxxx)

Fred van Blommestein
Berenschot / EP-NL

<<< "John Weiler" 6/17 2:07p >>> Anders et al,

I would like to propose should convene a meeting between multiple e-commerce standards and user groups to discuss how we can further our common goals.

Those that I believe would be interested are;
- Oasis (ebXML)
- OMG (new model driven architecture methods)
- Open Applications Group (defining application integration specs)
- IEEE 1471 (architecture specification nomenclature)
- UDDI (web based component directory based on SOAP and XML)
- Distributed Management Task Force (looking at low level interop. issues)
- Interop. Clearinghouse (defining validation methods) and
- OBI/CommerceNet (core standards for e-commerce transactions)

As these combined organizations together define the key elements for internet computing, we should be able to establish common mechanisms for addressing how we can help bridge the gap between the promise of standards and implementation reality. The ICH has established liaison relationship with most of these organizations, and would be glad to host a meeting this summer in Washington DC.

Let me know if there is interest in collaborating with other standards groups in the IT value chain of e-commerce.


-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@xxxxxxxx]
Sent: Friday, June 15, 2001 9:41 AM
To: Wilcox,Fulton; Fred Sollish; Kevin Kienast; Fred Blommestein, van; dirk.dougherty; obi-requirements@xxxxxxxx; John@xxxxxxxx; Dick de Jong; SET-List
Cc: kaustin@xxxxxxxx.au; Nick Lewins; Graydon.Smith@xxxxxxxx
Subject: Putting OBI 4.0 on the market may call for new measures

This message is directed to all involved in OBI and e-commerce standards in general.

I have been closely following several [largely unsuccessful], efforts to standardize new and unproved technology. A thing that few of the involved parties understood, was that developing code for technically complex and marketwise unproved systems involves huge risks and is therefore not as attractive as one could think. And if they already have something running the motivation to change is likely to be limited even if the new thing offers very compelling advantages. Then there is the problem that there usually is more than one competing standard.

When things get as complex as for OBI, there is also the problem that there may not be too many that are up to the task at all. OBI 3.0 requires understanding of what most young developers would call "yucky" EDI which definitely is a limiting factor, while OBI 4.0 relies on standard but still hard-to-use cryptographic functions that few e-commerce developers so far have had any reason to bother with. XML schema parsers which also is a corner-stone of OBI 4.0 are still non-standard, in spite of being a hot topic for several years. I.e. we are in a transitional period where the OS manufacturers still have some major homework to do in supporting e-commerce.


Due to the previous roadblocks to success, one should seriously consider making key-components available for free, to not stall market acceptance. How could you make any money on that someone probably rightfully wonders?

The free components could have soft [test/verification license] or hard [cripple-ware] usage restrictions. The latter is not a good idea in my opinion when a market is still in a "cautious" state

The major sources of revenues are probably not in components, but in packaged products, system integration services, and in running ASPs [which OBI 4.0 offers vastly improved support for].

Last by not least. If adoption becomes marginal, all parties that invested money, time, and energy will lose most of their investment. I.e. deployment is the really critical factor, regardless if you are a SW vendor, consultant, or actually just want to perform e-business.


Still I think that without public testing/debugging-, compliance-, and proof-of-concept- (tryout) sites you get essentially nowhere. This is in my opinion valid for all non-proprietary application- oriented e-commerce standards, aspiring for market acceptance.

Anders Rundgren
+ 46 70 - 627 74 37

MS masters NC mind-set (authentication is the key)

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2001 07:5s AM
To: ansi-epay@xxxxxxxx, dcsb@xxxxxxxx
Subject: MS masters NC mind-set (authentication is the key)
somewhat with respect to AADS NWI &/or some of the FSTC "FAST" proposals

WAKE UP, open-source community. The battle is not for the desktop; it is not for the server; it is not for the operating system; it is not for the development environment; it is not about the GNU General Public License (GPL) vs. Microsoft's business model. The battle is primarily about who will control user-authentication services.

somewhat related ... the nacha pilot (now complete) & AADS Option for Buyer Authentication



MS masters NC mind-set (authentication is the key)

From: Lynn Wheeler
Date: 06/21/2001 10:54:04 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: ansi-epay@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: MS masters NC mind-set (authentication is the key)
but it is trivial to show that DNS just has trusted operation with real-time key distribution the very same way that it does real-time IP address distribution (no certificates)

it is also trivial to show that for all the transactions that involve account-based financial activity ... that certificates are redundant and superfluous. in effect, certificates are useful for having 3rd parties proove somebodies identity to a relying party when there isn't prior business relationship between the parties ... and when it isn't possible for the relying party to to contact a TTP with an online infrastructure in real time.

The big problem for the real scenerio for a identity certificate in an offline world for individuals ... is first finding an offline world (i.e. instead of just trying to force fit an offline square peg into an online round hole) and second not treading on privacy concerns by spraying identity information all over the world on every transaction.

but otherwise ... it would seem we are in violent agreement with respect to the importance of authentication ... but it should be at least tempered by privacy concerns.

random refs:


"Anders Rundgren" on 06/21/2001 08:31:37 AM wrote:
This is true! Authentication IS the key. For yearly subscription fees as well!

This also makes me a firm believer that in the end [highly controversial stuff here] there will be just two major CAs.

- Microsoft for individuals. What!?!? Passport/Hailstorm V3.0. I have their plan...
- VeriSign/DUNS for organizations. DNS or DUNS as Global ID, no one else can match that.

Open SRC has little to do with this. Lousy competition without visions is
the thing that makes it [according to some too] easy for MSFT to rule.


"Gurard against Identity Theft" (arrived in the post today)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/21/2001 01:25:25 PM
To: ansi-epay@xxxxxxxx
Subject: "Gurard against Identity Theft" (arrived in the post today)
somewhat with regard to identity certificates being anti-thetical to privacy

probably applies to others ... but this showed up in the mail today from Navy Federal
Guard against Identity Theft

Don't give your Social Security Number (SSN) or credit card numbers to anyone over the phone unless you know the caller personally or are confident the organization is legitimate

Cancel unused credit cards

Limit the number of ID and credit cards you carry.

Order only from a secure Web site

Completely destroy copies of credit card receipts, financial statements, etc. before discarding them

Check statements from financial institutions and verify account information. Navy Federal Online, www.navyfcu.org, provides you with an excellent means of reviewing your Navy Federal accounts at your convenience

Never give your Personal Identification Numbers (PINs) to anyone

Report unexplained interruptions in mail service to your local post office

Review you credit report once a year.

If you are a victim of Identity Theft:

Report Identity Theft incidents to the three credit bureaus: Trans-Union (1-800-680-7289); Equifax (1-800-525-6285) and Experian (1-888-397-3742)

Contact Navy Federal or other financial institutions to obtain new account numbers and PINs and have a code word placed on your accounts.

File a police report and obtain a report number for future reference

Report fraudulent use of your SSN by calling the Social Security Administration at 1-800-289-0271

Obtain a new driver's license and number.

x959 Postings and Posting Index,
next, previous - home