there are two parts of certificate design point (not just one)
1) no prior relationship (i.e. except in the introductory stage, not
applicable for financial infrastructure)
2) offline (not applicable in the online payment infrastructure)
all things considered somebody that is being paid would prefer an online,
realtime notification that the financial institution says that the money is
available and is being transferred (i.e. if they get their money they don't
actually need to know who you are .... which is the EU directive that
point-of-sale electronic financial transactions are as anonymous as case).
it is only when things regress to pre-1970 technology into an offline world
that a poor 2nd choice is to know who you are ... as opposed do i already
have the money.
another payment scenario from pre-1970.. are corporate checks that had
signing limits printed on the checks (somewhat analogious to certificates
of a particular kind). they discovered that fraud was happening by people
signing 200 $5000 checks for $1m ... aka no real time aggregation. The
transition was made from signing check limits to real-time aggregation.
given an online infrastructure .... is it better to have transaction built
around stale, static data ... or transaction built around real-time
aggregation information.
The design point of "trusted" stale, static data (aka some sort of
credential or certificate) in an offline system is better than having no
information aka that was the original invention justification for
certificates .... not having an online system to get real-time, up-to-date
transaction aggregation information (if you are in a pre-1970 technology
situation ... with offline payment transaction ... then some sort of
certificate is better than not having anything). However, given that there
possibly is the availability of a post-1970 online technology ... that it
would appear to be a better choice to go with an online transaction as
opposed to an offline transaction paradigm.
Now some of the past payment related certificates have been in the 1k to 4k
byte range. There is significant portion of payment transaction that
currently operate with 80-100 bytes. The x9.59 mapping to ISO 85838
networks has one the order of 80 byte payload increase ... 42byte ecdsa,
fips186-2 signature plus misc. other information for increased integrity. I
believe that some of the x9 sixty-something certificate compression is
talking about a simple straight-foward something on the order of 300 bytes
for a ecc (163-bit) public key and a 42 byte ecdsa signature. note however,
that the whole design point for such a certificate is to be able to
authenticate an offline transaction ... since the certificate is redundant
and superfulous in online transactions processed by the customer's
financial institution. There is some push back on the unique information in
the x9.59 addenda since it almost doubles the size of existing payment
transaction. The pushback is even worse when considering an optimized,
compressed, 300-byte ecc certificate that is totally redundant and
superfulous and servces no valid business purpose.
Note however, that if such a certificate were to contain any identification
information and it was viewed by any but the customer's financial
institution then it would be in violation of the EU's anonymous directive.
Now, the financial institution doesn't need the certificate ... since it
already has all the information. The merchant doesn't need know anything
from the certificate if there is a realtime online transaction that gives a
real-time commitment from the financial institution that 1) it is a valid
transaction from 2) a valid customer account, 3) there is sufficient funds,
and 4) the bank is transferring the funds.
Part of this is that it is post-1970, there is significant world-wide
coverage for doing online transaction, that being able to do online,
real-time, payment authorization taken into account real-time account
transaction aggregated information .... is of higher quality than an
offline transaction with static, stale information possibly year or more
old.
with regard to legacy systems (including stove-pipe legacy systems), i made
the statement that there is a much larger upfront cost to integrate public
key support into existing production system ... as compared to the upfront
cost to deploy a brand new server with new operation (especially if it is a
simple SSL-like certificate manufactoring ... as opposed to full-blown
PKI).
The problems that have cropped up in financial consumer certificate issuing
(whether PKI or simple certificate issuing) ... is that there is the issue
of keeping a customer database. that customer database then has to
eventually have all the customer activity support as the "real" production
customer account database operation. The presentation made at NISSC
(previously mentioned) calculated that the cross-over point for financial
institutions between the upfront cost reduction of doing a separate PKI
operation ... as opposed to modifying the stove-pipe legacy stuff for
public key authentication was somewhere around 5 percent of the account
base. If financial infrastructure was looking at supporting less then five
percent of its customer base with public key authentication ... then a
separate PKI "stove-pipe" was probably cheaper. If the financial
infrastructure was looking at supporting public key authentication for more
than about five percent of its customer base ... then it was probably
cheaper to modify the existing stove-pipes (than it was to effectively
create a new and separate stove-pipe for PKI).
my statement has always been that a trusted static stale
certificate/credential is always better than nothing when you are in an
offline world and don't have access to real-time, online information.
However, for almost anything of importance or value ... given the
opportunity of doing either 1) a real-time online transaction or 2) doing a
offline, delayed transaction based on static stale certificate ... which
would one choose.
Given a infrastructure that is in general moving towards online, real-time
.... the multiple legacy stove-pipe situation would be aggrevated with yet
another (PKI) stove-pipe (in other than very early technology exploratory
pilot stages)
Given some infrastructure that is really an offline environment ... then it
is obvious that a trusted, static, stale credential/certificate is better
than nothing at all. The statement that certificates are redundant and
superfulous in an online, realtime payment transaction infrastructures is
in no intended to imply that they are totally useless and/or don't have
application. They were specifically invented for offline environment for
parties that have had no prior relationship/knowledge.
Something as an aside, the online payment infrastructure ... is in effect
an online certification authority paradigm ... with realtime online
ransactions as opposed to trusted static stale credential/certificate
offline paradigm. It turns out that the certificate issuing certification
authorities actually make extensive use of this realtime online feature for
some number of consumer/client certificates they issue. They effectively
take a credit card in payment for the credential they issue ... and for the
basic credential type with name and address use the name/address
verification option of the realtime credit card transaction as the means of
checking the name and address. There are some number of other web-based
"certification" sites (some doing realtime transactions in lieu of static
stale credentials and others that issue a form of short-lived credentials
... possibly analogous to kerberos tokens) that also rely on the
name/address verification option of the realtime credit card transaction as
the means of checking name and address.
[EMAIL PROTECTED] on 5/30/2002 8:25 am wrote:
Lynn,
You do put an interesting interpretation on things.
A few points worth noting:
(1) Letters of credit are very much alive, today, having
survived the invention of the telegraph, the telephone, and, so
far, the invention of the Internet. They are in regular use for
lots of global commerce activities. There are even electronic
versions of letters of credit. Suffice it to say that there is
still value in being able to extend one's business reputation
(credit) beyond one's normal domain of operations.
(2) To put things in perspective, the primary contributors to
the "onerous payload" in X.509 certificates are the public keys
themselves. Next are the signature blocks of the issuers. Basic
X.509 certificates do little more than provide the name of the
subject of the certificate, the name of the issuer, and some
basic management information, such as the starting and ending
dates for when the cert is valid. Plastic mag-stripe credit cards
actually carry a lot more information than do basic X.509 certs
(although public keys are longer than credit card numbers). True,
there are lots of optional fields and extensions in the X.509
standards, but even when these are used, they generally don't add
that much bulk (unless someone really does stick the entire
certificate practice statement into the cert). [Please, before
you respond with a list of your favorite stats on cert size and
hyperlinks to your voluminous archives, read on and recognize
that none of this really matters until we better understand what
we're trying to accomplish.]
(3) While it is true that you don't need a cert in the case
where the issuer is the only party that will rely on the cert,
this is not the typical case in most business situations. Even
banks tend to have lots of stovepipe operations that have no good
internal means for sharing information about customers and their
reputations. Many other businesses are also comprised of multiple
stovepipes. There may also be good reasons that the "Bank of
England" (to cite your example) might issue a letter of credit to
a customer based in England to help facilitate their opening of
an account at the Bank of England branch in some other part of
the world. If all the legacy systems in place today could
effectively exchange information in a trustable fashion, then
maybe such "inefficiencies" would not be required--but they don't!
It might also be worth noting that payments are between _payers_
and _payees_. Goverment Treasuries, banks and payment service
providers merely facilitate the payment transactions and provide
some "insurance" for a subset of the payment transactional risks.
The key point is that payer-payee transactions are highly
distributed in nature, and often between parties that have little
or no transactional history with each other. Just a suggestion,
but maybe we need to focus a bit more on how to facilitate
payer-payee interactions and give payers and payees the tools
they need to manage the very real risks they confront with every
payment transaction.
The reason I provided some commentary on the editorial by Scott
Berinato was that I'd like to see the industry dialogue move away
from arguments about the machinery, and to more on-topic
discussions of what it will take to create viable payment
applications that can be conducted safely over the Internet. With
a better understanding of user needs, system requirements, and
appropriate architectures for new payment applications, perhaps
we will then have the insight to intelligently evaluate what
sorts of machinery will actually serve our purposes.
As I've already emphasized, the PKI approach is on the wrong
path. But, if you'll forgive me for saying so, I contend that
your approach is also not showing a great deal of promise these
days. To be honest, only a narrow set of applications is served
by a model where the issuer of public key credentials is also the
only relying party. This might work for some highly centralized
application models with rigid constraints on the relationships
between the players. It is, perhaps, even a good model for
extending some legacy systems, especially where closed protocols
and networks are used.
Personally, I think it is a good idea to look at how new payment
applications can leverage, and even extend, legacy payments
infrastructure. On the other hand, I think it would be a mistake
to continue the practice of stamping out new payment applications
and innovative approaches for the sake of protecting existing
payment system franchises that are protected by closed systems
designs and technological constraints from the 70s and 80s. But
that's just one man's opinion.
Regards...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137 Office Phone/Voice Mail
+1 309 422-9871 Fax Service
