Misc AADS & X9.59 Discussions

AADS Postings and Posting Index,
next, previous - home

X9.59 Electronic Payment Standard
Assurance, e-commerce, and some x9.59 ... fyi
Assurance, e-commerce, and some x9.59 ... fyi
Assurance, e-commerce, and some x9.59 ... fyi
Ballot for Withdrawal of X9.15 Posted - X9/01-LB#7-X9A/01-LB#3
assurance, X9.59, etc
implementations of "XML Voucher: Generic Voucher Language" ?
"e-payments" email discussion list is now "Internet-payments"
revised Shocking Truth about Digital Signatures
revised Shocking Truth about Digital Signatures
Encryption article
The Fundamental Inadequacies of Conventional PKI
Lie in X.BlaBla...
use of digital signatures and PKI
PKI: Evolve or Die
problem with the death of X.509 PKI
faith-based security and kinds of trust
Online Certificate Revocation Protocol
Online Certificate Revocation Protocol
Simple PKI
Online Certificate Revocation Protocol
Online Certificate Revocation Protocol
Simple PKI
Simple PKI
Simple PKI
Simple PKI

X9.59 Electronic Payment Standard

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 01/10/2001 09:36 AM
To: DIGSIG@xxxxxxxx
Subject: Re: X9.59 Electronic Payment Standard

ANSI makes money off the standards documents ... i heard that it will be something like $120 for this one.

X9.59 is a definition of the fields in a payment object that can be used in authenticated transactions.

AADS model is a way of doing public key management that optimizes transaction appended certificates. Digital signatures using public key is a way of implementing authenticated transactions.

There is a mapping of X9.59 to ISO8583 (payment cards like debit & credit) at

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

There is some discussion about existing resource requirements for typical ISO8583 transactions (<100 bytes). The example shows EC/DSA authentication (FIPS186, X9.62) for X9.59 and a mappint of X9.59 elements and digital signature into ISO8583 w/o excessively bloating the transaction size.

Part of this recognizes that almost all existing financial PKI-like infrastructures implement essentially "relying-party only" certification (i.e. the financial institution is RA & CA, registering the public key & related certificate). In this scenerio, it is easily shown that for any certificate that might be appended to a digitally signed transaction, all certificate fields currently exist at the relying party financial institution and therefor the appended certificate can be compressed to zero bytes.

An appended certificate compressed to zero bytes significantly reduces some of the issues with transaction size bloat for digitally signed transactions. It also eliminates the possibility of unnecessarily divulging privacy information that might be contained in the uncompressed certificate (i.e. for instance to a merchant in an internet and/or other retail electronic transaction, like the person's name).

For related discussion see

https://web.archive.org/web/20010223082113/http://lists.commerce.net/archives/ansi-epay/200101/msg00002.html

more information at:

https://web.archive.org/web/20010603061158/http://lists.commerce.net/archives/ansi-epay/

Daniel Greenwood on 01/09/2001 09:37:06 PM
Lynn,
Does this use the AADS standard that you have been discussing? Is there a link to this payment standard on the net that you can give us?
Thanks,
- Daniel

=======================
Daniel J. Greenwood, Esq.
dan@xxxxxxxx
www.civics.com
=======================

-----Original Message-----
From: Digital Signature discussion [mailto:DIGSIG@xxxxxxxx]On
Behalf Of Lynn.Wheeler@xxxxxxxx
Sent: Tuesday, January 09, 2001 6:44 PM
To: DIGSIG@xxxxxxxx
Subject: X9.59 Electronic Payment Standard

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).

Assurance, e-commerce, and some x9.59 ... fyi

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 02/28/2001 02:13 PM
To: dcsb@xxxxxxxx
Subject: Assurance, e-commerce, and some x9.59 ... 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)

reference

https://web.archive.org/web/20010801203303/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp%2bs13

Assurance, e-commerce, and some x9.59 ... fyi

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 02/28/2001 02:16 PM
To: Rodney Thayer <rodney@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: Assurance, e-commerce, and some x9.59 ... fyi

in the digital trivia previous posted to dcsb

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

two of the people in the reference meeting:

https://www.garlic.com/~lynn/95.html#13

the following year (after the referenced meeting) my wife and I got a note saying they were leaving their current positions and joining an exciting new startup in the valley and hopefully they would be able to talk to us about it.

the year after that ... my wife and I started doing some work for a financial services company. one of the tasks was working with an exciting new startup company in the valley ... and we run into the same two people and they had responsibility for doing this thing called a commerce server.

this exciting new startup they were working for had come up with these things called HTTPS and SSL (among other things) and wanted to be able to do interactions between clients and servers that involved something called credit card numbers (flowing over these things called HTTPS and SSL that they had come up with). However, one of their issues were once these credit card numbers and the person's name and address got to the commerce server, the commerce server had to do something with them. doing something with these things called credit card numbers was something we were suppose to work with the startup on .... i.e. take this things called credit card numbers and along with the person's name and address and bits and pieces of other information and somehow use them to execute real live financial transactions.

we eventually got it up and running and they eventually started deliverying to customers.

it may be possible that some number of people on DCSB mailing list have heard of it .... although it is frequently now referred to as electronic commerce or e-commerce and there has been quite a bit of mimiking of the original implementation.

random other refs:

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

Rodney Thayer on 02/26/2001 09:54:39 AM wrote:
gee, I'm giving a talk at Apachecon and one at EFCE, but I don't clutter DCSB with gratuitous advertisements. I usally leave that sort of inappropriate self-promotion to Bob Hettinga.

Assurance, e-commerce, and some x9.59 ... fyi

From: Lynn Wheeler
Date: 02/28/2001 02:19 PM
To: Rodney Thayer <rodney@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: Assurance, e-commerce, and some x9.59 ... fyi

oh yes, with this thing called a commerce server .... there was also another thing done called a payment gateway.

in order for the commerce server to do a real live financial transaction, it had to package all the bits of information; credit card number, person's name & address and bits & pieces of other stuff and communicate it to a merchant or acquiring processor. The standard for this communication message in the US is referred to as X9.15 .... which is a kind of subset of an international standard called ISO8583 (although there are a large number of proprietary protocols in the merchant processing business, and the latest 5year update is merging X9.15 as a section of the ISO8583 standard).

Once the financial transaction message is appropriately formated, it then has to be transmitted to the merchant/acquiring processor. The original work on the original commerce server used direct (non-internet) method of transmission. However, for customers/product something called a payment gateway was also invented. The payment gateway allowed a (actually any number of) commerce server to transmit a financial transaction over the internet to the payment gateway and the payment gateway would handle the direct communication with the merchant/acquiring processor. This original payment gateway used a special modified version of SSL implementing something called mutual authentication (this was well before something called SSL3 was concieved) to communicate the formated financial transaction from the commerce server to the payment gateway.

There was some interesting challenges with the payment gateway. Typical merchant call to the merchant/acquiring processor trouble desk is supposedly able to do 1st level problem determination within 5 minutes. The translation from a circuit-based infrastructure (with various implied telco facilities) to a relatively primitive packet-based infrastructure posed some interesting problems. Early testing of payment gateway implementation eventually resulted in the first payment gateway trouble ticket which took 3hrs to come up with NTF (i.e. a call comes into the trouble desk and the trouble desk opens something called a trouble ticket and attempts to identify, isolate,and/or resolve the problem within 5 minutes .... in this particular case, the effort lasted 3hrs and the resolution was NTF or "no trouble found"; i.e. the trouble desk was unable to figure out anything and it took them 3hrs to do it).

This is unacceptable, especially for bigger merchants which are likely to have something called a SLA, or service level agreement for their commerce services (that specify things like service availability and possibly penalty clauses if service objectives aren't met).

As a result, various servicability, diagnostic and recovery techniques had to be invented for both the commerce server and the payment gateway in order to meet minimal commercial expectations.

it is likely that various of these other commerce features have also since been mimicked by subsequent electronic commerce implementations.

part of the assurance for the original commerce server and payment gateway was a failure mode grid that consisted of something like 5 states and 40 failure modes .... the commerce server/payment gateway interaction had to demonstrate that preferrably it could recover from (& mask out) each of the 200 possible cases or at a minimum provide enough diagnostic information to identify and preferrably isolate the failure within five minutes.

now for a tale out of school ... I insisted that the commerce server setup with the payment gateway include multiple-A record support. The first re-action was that it was too advanced ... even when i pulled code examples out of a 4.3 distribution from 1988, ftp client, telnet client, etc. Finally got it into the commerce server ... but it took possibly another year to get multiple-A record support into the browser.

One of the early commerce server customers was a large sport shop. It was common at the time to only have a single ISP connection and many of the ISPs at the time had something called scheduled PM (or preventive maintenance) on sundays .... and not unusual for it to extend into sunday afternoons. The problem for the sport shop was big promotions associated with sunday afternoon football games and the possibility that their intended market wouldn't be able to find them on the net. Even with multiple strategic connections to different places into the backbone, many browsers would still get server not available messages w/o multiple-A record support.

Ballot for Withdrawal of X9.15 Posted - X9/01-LB#7-X9A/01-LB#3

From: Lynn Wheeler
Date: 02/28/2001 02:21 PM
To: dcsb@xxxxxxxx
Subject: Ballot for Withdrawal of X9.15 Posted - X9/01-LB#7-X9A/01-LB#3

a follow up to previous note referencing x9.15 (message formats for communicating with merchant/acquiring financial processor) being incorporated into ISO8583 ... the official notice for withdrawal of the x9.15 standard just came out today.

The ballot for Withdrawal of X9.15, Specification for Financial Message Exchange Between Card Acceptor and Acquirer - X9/01-LB#7-X9A/01-LB#3 - has been posted. The close date is 4/09/01. X9A Recommends an Affirmative vote.

assurance, X9.59, etc

From: Lynn Wheeler
Date: 02/28/2001 02:23 PM
To: dcsb@xxxxxxxx
Subject: assurance, X9.59, etc

the session presentations and tape recording of the session will be available ... i'm not sure yet whether online or not.

microsoft speaker mentioned need for tools & education and ability to hold up product release for assurance reasons .... like was done for windows 2000.

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

i started my talk with old joke about computer science having brain wipe every five years and not only are the same things repeatedly re-invented but also the same bugs (over the last 35 years, i've gone thru at least three separate generations fixing the same bugs).

When my wife and I started doing HA/CMP in the late '80s we did vulnerability analysis and came up with various bugs effectively in the basic network protocol stack as well as a common C-language use had a fundamental semantic deficiency with respect to lengths; which was likely to result in a two-orders of magnitude increase in buffer related problems (compared to our previous experience in high assurance system deployments).

random refs:

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

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

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

this isn't a problem that can just be solved by code analysis tools ... unless they force the programmer to use explicit length paradigms.

random issue related to network protocol stack issues:

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

the problem reference in the above had been going on for two months before i was asked to look at it. it turned out to be one of the things identified from the vulnerability analysis done in the late '80s.

A big difference has been that financial infrastructures typically have had majority of the issues associated with insiders not intrusion & outsiders. The current focus on intrusion is major setback and characteristic of the immaturity of the systems and protocols that are in common use. As some of these infrastructures reached nominal levels of maturity, the primary focus of financial infrastructures should return to insider issues.

One of the things is that X9.59 standard defines authenticated transactions and business requirement that X9.59 related account numbers can only be used in authenticated transactions. The existing problem of account numbers being a vulnerability and a point of attack then goes away (harvesting of account numbers by outsiders for fradulent purposes cease to be an issue since they no longer are usable in unauthenticated transactions).

i.e. requirement for the X9.59 standard was to preserve the integrity of the financial infrastructure for all electronic retail payment transactions.

I also did a high level coverage of the AADS chip and current status with regard to silicon.

Turns out that the trusted computing platform alliance is also doing a trusted platform module .... also a unique piece of silicon. It looks like there is possibly an 80% overlap in the requirements and a lot of similarity in the implementation. Possibly the AADS chip is a little further along in the silicon cycle (I got first wafer of chips last nov).

The TPM will go for protection profile certification. The AADS chip will go for both FIPS140 and PP certification, with the PP certification probably at a higher level than the TPM.

A major different between TPM certification and chips for the financial sector is that standard certification sends some number of chips off for certification and then the vendor asks the consumer to take as a matter of faith that all the rest of the chips are similar to the chips sent for certification. Financial secuirty ICs tend to have more detailed process & audit trail that provides higher level of assurance that all the rest of the chips are the same as the chips sent for certification (more than simple a matter of faith).

There was also minor observation that I was free of a lot of contensious design by committee issues that the TPM effort had to contend with.

random ref:

https://www.garlic.com/~lynn/aadsm2.htm#straw

some stuff related to certification & protection profiles

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

implementations of "XML Voucher: Generic Voucher Language" ?

Refed: **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 03/05/2001 05:35 PM
To: iang@xxxxxxxx
cc: Ko Fujimura <fujimura@xxxxxxxx>, Rachel Willmer
    <rachel@xxxxxxxx>, ietf-trade@xxxxxxxx,
dbs@xxxxxxxx
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?

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.

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).

financial standards bodys are at

http://www.x9.org/

https://web.archive.org/web/20070105065215/http://www.tc68.org/

http://isotc.iso.org/livelink/livelink/fetch/2000/2122/2567/2861/customview.html?func=ll&objId=2861&objAction=browse&sort=name

for some fsml related information

http://www.echeck.org/

misc. x9.59 information

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

Ian Grigg on 03/05/2001 08:59:35 AM wrote:
That's an interesting point. In our system, the identity of the contract is provided by a canonical message digest (calculated over the readable contract) which is used as the identifier in payments. There is nothing in the SOX protocol that limits the usage to that digest, and nothing in the Ricardian Contract that says which protocol to use (and indeed, it is possible to plugin a separate payment system into WebFunds, and use Ricardian Contracts), it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and indeed, any similar format like your XML Voucher one, to add a limitation of protocol. That might become interesting in the future as we are adding different transaction types to WebFunds as a background task, and are using Ricardian Contracts in areas that don't involve SOX directly.

--
iang

"e-payments" email discussion list is now "Internet-payments"

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 03/08/2001 08:57 PM
To: Chuck@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: "e-payments" email discussion list is now "Internet-payments"

also hosted by lists.commerce.net has been ansi-epay ... the mailing list for the x9a10 working group of (ANSI) X9 financial standards working group ... which recently passed X9.59 DSTU ... a electronic payment standard for all electronic retail payments. The charter given the x9a10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments (internet, point-of-sale, wireless, etc).

archive of the x9a10 mailing list.

https://web.archive.org/web/20020604031659/http://lists.commerce.net/archives/ansi-epay/

x9 home page

http://www.x9.org/

ISO (international) financial standards group (US is the chair)

https://web.archive.org/web/20070105065215/http://www.tc68.org/

http://isotc.iso.org/livelink/livelink/fetch/2000/2122/2567/2861/customview.html?func=ll&objId=2861&objAction=browse&sort=name

misc. other discussion & information regarding the x9.59 electronic payment standard

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

some recent related discussions on other mailing lists or newsgroups

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

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

https://www.garlic.com/~lynn/subindx2.html#publickey

a short list of some of my payment related URLs.

http://vu.wu-wien.ac.at/ecommerce/ Electronic Commerce Resources
http://www.dstc.qut.edu.au/DST/marg/eproc/bookmark990813.html EC-related Bookmarks for Margaret Turner
https://web.archive.org/web/20010421053628/http://www.dstc.qut.edu.au/DST/marg/eproc/bookmark990813.html
http://cfec.vub.ac.be/cfec/purses.htm Leo Van Hove - bibliography on electronic purses
http://www.amarshall.com/resix/ISO8583.html ISO8583 Summary
http://www.bell-labs.com:80/mailing-lists/www-buyinfo/ www-buyinfo Home Page
http://www.disastercenter.com/merchant.htm Merchant Electronic Payment Systems
http://www.fedmarket.com/sales_resources/bids/federal.html
http://www.i-m.com/hyper/inetarchive/January-1-7-1996/0007.html Internet Marketing Discussion list archive: Millicent White Paper
https://web.archive.org/web/20020127101111/http://ibill.com/ Welcome to ibill
http://www.hrl.il.ibm.com/mpay/ Mini-Pay Home Page
http://www.notablesoftware.com/evote.html Electronic Voting
http://www.strom.com/browsergui.html browsergui
http://www.uetaonline.com/ UETA Online
http://www.visa.com/cgi-bin/vee/nt/main.html?2+0 Visa-New Technologies Visa-New Technologies
https://web.archive.org/web/20020309163536/http://www.webcom.com/legaled/ETAForum/
http://www.worldchambers.com/ Chambers of Commerce World Network
http://brie.berkeley.edu/BRIE/ BRIE's Homepage
https://web.archive.org/web/20020211155502/http://www.cs.caltech.edu/~adam/isen/event-papers.html A Bibliography of Event Papers, by Adam Rifkin and Rohit Khare
http://www.ecom.cmu.edu/resources/elibrary/epaylinks.shtml
https://web.archive.org/web/20020125090034/http://www.ini.cmu.edu/netbill/ CMU's NetBill Payment System
http://www.kentlaw.edu/cyberlaw/payment.html Payment Systems/Banking working group
http://www.ccs.neu.edu/home/yiannis/pubs.html Yiannis Tsiounis, list of publications
http://www.virtualschool.edu/mon/ElectronicProperty/klamond/credit_card.htm Paying By Credit Card - Real World and Online
https://web.archive.org/web/20020122235601/http://ecommerce.gov/ United States Government Electronic Commerce Policy
https://web.archive.org/web/20020202041557/http://fms.treas.gov/ach/index.html Automated Clearing House (ACH)
http://ganges.cs.tcd.ie/mepeirce/project.html Network Payment Mechanisms and Digital Cash
http://ganges.cs.tcd.ie/mepeirce/Project/oninternet.html Payment mechanisms designed for the Internet
http://ganges.cs.tcd.ie/mepeirce/Project/tools.html Implementation Tools(electronic commerce)
https://web.archive.org/web/20020123041832/http://eco.commerce.net/ echeck at commercenet
http://www.commerce.net/resources/lists/open.html Open Mailing Lists
https://web.archive.org/web/20020126153815/http://www.tno.nl/instit/fel/intern/wkisec11.html TNO-FEL: Information Security
https://web.archive.org/web/20021218005655/http://www.abanet.org/buslaw/efss/newpub.html NEW PUBLICATIONS
http://www.abanet.org/buslaw/efss/paylib.html ELECTRONIC PAYMENTS LIBRARY
https://web.archive.org/web/20020612144232/http://www.abanet.org/buslaw/efss/private.html PRIVATE SECTOR
http://webstore.ansi.org/ansidocstore/dept.asp?dept_id=80 Ansidocstore: Department: 'X9 (ABA): Financial Services' Ansidocstore: Department: 'X9 (ABA): Financial Services'
http://www.bis.org/publ/cpss00b.htm A GLOSSARY OF TERMS USED IN PAYMENTS AND SETTLEMENT SYSTEMS
http://cryptome.org/GAO_payment_systems.html Payments, Clearance, and Settlement: A Guide to the Systems, Risks, and Issues
http://www.electronicmarkets.org/ Netacademy on EM Journal Homepage
http://www.erights.org/elib/ ELib: Local and Remote
http://www.erights.org/elib/capability/ode/ An Ode to the Granovetter Diagram
https://web.archive.org/web/20011122211304/http://www.frbatlanta.org/publica/eco-rev/ Federal Reserve Bank of Atlanta Economic Review
https://web.archive.org/web/20010816055554/http://www.frbatlanta.org/publica/eco-rev/rev_abs/1st98.html Economic Review - First quarter 1998, Volume 83, Number 1
https://web.archive.org/web/20001215022000/http://www.fstc.org/projects/bips/index.html Bank Internet Payment System (BIPS) Project
http://www.ex.ac.uk/~RDavies/arian/emoney.html Electronic Money, or E-Money, and Digital Cash
http://www.ex.ac.uk/~RDavies/arian/money.html Money - History, Present & Future - and E-Money
https://web.archive.org/web/20030207083034/http://www.qmw.ac.uk/~tl6345/index.htm Links on Law, Cryptography and Electronic Communications
https://web.archive.org/web/20010208113458/http://caag.state.ca.us/piu/creditc.htm Credit Card Chargeback Rights
https://web.archive.org/web/20000815080921/http://www.bog.frb.fed.us/boarddocs/RptCongress/ FRB: Reports to the Congress
http://www.federalreserve.gov/boarddocs/RptCongress/creditcard/1999/ The Profitability of Credit Card Operations of Depository Institutions

revised Shocking Truth about Digital Signatures

From: Lynn Wheeler
Date: 03/09/2001 09:38 PM
To: Mark Scherling <mscherling@xxxxxxxx>
cc: "R. A. Hettinga" <rah@xxxxxxxx>,
    Digital Bearer Settlement List <dbs@xxxxxxxx>,
dcsb@xxxxxxxx, cryptography@xxxxxxxx
Subject:  Re: revised Shocking Truth about Digital Signatures

Note that the recently past standard X9.59 for all account-based electronic payments doesn't specify a CADS based PKI ... but allows for an AADS based PKI ... depending on your view the certificates have been compressed to zero bytes ... or it is recognized that appended them to a signed transaction is redundant and superfluous.

The issues somewhat started in the EU ... which was started to say that all electronic point-of-sale transactions should be as anonymous as cash. As a result, the direction is to remove names from the plastic and magstripe and eliminate the requirement for a paper signature.

The corresponding direction started towards a relying-party-only certificate environment for business and financial infrastructures because of the significant privacy and liability issues associated with traditional "identity" certificates.

However, it is trivially possible to show that in such an environment that either

1) every field can be compressed out of a relying-party-only certificates because the relying party already has the original copy of each field ... whch results in zero byte certificate

or

2) appended a relying-party-only certificate to every transaction sent to the relying-party is redundant and superfluous since the relying-party alreay has the original.

in any case, numerous business (commercial, financial, etc) have perfectly privacy and liability issues that have led them away from the traditional 3rd party CADS model to a relying-party-only CADS model. However it is relatively trivial to show that a relying-party-only certificate is redundant and superfluous (and/or can be compressed to zero bytes).

X9.59 is the work of the ANSI X9 financial standards body

the X9 web site is at

http://www.x9.org/

the ISO (international) financial standards body web site (US is the chair) is at

https://web.archive.org/web/20070105065215/http://www.tc68.org/

http://isotc.iso.org/livelink/livelink/fetch/2000/2122/2567/2861/customview.html?func=ll&objId=2861&objAction=browse&sort=name

the ANSI X9.59 page at the ANSI standards publication online store:

https://web.archive.org/web/20020214081019/http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9.59-2000

misc. relying party discussions:

https://www.garlic.com/~lynn/2000.html#36
https://www.garlic.com/~lynn/2000.html#40
https://www.garlic.com/~lynn/2000.html#41
https://www.garlic.com/~lynn/2000b.html#40
https://www.garlic.com/~lynn/2000b.html#93
https://www.garlic.com/~lynn/2000e.html#41
https://www.garlic.com/~lynn/2000f.html#15
https://www.garlic.com/~lynn/2001c.html#56
https://www.garlic.com/~lynn/2001c.html#57
https://www.garlic.com/~lynn/2001c.html#58
https://www.garlic.com/~lynn/98.html#41
https://www.garlic.com/~lynn/99.html#226
https://www.garlic.com/~lynn/99.html#228
https://www.garlic.com/~lynn/aadsm2.htm#account
https://www.garlic.com/~lynn/aadsm2.htm#inetpki
https://www.garlic.com/~lynn/aadsm2.htm#integrity
https://www.garlic.com/~lynn/aadsm2.htm#mauthauth
https://www.garlic.com/~lynn/aadsm2.htm#privacy
https://www.garlic.com/~lynn/aadsm2.htm#scale
https://www.garlic.com/~lynn/aadsm2.htm#stall
https://www.garlic.com/~lynn/aadsm2.htm#techno
https://www.garlic.com/~lynn/aadsm3.htm#cstech6
https://www.garlic.com/~lynn/aadsm3.htm#kiss1
https://www.garlic.com/~lynn/aadsm3.htm#kiss4
https://www.garlic.com/~lynn/aadsm3.htm#kiss5
https://www.garlic.com/~lynn/aadsm4.htm#4
https://www.garlic.com/~lynn/aadsm4.htm#7
https://www.garlic.com/~lynn/aadsm4.htm#9
https://www.garlic.com/~lynn/aadsm5.htm#x959
https://www.garlic.com/~lynn/aadsmail.htm#perform
https://www.garlic.com/~lynn/aepay2.htm#cadis
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1
https://www.garlic.com/~lynn/aepay3.htm#aadsrel2
https://www.garlic.com/~lynn/aepay3.htm#openclose
https://www.garlic.com/~lynn/aepay3.htm#votec
https://www.garlic.com/~lynn/aepay3.htm#x959discus
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
https://www.garlic.com/~lynn/ansiepay.htm#x959ansr

Mark Scherling on 03/09/2001 02:29:38 PM wrote:
Adoption of anything takes time and depends on many factors. Let's take credit cards as an example; the first credit card was a metal plated distributed by Western Union in 1914 to preferred customers to allow them to defer payments. In 1958 the Bank of America issued the blue, white and gold card we are all so familiar with today (VISA). It took over 30 years before the credit card became ubiquitous. Today there are over 1 billion credit cards issued by VISA alone. There is also the problem with fraud. The credit card industry is moving towards smart cards and associated personal id (most are looking at PKI). The problem with replacing magnetic stripe cards with smart cards is user acceptance and the cost of replacing the infrastructure. Credit cards are successful today because of consumer acceptance, but who carries the risk? The merchant carries the risk and is liable for not only the goods lost but the transaction value. They would prefer if someone else also carried some of the risk or had better means of identifying consumers especially on non-face-to-face transaction (e-commerce, telephone, mail).

There are a lot of problems with PKI and digital signatures but not the ones that are pointed out in your article "the shocking truth" In reality PKI is not just technology and a bunch of bits; it's about policies, procedures, agreements, audit, control and people. It's complex and vendors realize this and are working at reducing the complexities. PKI works well in closed environments (an example is an organization issuing certs to employees) but there are a lot of issues when there are more than one organization issuing certs. These are mostly business, legal and liability issues and as you pointed out EDI had to solve these before it took off. The problem with EDI is that only the top 10,000 organizations can afford the high cost of the proprietary applications and VANs. There is a move to bring EDI to the Internet (ebXML), but the point is that PKI and EDI have similar needs: a complex solution needing business, legal and liability issues resolved in order to perform their functions.

The Internet is a new channel of doing business and communicating, that's all. With it comes a whole new set of rules and requirements. The next big wave is wireless, especially for developing countries that don't have the wired infrastructure dominant in developed countries like the US (wireless have a whole new set of problems). We are still wrestling with the rules and requirements for e-business and two of those are privacy and security. You read every day that a web site was hacked or credit/personal information was taken and the question comes to mind would these things have occurred if the organization had PKI. In some cases yes, however there would be a lot more fingerprints and audit information assuming you have done your due diligence in setting up and managing your PKI. The reality is that the Internet is here to stay and we need some mechanisms to improve identification, authentication and authorization of users and devices. PKI is one of the answers.

With respect to your article, you raise several issues with digital signature, non-repudiation and protection of private keys. I'd like to address these:

Proof of identity and non-repudiation (I'd like to see you prove the intent of a person based on a signature on a 30 year old paper document.) There is a correlation between intent and the act of typing in your passphrase to digitally "sign" an electronic document, which has been validated in the courts through signatory laws that demonstrate a signature shows intent. The problem is in proof that it was you and not someone else who has gained access to your passphrase and your private key. Intent is hard to proof and if you signed a document (paper) were you under duress (did someone have a gun to your head)? Trying to say "intent" is an issue in tying an identity to a digital signature is not correct. Ensuring that the person was the only one who had control of the private key is the issue. (BTW - do you give your house keys to anyone, or how about your bank information?) There are agreements that bind individuals (called subscribers) to keys and the proper protection of those keys. These agreements can be very stringent or very open depending on the value or level of assurance required. If a very high assurance is demanded, then two or three factor authentication will be required (something you have>, something you are and something you know). The deployment of smart cards and biometrics combined with PKI provide fairly high assurance of identity.

Policies and procedures are put in place at banks and other financial institutes such that there is separation of duties and one person cannot handle all the transaction. This ensures that complicity is required and fraud should be more difficult to perpetrate. Similarly policies and procedures are in place for PKI to prevent fraud. In PKI the higher the level of assurance, the more stringent the demand for identification and authentication, and the higher the value of transaction supported. Credit card issuers have a number of criteria that must be met prior to issuing a credit card and the higher the credit authorized, the more criteria needed.

Digital signatures are not replacing business administration systems. They complement the evolution towards more efficient and cost effective ways of doing business; electronic transactions, as proven by EDI.

In summary PKI is still in the early adoption phase and will continue to have difficulties as we wrestle with the business issues. These are the same business issues that e-business must deal with and organizations are always looking at ways to reduce costs and/or improve revenue. Doing business on the Internet is one of those ways. It's a matter of time before digital signature and e-business become a standard way of doing business.

[These comments do not necessarily reflect the opinion of my employer]

> Reply-To: <jwinn@xxxxxxxx>
> From: "Jane Winn" <jwinn@xxxxxxxx>
> To: "'R. A. Hettinga'" <rah@xxxxxxxx>
> Subject: revised Shocking Truth about Digital Signatures
> Date: Fri, 9 Mar 2001 11:22:46 -0600
>
> Bob:
>
> yet again, I'd like to ask you to post this to your DBS list for me.
>
> I received dozens of comments on my draft paper The Emperor's New Clothes:
> The Shocking Truth about Digital Signatures and Internet Commerce and made
> extensive revisions in light of those comments.  I think I fixed several
> errors in my discussion of the non-repudiation bit and other technological
> issues, and I tried to clarify the scope of the assumptions I was
> critiquing, and those I was not.
>
> I have posted the revised draft at the same url:
> http://www.smu.edu/~jwinn/shocking-truth.htm
!! NOTE moved to !!

http://www.law.washington.edu/Faculty/Winn/Publications/The%20Emperor's%20New%20Clothes.htm
>
> If you sent me feedback on the draft, and I haven't yet replied directly to
> your email, it is because I'm rushing around trying to get projects like
> this off my desk before I leave town (and probably lose Internet access) for
> two weeks.  I tried to acknowledge all the feedback I received in the first
> footnote, and will try to follow up with email later, but if I missed
> someone in the acknowledgments, it is only due to inadvertence so let me
> know and I will try to correct it before the article goes into print.
>
> many thanks and regards, jkw
>
>
> Jane Kaufman Winn
> Professor
> Southern Methodist University
> School of Law
> Dallas TX 75275-0116
> www.smu.edu/~jwinn
> www.virtual-langdell.com
>

revised Shocking Truth about Digital Signatures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 03/19/2001 11:32 AM
To: Mark Scherling <mscherling@xxxxxxxx>
cc: Scott Guthery <SGuthery@xxxxxxxx>,
"'R. A. Hettinga '" <rah@xxxxxxxx>,
"'Digital Bearer Settlement List '" <dbs@xxxxxxxx>,
"'dcsb@xxxxxxxx '" <dcsb@xxxxxxxx>,
    "'cryptography@xxxxxxxx '" <cryptography@xxxxxxxx>
Subject: Re: revised Shocking Truth about Digital Signatures

securing $10millioin transactions and trust propagation aren't necessarily the same thing.

digitally signing a $10million transaction to provide that message hasn't been altered and originated from the indicated person isn't the same issue with regard to trust propagation in an offline environment.

certificates were developed to address the issue of trust propagation in an offline environment (i.e. you downloaded something from a store&forward node, hung up ... or not ... in any case there is no direct connection to point of authority). they are like the letters of credit from the sailing ship days ... where relying parties had no access to the original authentication information and/or the authenticating agency (and there was no prior business relationship between the parties).

it is prefectly reasonable to have PKI with digital signatures that guarantee the message & origin w/o requiring an infrastructure supporting offline trust propagation by certificates. in fact, in the analogy of certificates to "signing limit" checks, the certificates still wouldn't indicate whether there was available balance ... just whether a person could sign that specific check for that specific amount (and not whether they had also, recently signed 200 similar checks for $5000 each against an account with <$50,000).

I would make a strong distinction between digital signature PKIs for security and assurance vis-a-vis certificate PKIs for offline trust propagation involving parties with no prior business relationship.

Parties with prior business relationship (like in cases of trading parties and/or EDI infrastructures) have no business requirement for 3rd party certification trust propagation ... especially involving the introduction of any 3rd party liability issues. Identity certificates & certification in the retail world not only introduces unnecessary liability issues but also raises serious privacy issues.

Alternatives to 3rd party certification that can raise liability and/or privacy issues are relying-party certification. The issue is that relying-party certificates would still be directed at incoming transactions that would be processed by the relying-party in an offline situation (i.e. the relying-party doesn't have online access to its business infrastructure in the ordinary course of processing, approving, authenticating, and/or authorizing the operation).

note the biometrics in an electronic environment is akin to a very complex and long PIN that doesn't have to be remembered (i.e. the biometric sensor generates a very long number that doesn't have to be remembered). There is a big difference between using a biometric value in a shared-secret open environment, a shared-secret close, secure environment and a secret environment. In the shared-secret environment, the biometric reading is effectively a PIN that is transmitted with the transaction. Current compromises of PINs result in new PINs being issued ... however at the current state of the art, it is difficult to issue new fingers or eyeballs in the case of biometric value compromise. On the otherhand, biometrics can be used in a "secret" environment ... i.e. situation where the biometric is only used to activate a private card which is then used to digital sign a transaction. Both PINs and biometrics are forms of "secrets" ... and there is a big implementation, risk-exposure, and vulnerabilities with secrets in a shared-secret environment vis-a-vis secrets in non-shared-secret environment.

random refs from some sci.crypt threads:

https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/subindex.html#scicrypt

Mark Scherling on 03/12/2001 08:57:50 AM wrote:
What if you lost $10 million? Or how about your insurance company said you can't get insurance because you are a high risk? The problem as I see it, is not B to C but B to B where there is a lot higher value transactions and loosing your credit ratings or jeopardizing your trading partners runs you the risk of losing your business. I'm not saying PKI is the answer to all security problems but one of the parts of the solution. As Bruce Schneier says "security is a process" and PKI is part of security. Look what happens if you don't apply patches and keep your anti-virus software definitions current. A lot of security breaches and down time can be contributed to unapplied patches or not keeping your definitions up-to-date.

Biometrics comes close to being the perfect solution since you have to be alive and each fingerprint/retina is unique (or at least mostly unique, I'm not sure if there may be duplicates out there, I've not fingerprinted everyone in the world), however it would still not solve the "intent" issue as someone under duress being forced to put their fingerprint on a contract. The combination of two or three factor authentication provides much higher assurance and you could use different techniques under duress such as entering in a different PIN or passphrase.

I keep hearing that PKI is too expensive and too complex to implement. Are there other solutions? Not really, biometrics is expensive and would require a massive change to our infrastructure to support. Smart cards with PIN or passphrases still don't provide a unique ID unless it's proprietary or PKI. Userid and password is not secure enough and doesn't provide a unique ID. So are there any other solutions out there that can provide a unique ID plus a level of security?

Bottom line if the requirement is there, PKI is a good solution (i.e. thousands or million dollar transactions), if you are doing $100 transaction, then I think you would find it hard to justify PKI. If implementing PKI meant you could do business with your largest trading partner (GM and EDI is a prime example of a trading partner forcing acceptance of a standard) or loose it, then you can justify PKI. If your insurance company says you need to implement PKI to get insurance (and they may all do it) then you must implement PKI or accept all the risk. PKI must be justified and without a business reason, PKI is not a viable option.

BTW - security used to be written off as a necessary expense, but more and more CIOs are using security as justification to implement better systems, with more audit and control capabilities.

Cheers

Encryption article

From: Lynn Wheeler
Date: 04/19/2001 12:40 PM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: "Fred Hapgood" <hapgood@xxxxxxxx>, Digital Bearer Settlement List
<dbs@xxxxxxxx>, dcsb@xxxxxxxx, "R. A. Hettinga"
     <rah@xxxxxxxx>
Subject:        Re: Encryption article

also ... might have interest in posting on The Thread Between Risk Management and Information Security

https://www.garlic.com/~lynn/aepay3.htm#riskm

https://www.garlic.com/~lynn/aepay3.htm#riskaads

and some of the publications of Jane Winn

http://www.smu.edu/~jwinn/
!! NOTE moved to !!
http://www.law.washington.edu/Faculty/Winn/

"Arnold G. Reinhold" on 04/18/2001 08:42:47 PM writes:
At 2:12 PM -0400 4/17/2001, Fred Hapgood wrote:

> I'm about to start working on an article dealing with the historical (by
> which I mean the last 8-10 years or so) relationship between the
> business world and encryption (as an application, not a product. I'm
> interested in the user side, not the vender side.)
>
> What should I be sure to mention, or for that matter, not mention?
> Are there myths here that need lancing? Stuff that is not usually
> pointed out but that should be?
>
> If you think there is no history worth writing about, that's fine. If
> you'd care to dilate on the reasons therefore I can promise you I
> care enough to read them carefully.
>
> www.pobox.com/~fhapgood

One thread worth mentioning if it fits in, is the failure of business to react to theoretical security problems and only respond to actual demonstrations. The continued use of DES until it was actually broken, being an example.

Arnold Reinhold

The Fundamental Inadequacies of Conventional PKI

From: Lynn Wheeler
Date: 05/12/2001 08:48 AM
To: Roger Clarke <Roger.Clarke@xxxxxxxx.au>
cc: internet-payments@xxxxxxxx
Subject: Re: The Fundamental Inadequacies of Conventional PKI

also part of recent thread in comp.security.unix:

https://www.garlic.com/~lynn/2001e.html#43

larger collection of similar threads
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

and with respect to client authentication
https://www.garlic.com/~lynn/subpubkey.html#radius

Roger Clarke on 05/11/2001 04:56:34 PM wrote:

I gather from the Internet Payments Newsletter of May 2001 that Jane Winn's paper is of interest to members:
The Shocking Truth About Digital Signatures and Internet Commerce
http://www.smu.edu/~jwinn/shocking-truth.htm
!! NOTE moved to !!
http://www.law.washington.edu/Faculty/Winn/Publications/The%20Emperor's%20New%20Clothes.htm

If so, then mine of a few months ago may be as well:
Conventional Public Key Infrastructure:
An Artefact Ill-Fitted to the Needs of the Information Society
http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html

It generated a great deal of feedback from multiple lists, varying from shocked-and-in-denial to 'well, we knew all of that already'.

A revised and shorter conference version is being presented at the European Conference in Information Systems in late June, as:
The Fundamental Inadequacies of Conventional Public Key Infrastructure
http://www.anu.edu.au/people/Roger.Clarke/II/ECIS2001.html

From there it's going into a journal, so constructively negative feedback would be much appreciated.

Thanks ... Roger Clarke

Roger Clarke http://www.anu.edu.au/people/Roger.Clarke/

Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke@xxxxxxxx.au            http://www.xamax.com.au/

Visiting Fellow                       Department of Computer Science
The Australian National University     Canberra  ACT  0200 AUSTRALIA
Information Sciences Building Room 211       Tel:  +61  2  6125 3666

Lie in X.BlaBla...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/03/2001 01:41 PM
To: Greg Broiles <gbroiles@xxxxxxxx>
cc: jamesd@xxxxxxxx, "Enzo Michelangeli" <em@xxxxxxxx>,
<cryptography@xxxxxxxx>
Subject: Re: Lie in X.BlaBla...

there may be a slightly different issue ... at least, with regard to one of early projected applications for certificates which was consumer identity in retail financial transactions. At least EU has talked about making retail transactions as anonymous as cash ... which sort of rules out using consumer identity certificates in such an environment (i.e. while consumer identity certificates in retail transactions wouldn't be fraud ... requiring them would appear to be in violation of privacy guidelines & regulations).

a stop-gap solution in europe as been relying-party-only certificates .... however, it is trivially shown that appending relying-party-only certificates to an account-based transaction is redundant and superfluous (i.e. not illegal just not KISS).

random refs:
https://www.garlic.com/~lynn/2001f.html#31
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/subpubkey.html#privacy

"greg brailes" wrote:
I don't think the new law is necessary - it's basically a retread of existing fraud and computer misuse statutes - but I don't think it criminalizes anything that wasn't criminal before. I haven't spent a lot of time crawling through Washington's criminal code - nor criminal courts, where the rubber meets the road - so I don't know if the "felony" status for this is new, or meaningful, or exemplary - it sounds like overkill, to my ears, but so does much of what comes out of our federal and state legislatures so I've stopped thinking that's remarkable.

use of digital signatures and PKI

From: Lynn Wheeler
Date: 06/04/2001 08:18 AM
To: Don Davis <dtd@xxxxxxxx>
cc: cryptography@xxxxxxxx, G�cza Zolt�n <goczaz@xxxxxxxx>
Subject: Re: use of digital signatures and PKI

that has been my assertion for a couple years ... that at least 99.9999999% of all cert events that go on in the world today are SSL events for establishing session keys ...

random ref:

https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Don Davis on 5/31/2001 8:07:14 PM wrote:
i have one potent, anecdotal data point: a friend of mine is a 3-letter executive at one of the older/bigger PKI vendors. he surprised me in a recent conversation, by mentioning that essentially none of his company's customers are using PKI for signatures. actually, he may have said, "_no-one_ is using PKI for signatures." he says that practically all of the certs are being used for negotiating symmetric session-keys.

- don davis, boston

PKI: Evolve or Die

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/06/2001 11:04 AM
To: DIGSIG@xxxxxxxx
Subject: Re: PKI: Evolve or Die

one of the targets for certificates had been retail financial transactions .... however certificates were designed to provide authentication in an offline environment ... effectively certificates represent some stale R/O distributed copy of some information in a certification authorities account record that can be used for authentication when it isn't practical to directly contact the certification authority.

the analogy is the plastic credit cards in the 50s/60s used before online infrastructure became available for online transactions.

the problem is further exaserbated by the x.509 identity certificates ... in retail financial transactions ... where the objective is to move towards greater privacy as well as greater security .... greater privacy would say that identity certificates can't be used in such an environment since they unnecessary expose all the privacy information.

european financial infrastructure has somewhat addressed this with relying-party-only certificates ... that only contain the person's account number ... addressing simultaneous both the liability and privacy issues.

in this situation it is much clearer that the certificates are totally redundant and superfluous since they are an attached to transactions that have to hit the customer's account record (i.e. the record indicated by the account number in both the transaction as well as any appended relying-party-only certificate) ... the account record which contains the "master" of the information in the stale R/O distributed copy of data called a certificate.

given that there are prior business relationships established in "closed" environment ... then 3rd party certification is redundant and superfluous. Given that it is an "online" environment ... then it is possible to directly access the original copy of the information and not have to resort to a technology construction (aka certificate) that has a design point for solving an authentication problem for the offline world.

random refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#privacy
https://www.garlic.com/~lynn/subpubkey.html#radius

"Stephen T. Middlebrook" on 06/05/2001 12:53:15 PM wrote:
Dan,

I think there is much truth in your points. One of the other failings of PKI is that everyone has gone out and created their own CA rather than rely on the certificates issued by others. The consequence being that an entity needs a different cert to interact with different parties.

This is already recognized as an issue in the Federal arena. The E-Government Act of 2001 legislation currently in Congress (S. 803) provides GSA and OMB with authority and $7 million to establish a bridge certification authority and bring some "interoperability" to federal digital signature systems. See Sec. 202.

The major problem facing PKI is one of insurance and indemnity, not one of technology. I think PKI has a future in closed system with a limited number of known players which allows the parties to assign risk, but faces extreme hurdles as an open public authentication scheme.

Steve Middlebrook

problem with the death of X.509 PKI

Refed: **, - **, - **, - **

From: Lynn Wheeler
Date: 06/06/2001 12:21 PM
To: hal@xxxxxxxx
cc: spki@xxxxxxxx
Subject: RE: problem with the death of X.509 PKI

While "pki" (lower-case) could just be public key conventions, "PKI" (upper case) has a specific market perception (regardless of the definition) that has X.509 certificates, 3rd ttp certification authorities, revokation lists, etc.

I coined the term certificate manufacturing 5-6 years ago in attempt to highlight that the deployed "PKI" for the most part were little more than the manufacturing & distribution of certificates ... and not the rest of the administration and management infrastructure that had become associated with "PKI" (upper case).

note that "AADS" & X9.59 maps into "online" account-based retail financial transactions .... "AADS" digital signatuures are also relatively trivially mapped into "online" RADIUS transactions

https://www.garlic.com/~lynn/subpubkey.html#radius

... random refs dns certificates, x9.59, adds, privacy, etc

https://www.garlic.com/~lynn/aadsm5.htm#asrn2.htm
https://www.garlic.com/~lynn/aadsm5.htm#asrn3.htm
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#privacy

"hal finney" on 6/6/2001 at 10:15:25 AM wrote:
I am curious, how do people here define PKI? There has been a lot of criticism of PKIs so I understand the concern that SPKI is affected by this. But PKI is Public Key Infrastructure, an infrastructure (in this context, a set of participants, conventions and protocols) for the use of public keys.

Ultimately isn't a PKI a way of deciding whether a given public key is suitable for a given use? In conventional X.509, you typically want to know whether a particular DNS name or email address is associated with a given key for encryption or authentication purposes.

SPKI tells whether a given key is qualified to request certain actions. But this is essentially the same type of problem: can a given key be appropriately used for a given use.

It seems to me that the problem isn't that SPKI is incorrectly classified as a PKI, but rather that the criticism of PKI has been too broad. If you look at Carl's and Bruce Schneier's "10 Risks of PKI" [1], a number of the risks do apply to SPKI as much as to any other PKI (for example, protection of private keys, security of verifying computers, user interface issues). Others are more specific to current practices in the X.509 world (like naming questions, CA and RA authority, etc.). But the paper does not clearly distinguish them.

I think it would be better for critics to focus on specific aspects of the use of public keys that can be improved, and not to brand every form of public key infrastructure as insecure.

Hal Finney

[1] http://www.counterpane.com/pki-risks.html

faith-based security and kinds of trust

Refed: **, - **, - **

From: Lynn Wheeler
Date: 06/07/2001 10:44 AM
To: "Carl Ellison" <cme@xxxxxxxx>
cc: "SPKI Mailing List" <spki@xxxxxxxx>
Subject: Re: faith-based security and kinds of trust

I was at some database conference circa '91 or '92 ... and somebody was trying to explain to me how this group in ISO (x.500) made up of mostly networking types were busily re-inventing 1960s database technology.

then when I first told about certificates and revokation lists ... it reminded me of the offline pieces of plastic and the paper booklets that were common place in the '60s .... before the industry went online in the '70s and moved to online transactions (instead of offline credentials, aka there were also re-inventing 1960s offline technology and trying to force fit it into an online world). It was also when I noticed that the whole business of revokation lists didn't actually exist (when I was working with this small client/server startup called mosaic that wanted to electronic payments and would deploy using this thing that they were calling SSL) and coined the term certificate manufacturing to try and highlight that even the "PKI" (upper-case) guys weren't even "PKI" (much of the infrastructure was/is just academic fabrication).

The concept of AADS was originally born in following the business trail for this original SSL environment (now called electronic commerce) and noticing that certificates were redundant and superfluous in situations where there was an account-based prior business relationship between the parties (consumer/bank, business/business edi, credit card, debit card, check, bank payments, brokerage houses, wire transfers, etc). X9.59 standard is a subset of that environment applying to all account-based retail payments.

"Carl Ellison" on 6/7/2001 at 05:12:33 AM wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 05:41 AM 6/7/01, Peter Gutmann wrote:

>The same thing occurs with the deified Directory (a concept so sacred that
>you have to capitalise it when you write it down, I'm waiting to see when
>it'll appear as Dy), which isn't really a directory (in even less sexy
>terms "a hierarchical database") but another utopia in which all... well,
>whatever problems the customer wants solved and will pay money to solve, are
>swept away.

Ah yes, Directory. This is X.500 in sheeps clothing. Or maybe the Devil, in some sweet disguise.

I have a great sermon by a retired bishop of Scotland around here someplace that I should scan and mail out. He was defining "faith" and "trust", if I remember correctly, and contrasting mechanistic trust to religious trust.

For mechanistic trust, we have gathered experience that something works a particular way so we're doing a prediction based on the belief that the future will mirror the past. [CME: this is probably wired into us at birth, given how easily we can move under a falling baseball to catch it, not move under where it is at each moment, but move under where it will be. This isn't just human, so it's probably not a higher brain function. My dogs could do this, too (well most of them).]

For religious trust, we have no experience at all and still we predict some particular outcome.

There was a third category, in which we expect some particular outcome in spite of much experience to the contrary, but I'm not sure that was in the sermon. That may have been in a clinical psychology textbook. :)

When he gave this sermon, I was struck immediately that most PKI thinking (and maybe Directory thinking, as you point out) is religious, not mechanistic.

- Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBOx9vr3PxfjyW5ytxEQK/NACfc91WxD+Q8s2s8xv2qlcdwqQ545gAoNX0
626RY8y+B5MwT/dhMxP0s7vj
=FS//
-----END PGP SIGNATURE-----

Online Certificate Revocation Protocol

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/11/2001 03:58:48 PM
To: "Carlin Covey" <ccovey@xxxxxxxx>
cc: "Bob Jueneman" <bjueneman@xxxxxxxx>, <ietf-pkix@xxxxxxxx>
Subject: RE: Online Certificate Revocation Protocol

in many cases, notary can include the idea of (secure) time .... i.e. that not only can you proove who signed it ... but also when it was signed.

in principle, private keys (whether compromised or not) should not be able to "pre-date" such a notorized, secure "time" signing.

typical solution is either a secure audit trail .... and/or to encapsulate the signing inside some other transaction/document which includes a secure time which is then signed by the notary function. The notary function (wether audit trail or encapsulated function) can also include the business function of validating/prooving the original signature (aka the notary attests to the validity of a specific signature at a specific time).

while a one-time key with non-expiring certificate could meet a subset of the business requirement .... it is not clear how many business processes would need just the subset w/o needing the rest of the capability (aka, a secure audit that establishes the validity of a signature executed at a specific time would subsume the need for a one-time signature key and also meet additional normal, day-to-day business requirements .... aka not only is there the issue of what order a sequence of signatures might have taken place .... but also what order did signatures take place within the context of real-world events and sequences ... i.e. time).

If you are going to go to all the trouble of a notary ... dump the stuff with the one-time private key .... and meet the rest of the business requirements which includes did the signature verify and at what time did the signature verify.

"Carlin Covey" <ccovey@xxxxxxxx>@xxxxxxxx on 06/11/2001 10:00:12 AM writes:
[Bob Jueneman]:

Indeed, although some have deprecated the concept of a private key validity period, it makes a great deal of sense to DELIBERATELY destroy a given signature key, especially a code or certificate signing key, well before the corresponding certificate expires. From the point of view of the certificate subscriber, this minimizes his risk by making certain that the key can NOT be compromised, yet the certificate has not expired or been revoked, so the certificate will continue to validate properly.

[Carlin Covey]:

I agree with Bob. It might even be desirable to use "one-time" signature keys for signing particularly important documents, such as major contracts, wills, etc. There might even be a super non-repudiation policy associated with the guaranteed destruction of the signature private key. This might be implemented via some trusted hardware token that generates the keypair, signs the document, destroys the private key, and signs a notification of private key destruction. Another possibility is some sort of trusted "key-destruction notary" service that notarizes the document, and then destroys the certified one-time signature key as a matter of policy.

Regards,

Carlin

________________________

- Carlin Covey
Cylink Corporation

Online Certificate Revocation Protocol

From: Lynn Wheeler
Date: 06/11/2001 07:04:14 PM
To: "Carlin Covey" <ccovey@xxxxxxxx>
cc: <ietf-pkix@xxxxxxxx>
Subject: RE: Online Certificate Revocation Protocol

.... as per aside ... having somebody sign a document ... and then a notary validate the signature with the public key, and then the notary signs a composite document ... consisting of the originally signed document, the signer's public key, and the current time ... and then log it to a secure audit trail ..... could be done completely w/o the original signer's certificate .... since in effect, the notary can perform at least all the feature/function of a RA & CA as part of their function (in effect the composite document that the notary signs .... is a kind of certificate).

It isn't absolutely necessary to know any validity period (from a certificate) of the original signer's public/private key .... it is just necessary that the notary validates the information as correct at the time it was signed/validated (and/or can be later shown to be valid at the time of the signing).

.... have you noticed that the postings to the mailing list seems to have some sort of lag? I've yet to see my original reply to you made at 3:59 (MDT) ... 3 hrs later (presumably you answered the copy of the reply sent directly).

"Carlin Covey" on 06/11/2001 04:42:12 PM writes:
Lynn,

I quite agree that notarizing, with or without secure time, is a more comprehensive solution. I simply proposed one-time signature keys as an example of a situation in which the certificate is expressly intended to be valid after the private key has been destroyed. Now whether anyone would want to use one-time signature keys is another matter ....

Regards,

Carlin

____________________________

- Carlin Covey
Cylink Corporation

Simple PKI

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/12/2001 07:30:30 PM
To: DIGSIG@xxxxxxxx
Subject: Re: Simple PKI

and then there is certificate-less PKI ... or AADS .... where people register their public key .... technology process is effectively the same as the RA/CA process .... but the business process is essentially like registering a password/pin .... aka if you are authenticating with entity involving prior business relationship (bank, financial institution, account-based operation, EDI, employment, etc) ... then just register the public key with the relying party and authenticate as needed.

this is the simplification of the relying-party-only certificates done for privacy & liability reasons ... but when the actual information flow is examined in detail ... it is obvious that the certificates are redundant and superfluous.

for most of the "relying-party" environments ... they ahve a solid "IT" department because the purpose of the authentication is in conjunction with some real live business process (i.e. like authorizing transactions) ... aka the business isn't performing authentication operations in the vacuum .... independent of any business justification. It is possible to imagine a business that just does authentication operations ... w/o any associated business justification and/or business reason .... but I don't know how likely it is.

Charlotte Axsmith on 06/12/2001 09:02:43 AM wrote:
Interesting thoughts on PKI, and I would tend to agree in most circumstances. There is something called SPKI (Simple PKI), which dispenses with the Certificate Authority. Below are some explanatory links.

The appeal of SPKI is that a party issues their own certificates and then is responsible for managing their own risks. The party themselves can determine the uses of their SPKI signature (either as a letterhead or to purchase raw materials)and then the type of value it would have. I have heard many debates about the value of certificates and how that will affect their uses in the marketplace. Using this methodology, an organization can tailor the use of assymetric crytography to meet the needs of their organization.

The disadvantages would be that the organization using these SPKI certificates would need to have the solid IT department that could reliably set up and manage the system. I would be interested in the thoughts of others on this. I am of the opinion that SPKI is under-rated and is worth a serious look.

Christine Axsmith
Axsmith.net
202.434.4576

Online Certificate Revocation Protocol

Refed: **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/13/2001 12:32:05 AM
To: "Scherling, Mark" <mscherling@xxxxxxxx>
cc: Carlin Covey <ccovey@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject:  RE: Online Certificate Revocation Protocol

the notary can do what he does today ... certifies that the person possesses some number of things (like some device for signing which can be verified with a specific public key) and some number of other things .... effectively a combination of the existing notary business practices along with some things like a RA & CA ....aka the notary is responsible for whatever the notary standards require the notary to attest to ... if the notary standard says that the standard is a driver's license, a passport, a hardware token that requires a PIN, and actually perform a digital signature ... then the notary can attest to that. If a different notary standard requires the notary to validate a RA & CA process done by some other entity (which checked a drivers license, a passport, and that a specific digital signature could be verified) ... in the form of a valid digital signature ... then the notary could attest to that.

The notary, in theory, could also do an online validation that a specific public key was registered to a specific person (say a new kind of online request sent to one of the existing credit bureaus) ... and that the entity seemd to be the same (an online request instead of needing a certificate designed for satisfying authentication requirements in an offline world) .... it is whatever the notary is supposed to be notarizing.

Just because most existing (capital) PKIs happen to specify certificates that were a paradigm solution to authentication opportunities in an offline world ... doesn't necessarily mean that the process that a notary would use in an online world need be the same

"Scherling, Mark" on 06/12/2001 08:18:37 AM wrote:
If there is a notary in the context of the transaction then the notary would be liable for the transaction if the certificate and private key that signed the document originally was proven to be invalid (i.e. key was assumed destroyed but copy made and copy signed document). I think that we can argue that there was no intent by the owner of the key to sign the document, however their digital signature is attached to the document signed by the notary, who did not know that the key was destroyed (no record of key revocation, certificate is valid, so notary signs).

I really like the idea of a notary function but you still need to revoke the key if it was destroyed. A key that was destroyed is in an unknown state (was the key really destroyed and are there no duplicates?). So the CA must revoke the key to place it in a known state. The public key can still be used to verify transaction prior to the revocation. However anything after revocation should be rejected. I feel that the security risks associated with leaving a key in an unknown state are far greater than the problems associated with revoking a key.

Online Certificate Revocation Protocol

From: Lynn Wheeler
Date: 06/13/2001 08:26:58 AM
To: jim <jimhei@xxxxxxxx>
cc: Carlin Covey <ccovey@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject:  Re: Online Certificate Revocation Protocol

a certificate doesn't represent anything particularly magic ... pretty much a credential target at being used in offline environments (when there access to an online authority) ... and the thing the credential represents is pretty much ... stuff that notaries do on a routine basis .... check some sort of reference to authenticate some information. In fact, a big part of the reason that a certificate has a validity period at all ... is to limited the exposure of a certifying authority in an offline paradigm environment where the certificate could be used in an unknown number of unknown transactions. A notary doing the certification in real time and online doesn't have that exposure because they typically know the number and kinds of transactions they are certifying.

jim on 06/13/2001 06:24:03 AM wrote:
This is especially true if the secure audit trail contains the information that the user was authenticated at the beginning of the session and that the authentication was successful, the certificate was within its validity period and that it was not revoked. Jim

Simple PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/13/2001 04:59:05 PM
To: DIGSIG@xxxxxxxx
Subject: Re: Simple PKI

one might contend that the attempted objective of obtaining status of non-repudiation for certificate-based digital signatures ... is to increase the perceived value of the certificate ... where an authentication business process is being done in the absence of any other business operation (aka most business process recover the cost of doing certification/authentication as an adjunct to some business process value transaction .... as opposed to just doing it independently of any other business reason).

Financial institutions have looked at relying-party-only certificates (aka just an account number) as a means of addressing some of the really thorny privacy and liability issues that are inherent in standard identity certificates. However, it is trivial to show that it is possible to compress a relying-party-only certificate to zero bytes in any of the various online transactions between entities that have prior business relationships (account-based payment, edi, login, session authentication, access, etc).

The value in this sort of certificate-less pki is that it can be much harder to counterfeit and/or generate fradulent transactions while essentially maintaining all the existing business processes.

Nicholas Bohm on 06/13/2001 07:34:59 AM wrote:
At 12:02 12/06/2001 -0600, Bob Jueneman wrote:

[snip]

>What is perhaps even more interesting is to note that while the
>technologists have been trying hard to tighten up various business and
>legal processes with strong authentication, etc., businesses in general
>have been moving in exactly the opposite direction, at least within the US.
>The eSign legislation is an obvious example -- almost anything can be a
>legally binding signature, up to and including a twitch on a mouse button.

This of course mimics the rest of life, where many contracts (even more outside the US than within, perhaps) can be made by word of mouth with no evidence of their content beyond the testimony of the parties.

>But credit cards have become ubiquitous, and no long have to be presented
>in a face to face transaction. Just phone them in.

This is fine for the customer under a regime accepting the chargeback mechanism, under which the customer can repudiate and leave the merchant with the risk. It only begins to go wrong when PKI is introduced with the exaggerated claim that it can support non-repudiation, i.e. enable bank and merchant to leave the customer with the risk of forgery (e.g. by surreptitious theft of a private key).

>Even what used to be the most common form of signed document, the paper
>check, has had the importance of the signature whittled away steadily.
>Banks abandoned even the fiction of validating every signature back in the
>50's or 60's, and perhaps earlier. Now, even in the case of an obvious
>difference in the signature, most banks would require that the user take
>them to court in order to reverse a transaction.

Not in the UK, at least. It is well understood that a forged cheque gives the bank no authority to debit the customer's account, and that the bank must prove that it has the necessary authority if challenged. On this foundation, it is wholly reasonable for the banks to decide which signatures are worth verifying, since they carry the risk of not doing so. If the customer is to carry the risk, then the bank ought to be under clear duties as to verification.

>So possession of the check book, or knowledge of the account number, is
>about all it takes any more. This is shown even more clearly by the
>increasing trend to authorize electronic debits over the phone, where a
>simulated check is cut and the signature line says something like
>"Signature on file", even though it clearly isn't.
>So I would argue that it isn't the case that PKI is dead, or not useful,
>although some of the vendors who were building such solutions have had to
>cut their staffs very significantly in the current downturn.
>
>It was digital signatures, backed only with identity certificates, that
>were oversold, and have not materialized to any significant degree as yet.
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>
>Novell, Inc -- the leading provider of Net services software

Regards

Nicholas Bohm

Salkyns, Great Canfield,
Takeley, Bishop's Stortford CM22 6SX, UK

Simple PKI

Refed: **, - **, - **

From: Lynn Wheeler
Date: 06/15/2001 10:10:18 AM
To: DIGSIG@xxxxxxxx
Subject: Re: Simple PKI

some part of the strong authentication issue is whether the design point is for an offline or online environment

part of the trade-off of having an offline design point .... is who all might be the relying parties and out to pull-back the credential ... especially in an era where once a credential is manufactured an unlimited number of copies might be made in dealings with an unknown number of relying parties.

Modesl are the letters-of-credit from the days of sailing ships and before being able to electronically contact the issuing/responsible financial institution directly (and/or the original credit card plastics before the advent of online networks). The solution before the ubiquitous deployment of online networks was that some sort of credential was manufactured that would assert various things by the issuing/responsible institution that could be relied upon by other parties. The obvious short-comings of the manufactured credential is that the issuing/responsible institution would have no idea how many times and/or where the credential might be used. Given that the issuing/responsible institution had little or no concept as to who relying parties might be, nullifying and/or abbrogating a credential might involve a broadcast to every entity in the world that could possibly act as a relying party.

The transition to ubquituous online networks tended to shift the paradigm from manufactured credentials targeted for the offline environment to online transactions by the relying party (transition in the letter of credit days started out with telex/telegrams sent to the responsible party for corroborating details of the credential ... finally being replaced with the elimination of the credential all together and the relying parties just used telex/telegrams transactions).

The corresponding situation in the case of the credit card credential went thru a phase of monthly booklets of revoked plastics mailed to all possible merchants contain all revoked plastics, value thresholds requiring the relying party to call in and verbally receive a transaction authorization code, and finally direct online transaction.

The transition from offline credentials to online transactions is a combination of the ubquituous of the online network and the timeleness value of the assertions being made in the credential (credit limit, bank account, employment, authorization, etc are all types of attributes that tend to have timeleness value) along with the uncertainty factor associated with the identity and number of possible relying parties (how determinable is the possible population of relying parties).

A large portion of "tightening" has to do with a solution that is a fundamentally offline design point and trying to resolve the inconsistancies that would crop up in a fundamentally online environment. Part of the inconsistency is attempting to treat the offline shortcomings (in an online world) as a technology failing when it really amounts to having inconsistent assumptions (offline solutions will tend to exhibit all sorts of deficiencies during transition to a fundamentally online world). The issue then becomes can the direct online communication (with the issuing/responsible party) be authenticated and trusted .... not that can authentication and trust for an electronic message be established with an offline credential from some issuing/responsible party.

Simple PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 06/15/2001 11:06:00 AM
To: DIGSIG@xxxxxxxx
Subject: Re: Simple PKI

Anne and I had dinner night before last with the person that says he drafted the original X12 spec and wrote the first EDI book.

EDI had two issues, the cost of interfacing complex legacy systems to a defined transaction and format specification and the cost of the delivery "value added networks". The authentication issue (for EDI) could be considered in the noise range compared to the difficulty of implementing transaction and format mappings.

In some cases, the level of EDI difficulty exceeds y2k issues; any particular legazy system might not have a 1:1 mapping for the kinds & types of transactions or the kinds & types of fields as defined in the EDI standard. In that respect, EDI is much more difficult than a simple encoding issue (i.e. ASN.1 &/or XML encoding for interoperability) because there may not be a direct mapping with kinds of ransactions and/or kinds of fields.

A simple complicating factor for NxM authentication (and offline credentials) in cross organizations associated with EDI authentication is the concept of signing limit. The offline solution for signing limit associated with business transactions was checks that had signing limit printed on the check ... but they found people could bypass that with justing doing multiple checks.

In a typical EDI scenerio, not is somebody authorized to do EDI transactions (i.e. possibly not just ever employee), but specific employees may have limitations as to types of EDI transactions as well as real-time running budget constraints i.e. not only am I authorized to buy pencils from any of three vendors ... but I'm authorized to only buy up to 1 million pencils per month. The real-time online requirements for modern EDI authorization go beyond whether I'm an employee of a particular corporation, but the corporation would also like to control the real-time characteristics of the transactions (including various real-time aggregation issues).

The simplest way of guaranteeing that is the partners have final authorization agents. An signed EDI transaction is originated by an employee and transferred to an authorization agent. The authorization agent validates the employee signature and checks various real-time factors including aggregated factors and then cross-signs the transaction. The relying-party-only has to verify the authorization agents signature, the employee's signature is only necessary for audit trail.

Some number of corporations are simplifying this by going to business purchase cards that look and taste like a credit card ... but the business can specify complex rules at a specific account level. One of the drivers for SKU-level ("level-3") detail in the credit card network is so business rules can be expanded to not only include

specific transaction amount,

aggregation of transaction amounts ... i.e. credit limit,

type of merchant(s),

specific merchant(s)

specific merchant location(s)

but also as to type of item(s).

The business card transactions then are further enhanced so that the account statements are then electronically transmitted back to the corporation in EDI format ... so that they flow back into the corporations standard electronic purchasing/payment legacy systems.

One more simple step is for the business card to be issued with a chip and the transactions become X9.59. The corporation just makes sure that the public key of the chip is registered with the business card processing account.

To finally conform to my assertions regarding what the relying party pays attention to, the "merchant" doesn't validate the X9.59 signature, since for their purposes that only establishes the account owner and not whether the actual transaction is authorized. The transaction with the X9.59 signature is transmitted to the business card processor who runs it through the real-time aggregation rules before authorizing the transaction.

Fundamentally, if it was still in the days of the offline world, the merchant would be paying attention to the credential (aka "credit card" or even chip-enhanced credit card), however with the transition to an online world, the added benefit to do the additional forms of real time evaluation (like aggregation factors) far outweight the incremental cost of the online transaction.

Bob Jueneman on 6/13/2001 9:35:55 AM wrote:
i normally have a hard time making it though your notes .... no capitalization ... too many ellipses ... too disconnected. :-)

But I believe you are half right, at least.

Within the confines of one relying party organization, such as a bank with respect to its own customers, they are obviously authoritative as to the identity, and much more importantly, the privileges accorded to the customers and employees than a public CA could ever be.

In that environment, if you are merely going to be registering that identity and privileges in a directory, you don't necessarily need the formality of X.509. Novell has been doing exactly that with our NDS eDirectory for longer than the five years I've been here -- the public key is recorded in the directory, and after having suitably authenticated the user (username and password, normally), the private key is temporarily downloaded for use in background authenticating to other processes. In this environment, as you say, the processes are effectively that of an RA/CA, but without the third party involvement.

Where this starts to break down is when you cross the boundary between in intranet and an extranet.

In my definition, at least, an extranet involves two or more organizations working more or less together, but without an integrated (some people use the word federated) directory or database of each organization's personnel and their privileges.

It isn't that this is a technical problem -- Novell's eDirectory has been demonstrated to be capable of handling a billion objects, although scalable and replication could be a problem at that level. No, the real problem is human/procedural. Organizations have a hard enough time keeping their own employee databases up to date (between HR, the IT department, Facilities, etc.), much less be legally responsible for keeping someone else up to date with everyone's comings and goings. And if it would be hard enough to do it between two cooperating organizations, imagine the difficulty between one manufacturer and 100 suppliers, when each supplier probably has 1000 customers who would also like to have the same degree of authentication.

The processes simply break down under the weight of the N-squared combinatorial problem, and most especially if you have to be concerned about the identity of individual roles of a thousand employees in each organization.

This is why EDI never really took off. Only the largest of companies could afford to do it, and even then they didn't get down to the level of the individual employee who was authorized to do something.

The answer to this kind of scalability problem is relatively simple, of course -- it is similar to the hub and spoke principle used by the airlines. the enterprises sign agreements with each other, and delegate to each other the right to identify users and roles that will be mutually acceptable.

Now SAML and the OASIS group is beginning to do this. They essentially have enterprise A go through whatever type of identification process they normally do, and then either though a browser redirection or a more direct push or pull model, they convey that authorization to enterprise B.

In a sense, enterprise A is acting as a CA and enterprise B as a relying party, except that they don't necessarily get all that paranoid about the end user's "true" identity. This relationship may or may not be expressed in the form of a certificate -- it may be merely a encrypted "ticket" that may or may not identity the end user and may or may not convey specific rights.

This is essentially single-signon for the Internet.

There are some potential dangers lurking here, however. If Enterprise A merely sends the equivalent of an encryption cookie to Enterprise B, identifying use X, then it is possible that anyone who could intercept that cookies and use it within the validity period (typically short - perhaps a few minutes) could impersonate that user.

So for better security, it would be desirable to use a public key or similar mechanism that wouldn't require user input to make happen. If the user already has a public/private key that is unlocked and accessible to the application, that could be used, or perhaps a new key pair (either in X.509 format or not) could be generated and downloaded to the user, with the public key being communicated to Enterprise B. B could then require the end user to reauthenticate himself, but this could all take place under the covers, without user involvement.

Of course the real question is what is this authentication being used for, and what protections are should be required. If Enterprise A is my company's portal, and Enterprise B is say Fidelity, I might be a little bit upset about an automatic authentication mechanism that might allow an application to access my private key and sell all of my stock.

A lot still needs to be worked out in this arena, obviously.

Bob

PS -- say hi to Anne.

Public key technology

Robert R. Jueneman Security Architect

Simple PKI

From: Lynn Wheeler
Date: 06/15/2001 02:51:27 PM
To: DIGSIG@xxxxxxxx
Subject: Re: Simple PKI

i.e. .... authentication is normally done in conjunction with some business goal ... not as part of some authentication only event aka i open the door of a store and announce, "hi, i'm account number xyz" and then immediately walk out (for the moment ignoring the privacy and liability issues)

one of the problems of trying to deploy some authentication paradigm that has absolutely no justification as part of some business process .... is trying to find ways of covering the cost of the deployment (even if it is possible to convince everybody that frequent authentication events serving no business purpose is an enjoyable activity and will make their life richer and healthier).

AADS Postings and Posting Index,
next, previous - home