X9.59 mailing list
x959 Postings and Posting Index,
next, previous
- home
- Online Card Fraud Thirty Times That Offline
- X9.59 Electronic Payment standard status
- X9.59 Electronic Payment standard issue
- ANSI X9 Electronic Standards "store"
- X9.59 Web site??
- Intel Developer's Forum ... fyi
- some electronic commerce discussion from dcsb & IDF
- implementations of "XML Voucher: Generic Voucher Language"?
- implementations of "XML Voucher: Generic Voucher Language"?
- harvesting of credit card numbers
- shared-secrets, CC#, & harvesting CC#
- X9.59 available at the ANSI X9 online publication store
- GAO: Government faces obstacles in PKI security adoption
- GAO: Government faces obstacles in PKI security adoption
- GAO: Government faces obstacles in PKI security adoption
- GAO: Government faces obstacles in PKI security adoption
- best ketp secrets of money(?)
- 7th CACR Information Security Workshop
- 7th CACR Information Security Workshop
- assurance, X9.59, etc
- Digital Signatures Spark Debate
- Announce: Eric Hughes giving Stanford EE380 talk this
- Announce: Eric Hughes giving Stanford EE380 talk this
- do CRL's actually work?
- Electronic Commerce Modeling Language
- AADS NWI closed two years ago today
- latest credit scam puts plastic in peril ... is your credit card being cloned?
- use of digital signatures and PKI
- Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi
- use of digital signatures and PKI
- use of digital signatures and PKI (addenda)
- Entrust To Cut 400 Jobs .... fyi
- problem with the death of X.509 PKI (forwarded)
- use of digital signatures and PKI (addenda)
- use of digital signatures and PKI (addenda)
- "out of control credit card fraud"
- "out of control credit card fraud"
- call for new measures: ICH would be glad to help
- MS masters NC mind-set (authentication is the key)
- MS masters NC mind-set (authentication is the key)
- "Gurard against Identity Theft" (arrived in the post today)
Online Card Fraud Thirty Times That Offline
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 08:36 AM
To: ansi-epay@xxxxxxxx
Subject: Online Card Fraud Thirty Times That Offline
Online Card Fraud Thirty Times That Offline
Celent
http://www.celent.com/PressReleases/20001218/OnlineFraud.htm
Dec 19 2000 : Online merchants are experiencing fraud rates of 30
times higher than their real-world counterparts this holiday season,
according to new research from Celent Communications. The report,
"Online Payment Fraud: The Grinch That Stole e-Christmas?", predicts
Web stores to lose USD 300 million to fraudulent payments, or 3 per
cent of total holiday eCommerce sales, by year-end 2000. However,
Celent expects credit card firms to "come to the rescue with a
workable solution that reaches critical mass within 3 to 5 years".
For now, Celent predicts a growing number of merchants to adopt
score-based solutions to combat online fraud, since merchants
"struggling to be profitable" already foot the bill for losses. While
Forrester Research predicts eCommerce to grow from USD 8 billion in
1999, to USD 108 billion in 2003, IDC expects aggregate fraud-related
losses of USD 200 million from this year's USD 12 billion. In July
2000, Gartner found e-tailers to incur 2.64% online charge back rates,
with fraudulent or stolen credit cards accounting for 1.13%.
Odyssey Research also noted fear of credit card fraud to be a
significant barrier to on-line purchasing, with 31 per cent concerned
about credit card fraud, and 25 per cent not trusting the
Internet. Still, a joint survey by Goldman Sachs and PC Data, recorded
a 50 per cent growth in online sales during the week after
Thanksgiving, compared to the same period in 1999. Accordingly, PC
Data concluded that online spending volume was being spread across
several weeks, rather than spiking, as in December last year.
X9.59 Electronic Payment standard status
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 09:55 AM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Electronic Payment standard status
The X9.59 DSTU period starts Feb. 1, 2001 and runs through Jan. 31, 2003
The X9.59 DSTU standards document should appear in the next standards
publication catalogue:
DSTU X9.59-2001, Electronic Commerce For the Financial Services Industry:
Account-Based Secure Payment Objects
X9.59 defines a secure payment object for use in authenticated financial
transactions. It relies on existing X9F security standards for payment object
authentication. It supports secure payments involving virtual (e.g. Internet) or
face-to-face transactions. It applies to card-based (e.g. smart card) financial
transactions as well as other forms of electronic financial transactions (e.g.
e-check).
X9.59 Electronic Payment standard issue
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/09/2001 03:26 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Electronic Payment standard issue
One of the complaints about the X9.59 standards document (especially
from X9F) is that it doesn't specify key management standards.
X9.59 defines a secure payment object that can be used in
authenticated transactions using X9F authentication standards.
As such it relies on X9F authentication standards ... and where X9F
authentication standards involve keys (symmetric &/or
public/private), protection of keys is somewhat part of the related
X9F standard involving that particular authentication standard.
A related issue is that many of the X9F key-related standards are
applied to wholesale transactions and/or backroom portions of retail
transactions. One of the things that X9.59 is potentially moving into
is the direct involvement of consumers with keys. This may be on-par
with the existing PINs which is not unusual to find consumers having
written on their magstripe card.
while wholesale environments have a little more luxary in specifying a
single key management standard across all environments (in part
because the cost of key management tends to be only a small percentage
of the overall costs) ... retail arenas tend to be somewhat more cost
sensitive and ideas like parameterised risk management come into play
(i.e. integrity costs proportional to the related values & risk in
the environment). The issue is that in some cases, incremental
integrity costs can be a multiple of existing costs as opposed to a
small percentage of existing costs.
Simplifying somewhat, parameterised risk management would indicate
that the integirty costs (like key protection) should be proportional
to the related transaction values being protected &/or related
risk/fraud. This might be an interesting emerging security area, being
able to establish integrity costs proportional to risk.
In another area, one of the related advantages of X9.59 is that it
specifies that account numbers used in X9.59 only be usable in
authenticated transactions i.e. it is not possible to evesedrop and/or
collect large numbers of X9.59 account numbers and use them in
un-related, fraudulent un-authenticated transactions.
As a result, it significantly mitigates some of the end-to-end
integrity costs associated with management of shared-secret account
numbers (i.e. account numbers that can be collected and used in
un-related, fraudulent, un-authenticated transactions).
ANSI X9 Electronic Standards "store"
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/26/2001 01:33 PM
To: ansi-epay@xxxxxxxx
Subject: ANSI X9 Electronic Standards "store"
The X9 portion of the ANSI standards document electronic store is at:
http://webstore.ansi.org/ansidocstore/dept.asp?dept_id=80 Ansidocstore: Department: 'X9 (ABA): Financial Services'
X9.59 should be showing up there any moment.
current list ....
Number
Document Title
Price
ANSI X9 DSTU-2-1995
EBT Processor Interface Technical Specifications
$40.00
ANSI X9.1-1991
Bank Cards - Magnetic Stripe Content for Track 3
$40.00
ANSI X9.10-1992 (R1998)
Merchant Category Codes
$40.00
ANSI X9.12-1991 (R1998)
Municipal Securities, Specifications for Fully Registered
$80.00
ANSI X9.13-1999
Placement and Location of MICR Printing, Specifications
for the
$120.00
ANSI X9.14-1983 (R1995)
Securities Transaction Interchange Forms,
Specifications for
$80.00
ANSI X9.15-1990 (R1996)
Specification for Financial Message Exchange Between
Card Acceptor and Acquirer
$165.00
ANSI X9.18-1998
Paper Specifications for Checks
$40.00
ANSI X9.19-1996
Financial Institution Retail Message Authentication
$80.00
ANSI X9.20-1998
Securities - Institutional Delivery System
$80.00
ANSI X9.24-1998
Financial Services - Retail Management
$120.00
ANSI X9.27-2000
Print and Test Specifications for Magnetic Ink Printing
(MICR)
$120.00
ANSI X9.29-1998
Financial Services - Check Carrier Envelope
Specifications
$120.00
ANSI X9.30.1-1997
Public Key Cryptography for the Financial Services
Industry - Part 1: The Digital Signature Algorithm (DSA)
$40.00
ANSI X9.30.2-1997
Public Key Cryptography for the Financial Services
Industry - Part 2: The Secure Hash Algorithm (SHA-1)
$40.00
ANSI X9.31-1998
Digital Signatures Using Reversible Public Key
Cryptography for the Financial Services Industry (rDSA)
$80.00
ANSI X9.32-1998
Data Compression in Wholesale Financial
Telecommunications
$40.00
ANSI X9.33-1999
Specifications for Bank Deposit Tickets
$40.00
ANSI X9.34-1993
Asset Sales
$80.00
ANSI X9.37-1994
Specification for Electronic Check Exchange
$90.00
ANSI X9.40-1998
Check Strip Extension
$40.00
ANSI X9.45-1999
Enhanced Management Controls Using Digital
Signatures and Attribute Certificates
$80.00
ANSI X9.46-1997
Financial Image Interchange: Architecture, Overview, and
System Design Specification
$120.00
ANSI X9.47-2000
Creating MICR Document Specification Forms
$80.00
ANSI X9.49-1998
Secure Remote Access to Financial Services for the
Financial Industry
$80.00
ANSI X9.5-1988 (R1994)
Financial Institution Numbering System (FINS)
$80.00
ANSI X9.51-1998
Fraud Deterrent Icon Standard
$80.00
ANSI X9.52-1998
Triple Data Encryption Algorithm Modes of Operation
$80.00
ANSI X9.53-1996
Specifications for Check Endorsements Including
Legibility
$120.00
ANSI X9.55-1997
Public Key Cryptography for the Financial Services
Industry: Extensions to Public Key Certificates and
Certificate Revocation Lists
$40.00
ANSI X9.57-1997
Public Key Cryptography for the Financial Services
Industry: Certificate Management
$40.00
ANSI X9.6-1991 (R1998)
Securities Identification
$80.00
ANSI X9.62-1998
Public Key Cryptography for the Financial Services
Industry : The Elliptic Curve Digital Signature Algorithm
(ECDSA)
$80.00
ANSI X9.69-1998
Framework for Key Management Extensions
$40.00
ANSI X9.7-1999
Bank Check Background and Convenience Amount Field
$120.00
ANSI X9.71-2000
Keyed Hash Message Authentication Code (MAC)
$40.00
ANSI X9.8-1995
Banking – Personal Identification Number Management
and Security – Part 1: PIN Protection Principles and
Techniques; Part 2: Approved Algorithms for PIN
Encipherment
$80.00
ANSI/ABA X9
ANSI/ABA X9 Data and Information Security Collection
$700.00
ANSI/ABA X9
ANSI/ABA X9 Paper Check Collection
$800.00
ANSI/ABA X9
ANSI/ABA X9 Retail Electronic, Security and Electronic
Benefits Transfer Collection
$650.00
ANSI/ABA X9
ANSI/ABA X9 Securities Collection
$410.00
X9 TG-10-1994
Signature Guarantee Guideline
$80.00
X9 TG-15-1997
Technical Guideline: to aid in the Understanding &
Implementation of Financial Image Interchange
$80.00
X9 TG-19-1-1999
Part 1: Modes of Operation Validation System for the
Triple Data Encryption Algorithm (TMOVS):
Requirements and Procedures
$120.00
X9 TG-2-1995
Understanding and Designing Checks
$80.00
X9 TG-23-1-1999
Implementation Guide for ISO 8583-Based Card
Acceptor to Host Messages - Part 1 - Conveinence Store
and Petroleum Marketing Industry
$120.00
X9 TG-3-1997
Pin Security Compliance Guideline
(free download now)
$0.00
X9 TG-4-1993
Recommended Notation for DEA Key Mgmnt in Retail
Fin. Networks
$40.00
X9 TG-5-1992
Information Security Guideline
$80.00
X9 TG-6-2000
Financial Services Technical Guideline
$80.00
X9 TG-7-1995
Initial DEA Key Dist. for PIN Entry & Transaction
Originating Dev.
$40.00
X9 TG-8-1995
Check Security Guideline
$80.00
X9 TG-9-1995
Abstract Syntax Notation and Encoding Rules for Inf. Ind.
Standards
X9.59 Web site??
From: Lynn Wheeler
Date: 02/12/2001 12:15 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 Web site??
happened to stumble across the following (doing a query on x9.59
w/fast search engine)
http://www.ca0.net/
Intel Developer's Forum ... fyi
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/25/2001 10:07 AM
To: ansi-epay@xxxxxxxx
Subject: Intel Developer's Forum ... fyi
Intel Developer's Forum starts tomorrow in San Jose. I'm on a panel discussion
talking about assurance. One of the subjects is e-commerce (and some X9.59
standard)
reference
https://web.archive.org/web/20010801203303/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp%2bs13
some electronic commerce discussion from dcsb & IDF
From: Lynn Wheeler
Date: 03/02/2001 10:40 AM
To: ansi-epay@xxxxxxxx
Subject: some electronic commerce discussion from dcsb & IDF
some electronic commerce discussion from dcsb & assurance panel at Intel
Developer's forum:
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
misc. other
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
implementations of "XML Voucher: Generic Voucher Language" ?
From: Lynn Wheeler
Date: 03/08/2001 12:06 PM
To: iang@xxxxxxxx
cc: Ko Fujimura <fujimura@xxxxxxxx>, Rachel Willmer
<rachel@xxxxxxxx>, dbs@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
note that in the mapping of X9.59 to iso8583 ... the payment
transaction isn't being done in ASN.1 ... it is being done in ISO8583
messages.
The encoding mechanism in the standard for digital signing and digital
signature verification is ASN.1 ... but the mapping to ISO8583 is
basically ISO85893 messages. The small caveat is that fields that are
defined in X9.59 and not in ISO8583 are (at least for the mapping
example) are package as purely binary and placed in an ISO8583 message
"addenda" field.
At the financial backend ... for signature verification the original
signed message has to be reconstructed. Since the original encoded
signed format was ASN.1, the bits have to be re-encoded in ASN.1 in
order to do the signature verification.
The FSML version would be to encode the fields in FSML before doing
the digital signature and then at the backend re-encode all the fields
in FSML to do the digital signature.
The X9.59 mapping to ISO8583 for the actual financial transaction
message would be exactly the same whether ASN.1 or FSML was used for
the signature encoding mechanism.
One of the slight twists in FSML compared to XML was that the encoding
rules had to be strictly deterministic i.e. the backend needs to be
able to exactly reconstruct the original signed message bit-for-bit,
in order for the signature to verify. The base XML encoding rules were
not exactly deterministic (things like trailing blanks, leading zeros,
trailing zeros, misc. other things).
X9.59 does include a version number which could be used to indicate
things like additional fields in a message and/or encoding rules for
the original message.
Note, that X9.59 mapped to other environments might not necessarily
used the decomposition process used for mapping X9.59 to ISO8583; aka
the signed message and the transmitted message might be bit-for-bit
the same. It is somewhat a toss-up for the backend. In the X9.59
mapping to ISO8583 example, the bits effectively arrived in un-encoded
format (i.e. already decoded) and must be re-encoded for the signature
verification. In a scenerio where the bits transmitted are the same
as the bits signed, the encoded form arrives at the backend, the
signature can be verified, and then the message decoded in order for
the backend to operate on the fields in the message. Except for the
requirement for strict encoding rules ... there is an encoding
operation replaced with a decoding operation.
a sense of the financial representation in X9.59 can be found in the
mapping from X9.59 to ISO8583 (i.e. ISO8583 defines standard ISO
currency codes, regardless of whether it is ASN.1 encoded or FSML/XML
encoded).
https://www.garlic.com/~lynn/8583flow.htm (from iso8583 field definition)
bit 2 : primary account number, LLVAR, n..19
bit 4 : amount, transaction, n 12
bit 14 : date, expiration, YYMM, n 4
bit 42 : card acceptor identification code, ans 15
bit 49 : currency code, transaction, a 3 or n 3
there has been some investigation that when mapped iso8583, the transaction
amount is limited to twelve digits. This has been identified as a possible
problem given the inflation and currency values in some countries ... that some
reasonably high-value items might exceed 12 digits in some local currencies.
they are promising that the X9.59 standard should be back from the printer any
day now and should show up momentarily on the ANSI/ANS electronic store web
site.
ref:
https://www.garlic.com/~lynn/aepay6.htm#docstore
there are currently no deployed production implementations of X9.59 i.e.
financial processor accepting the X9.59 addenda field in an ISO8583 interchange
message, as well as taging account numbers as valid for use only in
authenticated transactions ... aka the harvasting of account numbers involved
in X9.59 could not be taken and used in fraudulent non-authenticated
transactions.
Ian Grigg on 03/08/2001 09:39:42 AM wrote:
lynn.wheeler@xxxxxxxx wrote:
>
> as an aside, X9.59 financial standard that recently passed (electronic standard
> for all retail payments) also incorporates the message digest of the purchase
> order (or contract) in the body of the payment message.
Right, as an audit trail method. We do that too in the description,
as desired by the application.
We are specifically talking here about the money - the value contract
is hashed and that becomes the money identifier. What does x9.59 use
as its money identifier? An ISO TLA is the most common method, but
I've seen all sorts (4 byte integers, telephone prefixes...) ? FSML
uses it for example. If x9.59 uses ISO TLAs then it doesn't include
a value contract at all, and it will be hamstrung in real finance.
Also, are there any extant implementations of the standard? Any real
transactions?
> as specified in the standard, the payment message encoding format is ASN.1 ...
> however the appendix includes an example in FSML (financial standards markup
> language ... precursor to much of the XML financial related specifications).
Doing the payment in ASN.1 is fine, there is only limited applicability
IMHO to doing it in XML, notwithstanding the intentions of FSML and
others.
> for some fsml related information
>
> http://www.echeck.org/
I printed out the 1.5. The document formatting rules look like a
useful starting point for XML contracts (including the Voucher
work).
The rest of the document seems to be oriented to check processing.
Even though it claims that it might be used for generic documents,
I doubt it, as there are too many assumptions about how checks work
built into it, as well as lots of protocol stuff.
--
iang
implementations of "XML Voucher: Generic Voucher Language" ?
From: Lynn Wheeler
Date: 03/08/2001 01:30 PM
To: ansi-epay@xxxxxxxx
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
note ... as an aside, thread start in another mailing list
... previous message can be seen at:
https://www.garlic.com/~lynn/aadsm5.htm#xmlvch
harvesting of credit card numbers
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/08/2001 05:07 PM
To: ansi-epay@xxxxxxxx
Subject: harvesting of credit card numbers
Large Criminal Hacker Attack on Windows NT E-Banking and E-Commerce
Sites
3:00 PM EST, Thursday, March 8, 2001
In the largest criminal Internet attack to date, a group of Eastern European
hackers has spent a year systematically exploiting known Windows NT
vulnerabilities to steal customer data. More than a million credit cards have
been taken and more than 40 sites have been victimized.
The FBI and Secret Service are taking the unprecedented step of releasing
detailed forensic information from ongoing investigations because of the
importance of the attacks.
shared-secrets, CC#, & harvesting CC#
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/08/2001 07:41 PM
To: ansi-epay@xxxxxxxx
Subject: shared-secrets, CC#, & harvesting CC#
discussions recently on sci.crypt regarding x9.59 being able to effect a
transition from a shared-secret environment to a "secret" environment (i.e.
x9.59 eliminating CC# as harvesting targets)
https://www.garlic.com/~lynn/2001c.html#39
https://www.garlic.com/~lynn/2001c.html#41
https://www.garlic.com/~lynn/2001c.html#42
https://www.garlic.com/~lynn/2001c.html#54
from previous postings on this list regarding probability that large
number of web servers will all operate perfectly (regardless of any
set of security guidelines)
https://www.garlic.com/~lynn/ansiepay.htm#privacy
https://www.garlic.com/~lynn/ansiepay.htm#theory
also
http://lists.commerce.net/archives/ansi-epay/199901/msg00011.html
http://lists.commerce.net/archives/ansi-epay/199904/msg00010.html
http://lists.commerce.net/archives/ansi-epay/200001/msg00007.html
X9.59 available at the ANSI X9 online publication store
From: Lynn Wheeler
Date: 03/08/2001 09:17 PM
To: ansi-epay@xxxxxxxx
Subject: X9.59 available at the ANSI X9 online publication store
x9.59 is now available at the ANSI X9 online publication store:
https://web.archive.org/web/20020214081019/http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9.59-2000
GAO: Government faces obstacles in PKI security adoption
From: Lynn Wheeler
Date: 03/10/2001 08:22 PM
To: ansi-epay@xxxxxxxx, digsig@xxxxxxxx
Subject: GAO: Government faces obstacles in PKI security adoption
GAO: Government faces obstacles in PKI security adoption
By JAIKUMAR VIJAYAN
(March 05, 2001) The federal government needs to overcome several obstacles
before it can implement the public-key infrastructure (PKI) technology needed to
deliver electronic government services effectively and securely, according to a
report released last week by the U.S. General Accounting Office (GAO).
Though these obstacles can be surmounted, doing so will require a lot of
coordination among the different agencies, the report said. And that isn't a
near-term prospect.
Key challenges cited in the GAO-01-277 report include the following:
Meshing incompatible PKI technologies across the different agencies.
Ensuring that PKI implementations can support a large number of users.
Reducing the cost of building PKI systems.
Setting policies that maintain trust levels among different government agencies.
A PKI comprises hardware, software and services that enable the secure and
private exchange of data and transactions over the Internet. The GAO report,
which was commissioned by Rep. Stephen Horn (R-Calif.), details efforts by the
federal government to implement PKI technologies for use in its electronic
initiatives.
Though a growing number of vendors today offer PKI products and services, there
are no common or widely accepted standards for PKI technologies. As a result,
there is little compatibility between PKI products from different vendors.
Therefore, "standards are necessary -- but not sufficient -- to guarantee
interoperability," said Derek E. Brink, who heads the customer advisory council
for one PKI vendor, RSA Security Inc. in Bedford, Mass. Brink is also chairman
of the PKI Forum, an industry group of vendors and users advocating the use of
PKI as an enabler of online business.
"[Interoperability] needs to be described and understood in terms of
component-level, application-level and interdomain interoperability," he said.
The only way to address the issue is by profiling standards and conducting
multivendor interoperability testing, he said.
Developing a governmentwide PKI network will require systems that work
seamlessly with each other across agencies, the GAO report noted.
Also, "since full-featured PKI's are rare, and those that exist are in the early
stages of implementation, it is not yet known how well this technology will
truly scale," the report said.
The high cost of implementing PKI could also be a deterrent for many agencies,
the report cautioned.
Any effective governmentwide PKI implementation program would require
well-defined policies and procedures for installing and monitoring the security
of each agency's system on an ongoing basis.
The Office of Management and Budget, which has statutory responsibility to
develop and oversee policies relating to the security of federal information,
should provide agencies with direction for implementing PKI, the GAO report
recommended. The policy guidance should relate to the use of PKI and to ensuring
that agency PKI implementations meet consistent levels of security, the report
added.
GAO: Government faces obstacles in PKI security adoption
From: Lynn Wheeler
Date: 03/12/2001 11:16 AM
To: ansi-epay@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
as an aside, i was a panelist on a PKI session at NISSC 21
one of the other panelist (last to speak) commented that they were responsible
for the operation of the largest and longest running (CADS-model) PKI.
one of the panelist that spoke first made some comment about all the stuff
you've heard about how hard PKIs really are ... they really aren't
this last panelist opened with something like, all the stuff you've heard about
how hard PKIs really are ... they really aren't; they are much, much worse.
random refs:
http://lists.commerce.net/archives/ansi-epay/199810/msg00006.html
http://csrc.nist.gov/nissc/
http://csrc.nist.gov/nissc/1998/proceeding.html
GAO: Government faces obstacles in PKI security adoption
From: Lynn Wheeler
Date: 03/12/2001 01:32 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: ansi-epay@xxxxxxxx, digsig@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
part of this was when I was working on the original payment gateway:
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
https://www.garlic.com/~lynn/aadsm5.htm#asrn1
using a precursor to SSL3 ... I quickly realized that while the two parties had
to do mutual authentication ... the certificates that passed during protocol
negotiations were redundant and superfluous. The merchant had an "account entry"
that gave the authentication information for the merchant processor that it did
business with ... and the merchant processor had real-time "account record" for
each merchant. The certificates were just an artificial artifact of the
underlying code that was being used and other than that didn't contribute at all
to the process.
https://www.garlic.com/~lynn/2001.html#8
https://www.garlic.com/~lynn/2001.html#9
"Anders Rundgren" on 03/12/2001 11:13:09 AM wrote:
By doing that the "PKI-interface" between organizations will be
limited to a server-based organization certficate ("digital company
paper") which scales several orders of magnitude better than the X500
approach. PKI has AFAIK, commercially and technically failed for
global use except for Web-server-certificates which speaks for itself.
There is only one weakness: This is extremely politically incorrect as
the general belief is that PKI must follow the original model...
GAO: Government faces obstacles in PKI security adoption
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/12/2001 08:02 PM
To: ansi-epay@xxxxxxxx
Subject: Re: GAO: Government faces obstacles in PKI security adoption
original (certificate) design point was many-to-many in an offline
environm4ent.... i.e. offline email. the analogy would be letters of credit in
the days of sailing ships or the business checks with "signing" .limit. It would
have also made sense if the credit card industry had gone from offline paper
(all of those paper CRL booklets in the 60s) to offline electronic; however the
credit card industry jumped from offline paper to online electronic and bypassed
the need for TTP offline electronic credential.
The "signing" limit checks found that with a $5000 limit ... people
could still sign 200 $5000 checks to make a $1m transaction .... this
pretty much jumped from offline paper to online electronic also. Many
times the "signing" limit check is now a business card (a special kind
of credit card) that has a lot more rules than just maximum credit
limit; things like transaction limit at different stores, different
limits on which vendors or even which stores ... also rules about SKU
codes (i.e. what kind of things that can be purchased, etc).
The many-to-many scenerio for certificates is the offline electronic
.... i.e. the original design point for offline email.
It can even be shown that the existing sort-of many-to-many scenerio
... i.e. SSL merchant domain name certificates (SSL merchant domain
name certificates probably represent 99.999999% of the certificates
server authentication events in the world today) is something of an
aberration that become redundant and superfluous with some simple
(necessary) upgrades to DNS. As mentioned in some of the prior (URL)
refs, one of the justifications for SSL merchant certificates is
concern regarding domain name infrastructure. However, who does a CA
go to as the authoritative agency for SSL merchant domain name?
... the domain name infrastructure (the infrastructure that concern
about justifies SSL merchant domain name certificates in the first
place). Simple proposal to "fix" the domain name infrastructure so
that CA's can rely on them when validating requests for SSL merchant
domain name certificates is to have merchants register a public key
with the domain name infrastructure when they register their domain
name. Now if the domain name infrastructure was fixed so that CA's
could rely on them for validating information that goes into creating
SSL merchant domain name certificates ... then that should alleviate
many of the concerns that drive people to get SSL merchant domain name
certificates. Furthermore, if a public key distribution is really
needed, then a "trusted" domain name infrastructure with registered
public keys could distribute them at the same time that they are doing
IP name resolution (i.e. an online electronic infrastructure that has
to be used in the internet environment in any case).
The "fix" to create a trusted domain name infrastructure so that CAs
could rely on it as part of the domain name certificate issuing
process ... also eliminates the requirement to issue domain name
certificates.... as well as providing an trusted online mechanism for
distributing public keys (if there is a requirement).
Anders Rundgren on 03/12/2001 02:30:10 PM writes:
Lynn,
In many-2-many situation certificates fill a need.
Also, if keys are to be renewed unilateraly certs supports that transparently.
AADS makes sense between a client and his/her bank but not between a client
a many RP's.
Client certs between organizations like in SET 1.0 is useless.
SET 3D OTOH reduces certs to one per FI which is great.
Anders
best ketp secrets of money(?)
From: Lynn Wheeler
Date: 03/16/2001 06:05 PM
To: ansi-epay@xxxxxxxx
Subject: best ketp secrets of money(?)
somebody watching the following show
http://tlc.discovery.com/schedule/episode.jsp?episode=551504005
claims they saw a smartcard with the letters AADS on it.
7th CACR Information Security Workshop
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/19/2001 03:55 PM
To: ansi-epay@xxxxxxxx
Subject: 7th CACR Information Security Workshop
possibly of some interest. I missed talking very much about chips at
the intel's developer's conference
random ref:
https://www.garlic.com/~lynn/aadsm5.htm#asrn1
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
==================================================
7th CACR Information Security Workshop
Smart Cards: Technology, Applications and Security
University of Waterloo, Canada
==================================================
This is the second announcement. Please pass this announcement to any
colleagues who might be interested in attending. Please note the
March 27 cut off date for hotel accommodations.
For updates, including the program, abstract of talks and speaker
bios, please see www.cacr.math.uwaterloo.ca under "Conferences".
April 25, 2001
9:00 am - 4:00 pm
The Sheraton Reston Hotel, 11810 Sunrise Valley Drive, Reston, Virginia
THEME:
The 7th CACR Information Security Workshop, titled Smart Cards:
Technology, Applications and Security, will be held on Wednesday,
April 25, 2001 at the Sheraton Reston, Reston, Virginia and hosted by
Certicom Corp. Topics that will be covered include:
- State of the Industry - who are the players, who are the
customers, what are the applications, what are the issues for
wide scale deployment
- Latest in smart card technology such as multi application
operating systems, processors, etc.
- Update on active and passive security attacks such as DPA, fault analysis,
etc and the latest and best means to counter these attacks
- Information Assurance
- Applications such as financial, transportation, and health care
- Integration of biometrics, encryption and smart cards
With the mobility that we have today with anywhere, anytime access to
myriad applications via the wired and wireless Internet and Intranets,
smart cards provide a perfect form factor for storing individual
user's private information such as digital certificates, public and
private keys, and health care and financial details, and for
processing financial and other transactions.
The series of Information Security Workshops is organized by the
University of Waterloo's CACR (Centre for Applied Cryptographic
Research) (url: www.cacr.math.uwaterloo.ca) and has been established
to provide a highly focused and content full program covering topics
of interest to the sponsors' customers, potential customers and
employees. The targeted attendee is an individual with a solid
background in information security, with two plus years of experience
in developing or deploying information security solutions for
electronic commerce or other applications. This individual understands
some of the issues and challenges (short term and long term) in this
area and attends the workshop in order to gain exposure to different
approaches (including specific vendor's approaches) or technology and
understand the availability of such, thereby expanding the "tools" in
his or her respective tool box.
This workshop is the 7th in the series. Agendas and presentations from
previous workshops can be found at www.cacr.math.uwaterloo.ca under
conferences.
SPONSORS:
- Certicom Corp.
- MasterCard International
- MITACS
- Mondex International Limited
- Pitney Bowes
ORGANIZERS:
- Alfred Menezes
Centre for Applied Cryptographic Research (CACR)
University of Waterloo
- Sherry Shannon
Centre for Applied Cryptographic Research (CACR)
and SVI Consulting Ltd.
- Chris Fader
University of Waterloo and SVI Consulting Ltd.
WORKSHOP PROGRAM (tentative):
April 25, 2001 (Wednesday)
8:30 - 9:00 Registration/Continental Breakfast
9:00 - 9:10 Welcome Certicom Corp. and CACR
9:10 - 10:40 Smart Card Industry Overview
Panel - State of the Smart Card Industry,
Moderated by Steve Howard, Certicom,
Panelist include Charles Cagliostro, Executive Director,
Smart Card Digital Security Initiative of the Smart Card Alliance;
John Moore, GSA, Chair, Federal Smart Card User Group;
and others to be confirmed.
10:40 - 11:00 Coffee Break
11:00 - 12:00 Multi-Application Vulnerabilities and Security Update
11:00 - 11:30 The Vulnerabilities of Multi-Application Systems,
TBD
11:30 - 12:00 Electromagnetic attacks on smart cards,
Jean-Marc Robert, Gemplus
12:00 - 1:30 Buffet lunch provided at the 57th Street Grill, Sheraton Reston
1:30 -- 2:30 Hardware Advances
1:30 - 2:00 Nimbus: An Atmel and ARM collaboration,
Julie Krueger, Atmel
2:00 - 2:30 TBD
2:30 - 2:50 Coffee Break
2:50 - 3:50 Information Assurance
2:50 - 3:20 Title to be determined,
Steve Haynes, PriceWaterhouseCoopers
3:20 - 3:50 Title to be determined,
Perry Luzwick, Logicon
3:50 - 4:00 Wrap Up CACR
REGISTRATION
There is no registration fee for guests invited by the sponsors
(Certicom, MasterCard, MITACS, Mondex, and Pitney Bowes).
The registration fee for other participants is as follows:
- CAD $400 (USD $200).
- For participants affiliated with an academic institution:
CAD $100 (USD $50).
Please register as soon as possible as space is limited for this
workshop; registration is on a first-come first-serve basis.
To register, complete, in full, the attached REGISTRATION FORM and
return it along with your payment (if applicable) to:
Mrs. Frances Hannigan,
C&O Dept.,
University of Waterloo,
Waterloo, Ontario, Canada N2L 3G1.
You may also register by email (fhannigan@xxxxxxxx)
or by phone (Frances Hannigan: 519-888-4027).
------------------------cut from here---------------------------------
7th CACR INFORMATION SECURITY WORKSHOP REGISTRATION FORM
Full name:
_________________________________________________________
Affiliation:
_________________________________________________________
Address:
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________
_________________________________________________________
E-Mail Address:
_________________________________________________________
Telephone #:
_________________________________________________________
Make Cheque/Money Order Payable in
CAD or USD funds only to: CACR
Credit Card Payments:
[ ] Visa [ ] MasterCard
Cardholder's Name: _________________________________________________
Card Number: _______________________________________________________
Expiration Date: ___________________________________________________
Signature: _________________________________________________________
-------------------------cut from here-------------------------------
ACCOMMODATIONS:
The workshop will be held at The Sheraton Reston Hotel, 11810 Sunrise
Valley Drive, Reston, Virginia
A block of hotel rooms (under the name CACR) has been set aside for
Tuesday, April 24 at the Sheraton Reston at the rate of $229.00 US
plus tax. Please make your reservations directly with the hotel by
calling (703) 620 9000 or 1 800 392-7666 prior to the cutoff date of
March 27, 2001. All reservations must be guaranteed and accompanied
by a first night room deposit or guaranteed with a major credit card.
Individual cancellations not made by 6:00 pm the day prior to arrival
will result in a charge of one night's room and tax to the guest's
credit card. No-shows will be charged.
Transportation is provided to and from the Dulles Airport. Please
use the hotel telephone in the baggage claim area to call the
Sheraton Reston. The Sheraton Reston courtesy bus picks up every
half an hour at the designated place. Please note that there are two
Sheraton hotels near the airport and each hotel operates its own
courtesy bus. Please make sure that you board the correct bus.
-----------------------------------------------------------------------
TRAVEL:
The closest airport is Dulles Washington DC Airport
-----------------------------------------------------------------------
For further information please contact:
Mrs. Frances Hannigan
Department of Combinatorics & Optimization
University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
e-mail: fhannigan@xxxxxxxx
Fax: (519) 725-5441
Phone: (519) 888-4027
http://www.cacr.math.uwaterloo.ca/
-----------------------------------------------------------------------
Frances Hannigan
Editorial Assistant/CACR Administrative Assistant
Dept. of Combinatorics & Optimization
Faculty of Mathematics
University of Waterloo
Waterloo, Ontario N2L 3G1
Ph: (519) 888-4027, MC 5027
Fax: (519) 725-5441
Email: fhanniga@xxxxxxxx
Web-site: www.cacr.math.uwaterloo.ca
7th CACR Information Security Workshop
From: Lynn Wheeler
Date: 03/22/2001 10:30
To: ansi-epay@xxxxxxxx
Subject: re: 7th CACR Information Security Workshop
oops ...
> https://www.garlic.com/~lynn/aadsm5.htm#asrn1
> https://www.garlic.com/~lynn/aadsm5.htm#asrn4
that should have been
https://www.garlic.com/~lynn/aadsm5.htm#asrn1
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
assurance, X9.59, etc
From: Lynn Wheeler
Date: 03/22/2001 05:10 PM
To: dcsb@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: assurance, X9.59, etc
with respect to
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
and the SRI contention that software assurance could learn a lot from
hardware design ....
the logic simulator machine mentioned in
https://www.garlic.com/~lynn/2001c.htm#69
was called the LSM or los gatos state machine and was used for
validating chip designs.
This was one of the original such hardware verification engines for
chip designs and had some unique features like a timer. Many of the
subsequent hardware verification engines (as well as software
verification tools) assumed a synchronous chip and so when things
stepped ... every thing stepped in unison (and therefor didn't need to
implement a timer function in the tool)
The LSM timer was useful for verifying chips that incorporated analog
circuits in a digital chip and/or digital chips that didn't have a
single uniform synchronous clock. Note that the Los Gatos VLSI lab
(where the LSM was developed) was associated with the San Jose disk
engineering plant ... where thin film heads were developed
(i.e. digital chip with analog circuits).
also in the above, specifically with respect to the high speed backbone (secure,
high-speed network)
https://www.garlic.com/~lynn/internet.htm#0
Lynn.Wheeler@xxxxxxxx on 02/28/2001 10:24:23 AM wrote:
sri speaker said that current level of assurance technology was very primitive
... that the chip industry has much more sophisticated tools for testing for
correctness and test coverage and that software could learn a lot from chip
design industry
Digital Signatures Spark Debate
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/14/2001 02:42 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: t.c.jones@xxxxxxxx, epay <ansi-epay@xxxxxxxx>
Subject:Re: Digital Signatures Spark Debate
note that banks have migrated to relying-party-only certificates ... for
both liability as well as privacy reasons (a generalized "identity"
certificate can represent a significant amount of unnecessary and/or
unwanted privacy information for the majority of transactions ...
especially in the consumer arena).
as a result there has been some amount of personal digital signatures
without reguiring any identity information to be divulged, i.e. privacy
invasive identity certificates welded to the end of every transaction).
that was part of X9.59 financial standard (i.e. the work product of this
X9A10 working group .... which this mailing list was set up as part of
X9A10 ) to be privacy neutral ... and not mandate privacy invasive identity
certificates welded on the end of every transaction).
https://www.garlic.com/~lynn/aepay6.htm#x959dstu
https://www.garlic.com/~lynn/aepay6.htm#x959pub
some related discussion recently in comp.security.unix
https://www.garlic.com/~lynn/2001e.html#26
https://www.garlic.com/~lynn/2001e.html#27
https://www.garlic.com/~lynn/2001e.html#33
https://www.garlic.com/~lynn/2001e.html#35
https://www.garlic.com/~lynn/2001e.html#36
https://www.garlic.com/~lynn/2001e.html#37
https://www.garlic.com/~lynn/2001e.html#39
https://www.garlic.com/~lynn/2001e.html#40
https://www.garlic.com/~lynn/2001e.html#43
https://www.garlic.com/~lynn/2001e.html#46
https://www.garlic.com/~lynn/2001e.html#49
misc other
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
also:
a good friend introduced the concept of VPN at the router committee meeting
during the fall '94 IETF meeting in San Jose. We had been familiar with
his work prior to that event.
Up until that time, IPSEC was going to be end-to-end network layer security
(authentication and privacy). Eventually things got re-organized into
heavy-weight end-to-end IPSEC and subnet-to-subnet light-weight (aka VPN)
IPSEC.
Since that time, it has also evolved into personal VPNs (i.e. end-node PC
client talking through the internet to a real router/gateway VPN, likely at
some gateway between the internet and the corporate intranet). as an aside,
our friend also was one of the first to introduce the idea of personal
VPNs. These personal VPNs can provide PC-to-subnet authentication and
privacy.
One of the downsides that some of the personal VPNs overlook is the use of
the PC as a backdoor into the corporate intranet. For a long time there has
been a real serious battle in corporation with PCs attached to the
corporate intranet and also allowed to have a dial-up modem (frequently
used by the employee to access their private internet account). Those PCs
have represented a clear-channel backdoor between the dial-up intranet
connection and the corporate intranet.
However, by definition, personal VPNs represent the same exact threat. They
have a clear-channel into the internet which allows generalized traffic to
flow back in forth. In addition, the VPN can create an encrypted tunnel
through the internet into the corporate intranet. An employee's home PC
with a modem dialed up to the internet is directly the same as his office
PC being allowed to have a modem dialed to the internet. At the TCP/IP
protocol stack, the PC sees effectively no protocol difference between a
office PC also directly attached to a corporate LAN/intranet and a personal
VPN software creating a virtual connection to the corporate LAN/intranet.
The same backdoor and viruses work in both cases.
at:
https://www.garlic.com/~lynn/rfcietff.htm
it is possible to select the "term" index and then select IPSEC and/or VPN
for the IETF RFCs related to the two subjects.
IP security protocol (ipsec)
see also security
2983 2888 2857 2709 2628 2451 2411 2410 2409 2407 2406 2405
2404 2403 2402 2401 2367 2207 2202 1829 1828 1827 1826 1825
virtual private network (VPN)
see also encapsulate , security
2917 2857 2764 2735 2685 2547 2451 2406 2405 2404 2403 2340
1851 1829 1827
Anders Rundgren on 05/14/2001 11:59:38 AM writes:
Interesting article,
May I add another even larger piece on the table? Digital signatures comes
in different flavors, one which is personal and one which is
machine-generated (server).
In Europe the general belief is that personal signatures is the important
one.
I disagree as noted in the article the health-care industry rely on EDI
through VPN or leased lines. Over the Internet you can achive the same
security by using server-signed EDI (or other) messages. This is techically
and deployment-wise very simple.
A major drawback with personal signatures is that people's identities come
to places they have no control of. And the globally interoperable employee
- CA does not even seem to be an issue in the private sector.
So my bet is that "healthy" path for the health-industry is to start with
organisation/server signatures before going too fast on the personal
signature path. In Europe this will surely be based on mobile phones
rather than smart cards etc.
Anders Rundgren
Announce: Eric Hughes giving Stanford EE380 talk this
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/14/2001 04:34 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx,
ansi-epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
Having been involved somewhat in the first round of electronic
commerce i.e. my wife and I worked with a small client/server started
in the valley on getting the server to point that they could do
financial transactions. The small startup went on to change its name
from Mosaic to Netscape
random ref:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
we didn't find doing it the first time as so hard ... it was getting
the next round to displace the first round.
We both worked on financial industry's X9.59 standard for all
electronic account-based payments (POS, internet, etc).
One of its characteristics was that it introduced the business concept
of authenticated transactions and authenticated transactions account
numbers (i.e. account numbers that can only be used in authenticated
transactions). One of the side-effects of this was that it eliminates
account numbers as shared-secrets (i.e. the requirement that
merchants & others keep the master account-number database at the very
most highest security and absolutely never make a mistake in order to
prevent the harvesting of account numbers that can be used in
unauthenticated fraudulant transactions).
I was one of the speakers at the NASA/CMU dependable computing
workshop last week and besides talking about several long known issues
... also talked about authentication as a component of dependability
(as well as x9.59 for dependable financial transactions ... transition
eliminating account numbers as a shared-secret vulnerability).
random refs:
https://www.garlic.com/~lynn/aepay6.htm#x959dstu
https://www.garlic.com/~lynn/aepay6.htm#x959pub
https://www.garlic.com/~lynn/2001e.html#41
"R. A. Hettinga" on 05/14/2001 02:45:04 PM writes:
To: cypherpunks@xxxxxxxx
Subject: CDR: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
From: Eric Hughes (yes, _that_ EH) <eh@xxxxxxxx>
Date: Mon, 14 May 2001 09:26:52 -0700
All:
In discussions at the Bay Area cypherpunks meeting last Saturday, I
was repeatedly asked to forward an announcement. I will be giving the
Stanford EE380 colloquium talk this Wednesday, May 16, 2001. The
course URL is thus:
http://www.stanford.edu/class/ee380/
The title of the talk is "Design for Commercial Reliance". The theme
is a particular reason why innovation in commercial transaction
systems is difficult. With the recent sale of the remaining assets of
Cybercash to First Data Merchant Services and VeriSign, the initial
wave of digital cash businesses is now fully over. The score was 0/3
(Cybercash, First Virtual, DigiCash).
I believe it is instructive to see that the predominant payment system
used over the internet (internet payment order initiation) is the
credit card system for consumer and the ACH (checks) system for
businesses. The internet has been applied to the delivery channel,
but the underlying financial mechanisms remain identical. These
internet use of these systems has been deeply conservative. Even the
only even moderately-successful "alternate" system, Paypal, still uses
no new transfer mechanism.
New payment systems are an awful business. They're low margin (they
have to be, to meet the competition), so they have to be high volume
to succeed. Getting to high volume has lousy financial properties.
The "bathtub curve" is long and deeper than you'd like. You have to
finance not only the NRE (non-recoverable engineering) costs,
including data center build-out, but also a few years of operating
costs before you hit volume. Let's just assume you've got the
financing in place and also realistically patient financiers who are
not dupes. You have five years to break-even from launch, say.
Now you have to do everything possible to ensure that your system has
rapid uptake. It has been proven by demonstration at this point (see
scoreboard above) that press coverage and cheerleading are
insufficient. It doesn't matter how much "RAH! RAH! Go Team!" there
is. Wishing doesn't make it so.
Certainly you need brand. Without being able to quickly communicate
what the service is about, you won't get rapid uptake, even in the
business market. So let's assume your financiers have stumped up for
advertising and other brand-building activities. You'll also need
differentiation, because otherwise why not just use a check or credit
card? Let's assume that, too. (The first wave of internet companies
had adequate brand and differentiation.)
My claim is that you're still not done. I'll be talking about a basic
design failure that would kill uptake or slow it sufficiently that any
new venture would still fail, even having done most everything else
right.
Eric
Announce: Eric Hughes giving Stanford EE380 talk this
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/15/2001 11:13 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>,
Digital Bearer Settlement List <dbs@xxxxxxxx>,
dcsb@xxxxxxxx, ansi-epay@xxxxxxxx,
internet-payments@xxxxxxxx
Subject: Re: Announce: Eric Hughes giving Stanford EE380 talk this
Wednesday May 16, 2001
... slightly different slant on "commercial transaction systems"
.... slightly more related to industrial strength data processing in
transaction systems (although the first ref in following list is
specifically with respect to one of the large financial transaction
systems).
random ref:
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/2001e.html#4
https://www.garlic.com/~lynn/2001e.html#2
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/2001d.html#69
"R. A. Hettinga" on 05/14/2001 02:45:04 PM writes:
The title of the talk is "Design for Commercial Reliance". The theme is a
particular reason why innovation in commercial transaction systems is
difficult. With the recent sale of the remaining assets of Cybercash to
First Data Merchant Services and VeriSign, the initial wave of digital cash
businesses is now fully over. The score was 0/3 (Cybercash, First Virtual,
DigiCash).
do CRL's actually work?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2001 12:45 PM
To: t.c.jones@xxxxxxxx
cc: ansi-epay@xxxxxxxx
Subject: Re: do CRL's actually work?
note that certificates were originally targeted for offline
environment (i.e. not being able to reference the information ... as
in the case for DNS IP-address real-time lookup) ... specifically
offline email.
originally CRLs were targeted at being broadcast to the relying-party
clients to provide more timely information as to certificate status
(nominal case, offline email distributed to the set of relying-parties
for offline email authentication). as the size of some of the
relying-party communities started to get very large it became less and
less practical to broadcast CRLs to everybody in a community (recent
discussion of broadcasting to possibly 100 million SSL clients in the
world that might be relying-party for SSL domain name server
certifices).
The alternative to broadcast/push for CRL became a online query/pull
model. So for business critical certificates where timely status is
important ... but a paradigm targeted for the offline environment
then needed to layer an online query paradigm on-top of the
infrastructure targeted at working in an offline environment .... aka
the certificates represent a R/O, distributed (possibly stale) copy of
the informaton contained in a (account) database record at the
certification authority. These R/O, distributed copies of database
records at the certification authority provide access to certified
information when the relying-party is in an offline environment and
has no access to the certification authority information.
Layering an online protocol (CRL and/or certificate real-time
information access) on-top of the certificate offline paradigm
basically negates original assumptions and design point that went into
the reasons that certificates were invented in the first play.
Given an "online" design point/requirement ... then authentication
information (like public keys) can be distributed by a trusted party
in much the same way that the domain name infrastructure distributes
IP-addresses, i.e. rather than trying to contort an offline
authentication solution into addressing online authentication
requirements (by layering online, timely information access on top of
stale, offline information copy paradigm); just use an online
authentication solution for addressing online authentication
requirements.
The comparison is especially apparent in the SSL domain name server
certificate scenerios. The domain name infrastructure already provides
for timely, query/pull model distribution of IP-addresses. The domain
name infrastructure is also the final authoratative agency as to who
owns a domain name. Nominally, for a certification authority to issue
an SSL domain name server certificate, the certification authority has
to verify with the domain name infrastructure that the entity
requesting the domain name certificate is in fact the entity that owns
the domain; aka in general, a certificate authority has to resort to
checking with the authoritative agency associated with the information
that the certification authority is "certifying" (in the case of SSL
domain name server certificates, the domain name infrastructure is the
authoratative agency as to the owners of domain names).
The domain name infrastructure shows that timely, query/pull
information distribution can be operated on a large scale. In fact,
something akin to the domain name infrastructure implementation could
be used to deploy support for scalable CRL operation. However, that is
placing an online "fix-up" layer on top of a fundamental offline
information distribution solution. For an online environment, it is
also possible to show that the domain name infrastructure
implementation could be used to address not only the CRL issue but
also the certificate stale, static information issue (rather than needing to
make availabe timely status information about offline stale, static
information, just make available the timely information directly).
random ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
t.c.jones@xxxxxxxx on 05/16/2001 09:55:40 AM wrote:
read this
http://amug.org/~glguerin/opinion/revocation.html
Electronic Commerce Modeling Language
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2001 03:06 PM
To: ansi-epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language
Of possibly some interest to X9A and/or TC68
This is going forward as an IETF Informational RFC ... fyi
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Open Trading Protocol Working
Group of the IETF.
Title : Electronic Commerce Modeling Language (ECML):
Version 2 Requirements
Author(s) : J. Parsons, D. Shepherd, D. Eastlake
Filename : draft-ietf-trade-ecml2-req-02.txt
Pages : 10
Date : 08-May-01
This document lists the design principles, scope, and requirements for the
Electronic Commerce Modeling Language (ECML) version 2 specification. It
includes requirements as they relate to XML syntax, data model, format,
payment processing, and external requirements.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-req-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After logging
in, type "cd internet-drafts" and then
"get draft-ietf-trade-ecml2-req-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
AADS NWI closed two years ago today
From: Lynn Wheeler
Date: 05/20/2001 01:30:54 PM
To: ansi-epay@xxxxxxxx
Subject: AADS NWI closed two years ago today
random ref:
https://www.garlic.com/~lynn/aepay3.htm#aadsnwi
latest credit scam puts plastic in peril ... is your credit card being cloned?
From: Lynn Wheeler
Date: 05/21/2001 09:16:40 PM
To: ansi-epay@xxxxxxxx
Subject: latest credit scam puts plastic in peril ... is your credit card being cloned?
http://abcnews.go.com/sections/business/DailyNews/creditcardfraud_010521.html
use of digital signatures and PKI
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/04/2001 08:36
To: ansi-epay@xxxxxxxx
Subject: use of digital signatures and PKI
note this is similar to the "merchant comfort certificates" that ran here
last year
https://www.garlic.com/~lynn/aepay4.htm
also
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
Gcza Zoltn on Thu, 31 May 2001 19:18:30 wrote:
Hi!
I have just read Jane K. Winn's paper, "The Emperor's New Clothes: The
Shocking Truth About Digital Signatures and Internet Commerce".
As far as I can remember, it was mentioned on the list.
I wonder if you could make any comments whether digital signatures are
really NOT used worldwide as the paper states! Unfortunately I could not
find any research or survey. Any reference would be greatly appreciated
Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi
From: Lynn Wheeler
Date: 06/04/2001 08:25 AM
To: ansi-epay@xxxxxxxx
Subject: Problem with the (lingering) death of x.509 PKI ... forwarded ... fyi
"Carl Ellison" on 31 May 2001 07:56:24 wrote:
One of the problems we face with the lingering demise of X.509 PKI is that
the three letter acronym "PKI" is being given a very bad name. I had one
product consultant tell me a few months ago that we should never include
those letters in anything we're trying to sell from now on.
Since SPKI has those three letters in its name, we may need a new name....
At Intel, we're calling it "relationship management".
That's big and English, not an acronym. Suggestions anyone?
- Carl
use of digital signatures and PKI
From: Lynn Wheeler
Date: 06/06/2001 10:43 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: goczaz@xxxxxxxx, Anders Ekström <anders.ekstrom@xxxxxxxx>,
ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI
actually ... it isn't just a case of trust anchors .... which is much
more of a technical concept; part of the issue is the whole idea of
the business of depending on very obscure trust relationships provided
by other parties ... including, potentially trust values that are
totally orthongonal to a relying party's trust requirements
the other issue is that certificate design point is really a piece of
R/O copy of distributed information along with some integrity
characteristics that was originally targeted for an offline
environment (i.e. where the relying party didn't have online access to
the original source of the information). It isn't that certs couldn't
do what they were originally targeted for doing ... but many of the
value propositions for certs that have been attempted over the past
couple years involved environments that basically voilated all their
original design assumptions.
the SSL server PKI infrastructure is a reasonably good example (even
tho the infrastructure is primarily used for encryption not
authentication) ...
random ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
Anders Rundgren on 06/04/2001 08:41:33 AM wrote:
Hi Gcza,
I think that the article is correct in the sense that digital
signatures are currently not widely deployed. That this is due to
impossible-to-accept deficiencies in the underlying idea and
technology is (in my opinion) not the case, it is rather the overly
complicated trust models that particularly the governments try to
apply to PKI. I.e
use of digital signatures and PKI (addenda)
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/06/2001 10:43 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: goczaz@xxxxxxxx, Anders Ekström <anders.ekstrom@xxxxxxxx>,
ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI (addenda)
... trust should effectively be the same regardless of the technology
that is used to deliver that trust.
that is a certification authority that validates/certifies some
information .... in theory the level/value of the trust should be the
same whether a relying parties directly does an online query to the
certification authority ... or relies on a R/O distributed
(potentially stale) copy of that some information (embodied in a
certificate) that a relying party can depend upon when there is no
online access to the same information.
so doing the SSL server certificate scenerio ... in the online "trust"
model.
we have a small technology startup someplace with an online database
that is effectively copied/validated with the domain name
infrastructure. an end user does an online query with the domain name
infrastructure and then does a 2nd online query to the SSL
certification authority to see if the direct response that the user
received from the domain name infrastructure is the same as the online
query response from the certification authority (i.e. is the domain
name infrastructure online response the same as the SSL certification
authority online response ...based on the SSL certification
authorities copy of the domain name infrastructure database). That is
the same basic "trust" ... but in terms of an online implementation
that is done today using stale, static copies (aka certificates) of the
certification authorities database (which is basically a copy of the
domain name authorities database).
... another relatively recent certificate-based incarnation example
... we have a small technology startup someplace with an online
database that is a copy of a bank's account database. the bank
receives an online transaction ... does it
1) validate using the stale, static copy of information (aka certificate)
from the technology startup which in turn is based on a stale, static copy of
the bank's account database?
2) validate by doing an online query to the technology startup
checking the technology startup's database (which is a stale, static copy of
the bank's online database?
3) validate directly using the banks real-time online database?
The issue of trust and certification should "work" totally
independantly of whether the technology to deploy that trust is an
online query to a real-time database ... or via offline dependance on
an offline stale, static copy (aka certificate) of the same information
(modulo potentially how stale the R/O copy might become).
The issue of whether an online or offline implementation is deployed
... and/or whether an online or offline solution is used ... should
be based on the target environment ... not based on the trust (aka the
trust scenerio should work effectively the same regardless of whether
it is offline ... with online queries ... or offline ... with R/O
stale certificates).
If it makes sense for a bank to depend on a 3rd party's certificate
representing information already in the banks database ... then it
should make equal sense for a bank to do online queries to that 3rd
party's online copy of the bank's database ... rather than doing the
online query against the banks own original database (the difference
isn't an issue of trust the difference is whether the bank is
operating in an offline or an online environemnt).
Entrust To Cut 400 Jobs .... fyi
From: Lynn Wheeler
Date: 06/06/2001 10:44 AM
To: ansi-epay@xxxxxxxx
Subject: Entrust To Cut 400 Jobs .... fyi
http://www.nytimes.com/2001/06/05/technology/05TBRF.html
ENTRUST TO CUT 400 JOBS
Entrust, a struggling Internet- security company, said yesterday that
it would cut 400 jobs - 30 percent of its work force - and close some
offices. The company said it would take a $400 million charge in the
second quarter to cover the costs of severance packages, office
closings and other items. The company, based in Plano, Tex., also
changed its name, which had been Entrust Technologies. Entrust was
spun off from Nortel Networks in 1997.
problem with the death of X.509 PKI (forwarded)
From: Lynn Wheeler
Date: 06/06/2001 10:44 AM
To: ansi-epay@xxxxxxxx
Subject: Re: problem with the death of X.509 PKI (forwarded)
the other trust scenerio ... continuing posting on the digital
signature thread ...
Maintaining the trust constant but comparing the migration from
offline to online ... is bank issued credit cards in the '50s/'60s
where the credit cards were offline "credentials/certificates" that
had names and numbers. The plastic was supposedly hard to counterfiet
and contained "name" so that merchant could cross-check with other
forms of identification (see if name is the same on a driver's
license). They could also check the account number against the montly
paper "revokation list".
A magstrip was added to the plastic form factor ... so it could be
used in electronic online transactions (totally skipping over offline
electronic ... which is where the current CA/PKI paradigm design point
was targeted for). The electronic online transaction not only had the
benefit of being able to do real-time revokation checking ... some
simple authentication ... as well as real-time credit limit ... as
well as multiple transaction patterns (not only aggregation of money
but aggregation of number and types of transactions).
use of digital signatures and PKI (addenda)
From: Lynn Wheeler
Date: 06/06/2001 10:45 AM
To: Carl Ellison <cme@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, goczaz@xxxxxxxx,
Anders Ekström <anders.ekstrom@xxxxxxxx>,
ansi-epay@xxxxxxxx, cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI (addenda)
electronic financial transactions are operating online already ... i
was being somewhat facetious .... but in the past these online
electronic financial transactions have been one of the major targets
for offline certificate application.
I was trying to separate/contrast between 3rd party certification
(whether the service is online or offline via certificates) and online
versis offline certificates (whether it is relying party or 3rd
party). In theory, 3rd party certification should be able to be
examined independent of the technology/paradigm (i.e. online &
offline/certificates) used to deliver the certification ... and
online/offline paradigm should be able to be examined independent of
relying party & 3rd party certification.
"Carl Ellison" on 06/06/2001 01:48:04 AM wrote:
At 10:20 AM 6/5/01 -0700, Lynn.Wheeler@xxxxxxxx wrote:
>If it makes sense for a bank to depend on a 3rd party's certificate
>representing information already in the banks database ... then it should
>make equal sense for a bank to do online queries to that 3rd party's
online
>copy of the bank's database ... rather than doing the online query against
>the banks own original database (the difference isn't an issue of trust
the
>difference is whether the bank is operating in an offline or an online
>environemnt).
Lynn,
I thought the beauty of X9.59 was that banks are all operating
online already, thanks to EFT and credit card processing, so there's
no reason to dilute security by having any third party involved in the
authorization process. Did I miss something?
- Carl
use of digital signatures and PKI (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/06/2001 10:32:16 AM
To: Carl Ellison <cme@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, goczaz@xxxxxxxx,
Anders Ekström <anders.ekstrom@xxxxxxxx>, ansi-epay@xxxxxxxx,
cme@xxxxxxxx
Subject: Re: use of digital signatures and PKI (addenda)
there are sort of two kinds of online financial transactions that go
on the internet today .... the standard (essentially unauthenticated)
credit card fincnail transaction (which turns credit card number into
a shared-secret) and "one dollar 'auths'".
standard "moto" (mail order/telephone order) credit card transaction
have typically included "address verification" (i.e. check to see if
the customer's address the same as the credit card billing address).
several elements (including some certification authorities) in the
internet today are taking advantage of online AVS transactions to do a
form of online authentication. One form is a one dollar credit card
authorization with AVS (i.e. verify correct credit card number, name,
& address) ... but never do an actual funds transfer (i.e. the
one dollar auth never actually shows up on the credit card bill).
They then make the assumption that since all that information is
correct ... they are dealing with a valid credit card customer that
signed a valid contract (and in some circumstances since to sign a
valid contract you have to be an adult ... they then make the
conclusion that the person is also an adult).
The merchant is charged additonal for an AVS transaction ... so this
takes a form of online authentication plus being charged per
authentication event. However, most internet operations that take
advantage of this AVS transaction feature ... are then recording the
information and relying on the recording (and not repeating the
transaction) for future use. In some cases, the "merchant" then turns
around and provides an "online transaction" authentication mechanism
for other entities on the internet (i.e. they charge other internet
entities a fee for online access the "AVS transaction" information
that they have cached; these entities caching AVS transaction
information seemed to be totally unrelated to the financial
institutions that provide the basic AVS support).
The Certification Authorities that are using the AVS feature ... are
frequently doing it as part of a credit card charge. They may be
charging a user $10 or more (on their credit card) for manufacturing a
certificate using the information "authenticated" by the AVS
transaction aka ... a $10 or greater fee to a user for munging the
bits that the user provides into ASN.1 encoding ... after including
the AVS information with the $10 charge against the user's credit
card. That provides a user with an AVS authenticated certificate
information in a CA manufactured certificate ... that supposedly they
could present to some other party ... and the other party will
possibly put more reliance on the certificate version of the AVS
information than in the AVS transaction itself.
There is a similar but different scenerio for SSL domain name server
certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
"out of control credit card fraud"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/11/2001 8:54:59 AM
To: ansi-epay@xxxxxxxx
Subject: "out of control credit card fraud"
Hypercom Launches Attack on Credit Card Skimming; Hypercom Chairman
and Chief Strategist Calls for Industry To Combat New Dangerous Form
of Skimming
June 8, 2001
PHOENIX--(BUSINESS WIRE)--June 7, 2001 via NewsEdge Corporation -
(Hypercom Corporation)(NYSE:HYC) -- Credit card "skimming" is an
alarmingly escalating form of fraud that is victimizing consumers,
causing havoc with merchants, and costing the industry hundreds of
millions of dollars every year. Skimming fraud takes many forms, but
most often involves a cardholder turning over physical possession of
his or her card to a retail or restaurant employee, who then swipes
the card through a small, illegal card reader, called a "skimmer." The
skimmer copies the data encoded on the card's magnetic stripe. This
information is then used to manufacture counterfeit cards that are
used to rack up illegal charges. Industry sources estimate that the
average skimmed credit card will generate some $2,000 in fraudulent
charges before being detected.
"out of control credit card fraud"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/11/2001 11:33:41 AM
To: ansi-epay@xxxxxxxx
Subject: Re: "out of control credit card fraud"
full text at:
http://www.hypercom.com/web/news/display.asp?releaseID=346
call for new measures: ICH would be glad to help
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/18/2001 07:59:16 AM
To: "Fred Blommestein, van" <f.van.blommestein@xxxxxxxx>
cc: John@xxxxxxxx, ddjong@xxxxxxxx, fsollish@xxxxxxxx,
kevin@xxxxxxxx, dirk.dougherty@xxxxxxxx,
set-discuss@xxxxxxxx, obi-requirements@xxxxxxxx,
kaustin@xxxxxxxx.au, Graydon.Smith@xxxxxxxx,
adam.sharp@xxxxxxxx, nick.lewins@xxxxxxxx,
anders.rundgren@xxxxxxxx, Fulton.Wilcox@xxxxxxxx,
ansi-epay@xxxxxxxx
Subject: RE: call for new measures: ICH would be glad to help
how about X9A10 group ... it has gotten the X9.59 standard out and on
its way to ISO (financial standards group electronic payment for all
account-based (non-wholesale, like fedwire, swift, etc) payments.
it somewhat grow out of our work with a small client/server startup
called mosaic in the 94/95 era
nacha has completed its pilot and various networks are looking at
production deployments
random ref:
https://www.garlic.com/~lynn/
"Fred Blommestein, van" on 06/17/2001 09:52:22 PM wrote:
Hi John,
Initiatives that you certainly should include are:
Rosettanet (adam.sharp@xxxxxxxx)
BMEcat/Opentrans Germany (Oliver.Kelkar@xxxxxxxx)
EP-NL Netherlands (patricia.grijpma@xxxxxxxx)
Fred van Blommestein
Berenschot / EP-NL
<<< "John Weiler" 6/17 2:07p >>>
Anders et al,
I would like to propose should convene a meeting between multiple
e-commerce standards and user groups to discuss how we can further our
common goals.
Those that I believe would be interested are;
- Oasis (ebXML)
- OMG (new model driven architecture methods)
- Open Applications Group (defining application integration specs)
- IEEE 1471 (architecture specification nomenclature)
- UDDI (web based component directory based on SOAP and XML)
- Distributed Management Task Force (looking at low level interop. issues)
- Interop. Clearinghouse (defining validation methods) and
- OBI/CommerceNet (core standards for e-commerce transactions)
As these combined organizations together define the key elements for
internet computing, we should be able to establish common mechanisms for
addressing how we can help bridge the gap between the promise of standards
and implementation reality. The ICH has established liaison relationship
with most of these organizations, and would be glad to host a meeting this
summer in Washington DC.
Let me know if there is interest in collaborating with other standards
groups in the IT value chain of e-commerce.
john
703-768-0400
www.ICHnet.org
-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@xxxxxxxx]
Sent: Friday, June 15, 2001 9:41 AM
To: Wilcox,Fulton; Fred Sollish; Kevin Kienast; Fred Blommestein, van;
dirk.dougherty; obi-requirements@xxxxxxxx; John@xxxxxxxx; Dick
de
Jong; SET-List
Cc: kaustin@xxxxxxxx.au; Nick Lewins; Graydon.Smith@xxxxxxxx
Subject: Putting OBI 4.0 on the market may call for new measures
Hi,
This message is directed to all involved in OBI and e-commerce
standards in general.
THE #1 COMPETITOR: STATUS QUO
------------------------------------------------------
I have been closely following several [largely unsuccessful], efforts to
standardize new and unproved technology. A thing that few of the
involved parties understood, was that developing code for technically
complex and marketwise unproved systems involves huge risks and is
therefore not as attractive as one could think. And if they already have
something running the motivation to change is likely to be limited even
if the new thing offers very compelling advantages. Then there is the
problem that there usually is more than one competing standard.
THE #2 COMPETITOR: IT'S NOT THAT EASY TO BUILD IT EITHER
----------------------------------------------------------------------------
When things get as complex as for OBI, there is also the problem that
there may not be too many that are up to the task at all. OBI 3.0
requires understanding of what most young developers would call
"yucky" EDI which definitely is a limiting factor, while OBI 4.0 relies
on standard but still hard-to-use cryptographic functions that few
e-commerce developers so far have had any reason to bother with.
XML schema parsers which also is a corner-stone of OBI 4.0 are still
non-standard, in spite of being a hot topic for several years. I.e. we
are in a transitional period where the OS manufacturers still have
some major homework to do in supporting e-commerce.
FERTILIZERS MAY BE CALLED FOR
-------------------------------------------------------
Due to the previous roadblocks to success, one should seriously
consider making key-components available for free, to not stall
market acceptance. How could you make any money on that
someone probably rightfully wonders?
The free components could have soft [test/verification license] or
hard [cripple-ware] usage restrictions. The latter is not a good
idea in my opinion when a market is still in a "cautious" state
The major sources of revenues are probably not in components,
but in packaged products, system integration services, and in
running ASPs [which OBI 4.0 offers vastly improved support for].
DEPLOYMENT IS KING
-----------------------------------
Last by not least. If adoption becomes marginal, all parties that
invested money, time, and energy will lose most of their investment.
I.e. deployment is the really critical factor, regardless if you are a
SW vendor, consultant, or actually just want to perform e-business.
KIDS, DON'T TRY THIS AT HOME! [only]
-----------------------------------------------------------
Still I think that without public testing/debugging-, compliance-,
and proof-of-concept- (tryout) sites you get essentially nowhere.
This is in my opinion valid for all non-proprietary application-
oriented e-commerce standards, aspiring for market acceptance.
Regards
Anders Rundgren
CEO X-OBI
+ 46 70 - 627 74 37
MS masters NC mind-set (authentication is the key)
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2001 07:5s AM
To: ansi-epay@xxxxxxxx, dcsb@xxxxxxxx
Subject: MS masters NC mind-set (authentication is the key)
somewhat with respect to AADS NWI &/or some of the FSTC "FAST" proposals
http://iwsun4.infoworld.com/articles/op/xml/01/06/18/010618oppetreley.xml
WAKE UP, open-source community. The battle is not for the desktop; it is not for the server; it is not for the operating system; it is not for the development environment; it is not about the GNU General Public License (GPL) vs. Microsoft's business model. The battle is primarily about who will control user-authentication services.
somewhat related ... the nacha pilot (now complete) & AADS Option for Buyer Authentication
https://www.garlic.com/~lynn/nacharfi.htm
https://www.garlic.com/~lynn/aadsmore.htm#nacha
MS masters NC mind-set (authentication is the key)
From: Lynn Wheeler
Date: 06/21/2001 10:54:04 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: ansi-epay@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: MS masters NC mind-set (authentication is the key)
but it is trivial to show that DNS just has trusted operation with
real-time key distribution the very same way that it does real-time IP
address distribution (no certificates)
it is also trivial to show that for all the transactions that involve
account-based financial activity ... that certificates are redundant
and superfluous. in effect, certificates are useful for having 3rd
parties proove somebodies identity to a relying party when there isn't
prior business relationship between the parties ... and when it isn't
possible for the relying party to to contact a TTP with an online
infrastructure in real time.
The big problem for the real scenerio for a identity certificate in an
offline world for individuals ... is first finding an offline world
(i.e. instead of just trying to force fit an offline square peg into
an online round hole) and second not treading on privacy concerns by
spraying identity information all over the world on every transaction.
but otherwise ... it would seem we are in violent agreement with
respect to the importance of authentication ... but it should be at
least tempered by privacy concerns.
random refs:
https://www.garlic.com/~lynn/subpubkey.html#privacy
"Anders Rundgren" on 06/21/2001 08:31:37 AM wrote:
Lynn,
This is true! Authentication IS the key. For yearly subscription
fees as well!
This also makes me a firm believer that in the end [highly
controversial stuff here] there will be just two major CAs.
- Microsoft for individuals. What!?!? Passport/Hailstorm V3.0. I
have their plan...
- VeriSign/DUNS for organizations. DNS or DUNS as Global ID, no one
else can match that.
Open SRC has little to do with this. Lousy competition without visions is
still
the thing that makes it [according to some too] easy for MSFT to rule.
Anders
"Gurard against Identity Theft" (arrived in the post today)
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/21/2001 01:25:25 PM
To: ansi-epay@xxxxxxxx
Subject: "Gurard against Identity Theft" (arrived in the post today)
somewhat with regard to identity certificates being anti-thetical to
privacy
probably applies to others ... but this showed up in the mail today from
Navy Federal
Guard against Identity Theft
Don't give your Social Security Number (SSN) or credit card numbers to
anyone over the phone unless you know the caller personally or are
confident the organization is legitimate
Cancel unused credit cards
Limit the number of ID and credit cards you carry.
Order only from a secure Web site
Completely destroy copies of credit card receipts, financial statements,
etc. before discarding them
Check statements from financial institutions and verify account
information. Navy Federal Online, www.navyfcu.org, provides you with an
excellent means of reviewing your Navy Federal accounts at your convenience
Never give your Personal Identification Numbers (PINs) to anyone
Report unexplained interruptions in mail service to your local post office
Review you credit report once a year.
If you are a victim of Identity Theft:
Report Identity Theft incidents to the three credit bureaus: Trans-Union
(1-800-680-7289); Equifax (1-800-525-6285) and Experian (1-888-397-3742)
Contact Navy Federal or other financial institutions to obtain new account
numbers and PINs and have a code word placed on your accounts.
File a police report and obtain a report number for future reference
Report fraudulent use of your SSN by calling the Social Security
Administration at 1-800-289-0271
Obtain a new driver's license and number.
x959 Postings and Posting Index,
next, previous
- home