Re: EMV cards as identity cards

[lynn . wheeler]

i have pointed out in multiple threads and numerous times (a number of
times when you have raised this or similar question in the past)  that
there has been some history of x.509 identity certificates from the early
90s and that the in the mid-90s, many financial institutions around the
world retrenched to relying-party-only certificates  because of the
enormous privacy and liability issues associated with the x.509 identity
certificates. I was at a presentation by one of the large german banks at
the 1998 21st nissc conference in DC ... on the enormous privacy and
liability issues associated with x.509 identity certificates and the
requirement for relying-party-only certificates (effectively only
containing an account number and public key). There were payment
transaction designs and deployments from the mid-90s that also used
relying-party-only certificates and had made some reference to the enormous
privacy and liability issues associated with x.509 identity certificates.

lots of past postings on relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

the issue that i've also pointed out multiple times in the past is that for
online transactions involving replying-party-only certificates, that the
relying-party-only certificates can typically be shown to be redundant and
superfluous ... since the relying-party is the issuing party ... and
therefor already has a registered copy of the public key (typically stored
in an account record which will be referenced as part of any online
transaction). the ancillary issue from some of the payment transactions
from the mid-90s using relying-party-only certificates for online iso 8583
payment transactions was that there was enormous payload bloat with various
relying-party-only certificates being approximately two orders of magnitude
larger in size than typical base iso 8583 transactions.

there has also been some sporadic discussions that sometimes there is
confusion between identification and authentication and that there are
times that identification has been specified when authentication would have
been sufficient.


at 9/21/2004 12:27 am, anders wrote:

Exactly what are you addressing here???

1. That EMV is a bad idea since it (optionally) uses PKI?
Could very well be so but EMV is also an off-line thing as
the EMV founders incorrectly thought that not many countries
could afford broadband!  Regardless how right of wrong this
assumption may be, those who actually are prepared to convert
to accepting chip-cards, probably have broadband as well.
That is, a core EMV idea is indeed ill-founded!

2. That ID certificates are redundant?
As ID certificates is an FI add-on service to be used by thousands
of independent e-gov relying parties using a common national identity
scheme, there is no viable alternative to PKI except using a gateway
approach which is fairly much the same  trust wise.  The difference
is that some people do not believe that gateways can sign but
schemes running in Norway shows that this is piece of cake.
At least technically!

Anders

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Re: FSTC Project Update

[Anders Rundgren]

Jim,
Thank you for this information.

http://fstc.org/projects/FSTC_E-Auth_Prospectus_FINAL.pdf

Although I do not plan to attend please let me pass some information
related to the a-authentication project.

The most advanced such service running to date is probably the
Norwegian BankID.no, that has a SAML-like authentication but
also offer signing services using portal-based technology.  That is,
signatures are also created on a server and no keys are ever
distributed down to the clients.  For authentication to the server
which is of course of prime importance, One Time Passcode
(OTP) schemes are used, ranging from SecurID and similar, to 
scratch cards.

BankID.no's scheme enable citizens to access e-government
services from virtually any computer as no local software
installation is required.

A further advantage of a portal-based auth and sign system is
that since all operations are logged, possible disputes are
easier to cope with.  In addition to offer citizens a possibility
to actually verify that they indeed signed something a certain
day etc.

Anders Rundgren
e-authentication developer

- Original Message - 
From: "Jim Salters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 20, 2004 21:06
Subject: FSTC Project Update


To: FSTC Members and Friends
From: Jim Salters, Director of Tech Initiatives and Project Development

*** September Project Update ***

After a busy summer season of meetings and project development, a number of
FSTC projects are poised to launch, as well as a strong pipeline in
development.  Our Standing Committees (SCOMs), especially those in Business
Continuity, Security, and Check Imaging and Truncation, continue to broaden
their participation, and build upon a foundation of dialog and action that
leads to FSTC projects.  In the past few weeks, we issued two new calls for
participation: e-Authentication Proof-of-Concept, and Business Continuity
Compliance and Status Reporting.  See http://fstc.org/projects/new.cfm .

In addition, we have recently completed projects in Image Quality and
Usability Assurance Phase I, Technology Recovery Best Practices, and
Survivability of Check Security Features.  Details on these recent projects
can be found at: http://fstc.org/projects/past.cfm .

FSTC provides an action-oriented, collaborative forum for our members to
address shared business opportunities and challenges through technology
projects and knowledge-sharing.  We view our projects as our core activity,
and one of the key benefits of FSTC membership is eligibility to participate
in these projects.  In our efforts to keep our members and friends
up-to-date on the latest developments in these active and developing
initiatives, we provide our colleagues this periodic project update  As
always, please contact me or Zach Tumin, FSTC Executive Director, for more
information.  Or visit our website at http://fstc.org.

Active Projects:

1.  Counter-Phishing Phase I 

Projects in Formation:

1.  e-Authentication: Business and Technology Proof-of-Concept (call for
participation issued 9/8)
2.  Business Continuity: Compliance and Status Reporting (call for
participation issued 9/8)

Projects in Development:

1.  Image Quality and Usability Assurance Phase II 
2.  Survivability of Check Security Features Phase II 
3.  Treasury Services Integration: Data Exchange and Customer Connectivity
through Web Services 
4.  Transformation to Open Mission Critical Systems 
5.  Minimum Essential Finance (MEF) 
__

ACTIVE PROJECTS:

1.  Counter-Phishing Phase I (launched July 2004, expected to complete in
December)

http://fstc.org/projects/counter-phishing-phase-1/
 
FSTC has launched a phased initiative to address the problem of phishing and
related threats in financial services, as it affects the relationship
between customer and firm.  In collaboration with other industry groups,
FSTC will focus on defining the unique technical and operating requirements
of financial institutions (FIs) for counter-phishing measures; investigating
counter-phishing technical solutions, proving and piloting solution sets
enabled by technology to determine their fit against FI criteria and
requirements; and clarifying the infrastructure fit, requirements, and
impact of these technologies when deployed in concert with customer
education, enforcement, and other industry initiatives.  The benefits to
participants are: industry-vetted due diligence and scaling of the current
problem and its future evolution; insight into peer institution strategies
and assessments; and definition of an industry response that may be best
undertaken with collaboration between key industry segments.
 
12 financial institutions and over 15 technology companies are participating
in the 5-month first phase.  This project originates from the Security SCOM:
co-chaired by Mike McCormick of Wells Fargo, and Mike Versace of NEC.
Please contact FSTC Managing Executive Gene Neyer for more information
([EMAIL PROTECTED])