[3636] in cryptography@c2.net mail archive
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital
daemon@ATHENA.MIT.EDU (Lynn.Wheeler@firstdata.com)
Thu Nov 12 18:53:36 1998
From: Lynn.Wheeler@firstdata.com
To: cryptography@c2.net
Date: Thu, 12 Nov 1998 11:25:42 -0800
slightly different take on risk management in financial transactions. X9.59
is financial industry draft standard for all retail payments ... and is
based
on an AADS-model.
Account Authority Digital Signature
AADS
AADS is the application of digital signatures to electronic business
processes. At the simplest, AADS extends message integrity by
encrypting the MAC with the sender's private key (i.e. the definition
of a digital signature). The digital signature is used to perform two
operations: 1) authenticate the sender and 2) verify the integrity of
the message.
The current prevailing digital signature infrastructure, Certificate
Authority Digital Signatures, originated as a method of creating a
totally self-contained, atomic message environment for offline
operations (both sender authentication and message verification).
There has been efforts to extend the CADS infrastructure to an online,
anarchy model involving self-contained, authenticatable and verifiable
message (message contains all information for both authentication and
verification) exchange between random, unrelated parties.
The extension of the CADS to online business messages between parties
with existing business relationships has prooved more problematical. A
large stumbling block has been the CADS self-authenticated methodology
involves status (implemented in 'certifictes') information that is
easily out-of-date and/or stale compared to what is expected by many
business (including financial) practices.
The Certificate Authority infrastructure combines a message and its
digital signature (similar to the account authority method) with a
certificate containing the necessary additional information to perform
all necessary authentication and verification. A certificate is a
defined format, digital signed message containing the public key
necessary to verify the digital signature on the body of the main
message and whatever additional attributes necessary to authenticate
the message. This, in theory, creates a self-contained,
authenticatable, and verifiable message. Frequently a digitally signed
certificate message is referred to "binding" the public key to some
set of characteristics or attributes.
The original objective of the Certificate Authority infrastructure was
to allow two parties, who otherwise have no knowledge of each other,
to exchange messages, authenticate and verify the messages, and
appropriately act on the contents of the messages.
Extending the Certificate Authority infrastructure to the business
relm has prooved problamatical because accepted business practices
frequently rely on more timely attribute information than is easily
available in pre-distributed "certificates" (business transactions
commonly rely on account-records to provide timely attribute
information as part of acting on the contents of a message).
A basic assumption of the Certificate Authority infrastructure is
frequently invalid in the business scenerio. First off, for most
business messages, there tends to be pre-existing business
relationship (i.e. the two parties aren't anonymous and unknown to
each other). The business relationship between the two parties tend to
also be established with account-records which contain timely status
and attribute information specific acceptable for common business
practices (i.e. bank account balance).
Attempts have been made to modify the original premise of Certificate
Authority infrastructure to provide simple forms of timely status. In
one case, CRLs (certificate revokation list) have been created,
basically providing a mechanism to negate a whole certificate (because
one or more characteristics of the certificate is no longer
valid). CRLs and/or other certificate negation mechanisms require
something like an online account operation (and/or a highly structured
operations tailored to keeping up-to-date on revokation information).
For some time, accepted business practices have used account records
to "bind" business attributes. There are examples of where account
records include authentication information like signature cards,
mother's maiden name, social security number and PINs. From a business
process standpoint that currently supports account-record binding of
authentication information, it is a simple extension to include
public-key binding as an additional authentication methodology
(i.e. basically registering a public-key in the account record in
manner similar to the registration of other authentication
information).
Compared to an AADS implementation, for a business operation that
would implemenat certifcate-based authentication and which also requires
access to an account record in order to complete the business
operation ... then it is fairly easy to show that the certificate is
either superfulous (if the certificate is ignored) or represents
increased risk (if it is not ignored). If a business operation is
already dependent on the integrity of the account record, creating any
dependencies on the integrity of additional items increases the risk.
Simply registering the public key in the account record represents the
least processing risk to the business (given that it already has to
access and maintain the integrity of the account record) represents
the least processing and infrastructure risk. Adding a certificate to
the process, where processing has to validate any of the certificate
characteristics (and/or rely on external parties for up-to-date
information regarding the certificate validity) increases the
processing risk (by potentially significantly increasing the number of
things that the business process is now dependent on).
The emergence of "relying-party" certificates is one of the easiest
examples. To address consumer privacy issues and for liability
reasons, a certificate is issued by the relying party containing only
an account number and public key. The relying party keeps the
original certificate (or at a mininum the public key) and sends a
copy to the account owner. For every transaction with the relying
party, the sender tacks the certificate at the end of the message
after the digital signature.
Since the relying party has to read the account record containing the
original for every transaction .... one could claim that the only
purpose served by the certificate is to open the relying party to the
dubious risk of denial-of-service attacks against the relying party's
signing private key. If the appended certificate is totally ignored,
the public key is taken from the original in the account record, the
process works just fine and eliminates systemic risks, like attacks on
the relying party's signing private key. If the appended certificate
is not totally ignored, risk is increased; if the appended certificate
is totally ignored then the only function served by the certificate is
to dramatically increase the bandwidth requirements for most typical
business messages.
