Dave,
While we are trying to sort out charters for a retail payments working group, I
notice that there is a substantial overlap of interest between the community of
interest represented by the pem-dev list, the e-payments list (and possible
others), and the new WG to be. Already many messages get posted to two or more
different lists.
I would suggest that there are three subject areas that are of great interest
in the electronic commerce field:
1. A means for negotiating the price and specifications for the goods or
services being ordered.
2. A means of agreeing to exchange goods or services for payment, whether by
debit or credit card, electronics checks or negotiable order of withdrawal, or
by digital cash, i.e., a payments protocol.
3. For systems based on digital signatures, at least, the technical, legal,
and business issues involved in establishing a national or international public
key infrastructure, especially the certification authorities and certificate
distribution/revocation services, and potentially other trusted third party
services such as secure timestamping, CyberNotarial services, archiving, etc.
If I understand the public announcements made by Visa and MasterCard correctly,
they are anticipating having working systems available asnd in use by real
customers by April of 1996. Presumably Microsoft and Netscape are already
busily developing the consumer software to be used, and I haven't any idea who
is developing the merchant and acquiring bank software. But if that timetable
is achievable, and if the IETF is to play any kind of a significant role in
this process, the scedule for the working groups will have to be sharply
compressed.
Presumably there has already been a lot of work done on the prices and
specifications negotiation topic within the EDI community, but I don't know how
applicable that will be to the retail, Internet environment. I don't even know
what kind of basic mechanisms are being proposed -- I've heard everything from
new MIME body parts to WWW forms to secure http suggested. But this part of the
overall electronic commerce protocol is obviously fundamental to everything
else, and would appear to require a forced draft effort. I would suggest that
the ietf-payments list be used to focus like a laser on that problem, with a
goal of producing a draft RFC no later than 1 October.
It appears that the banking/credit card industry is set to adopt the iKP
payment protocol, perhaps with minor changes. This may not satisfy all possible
users -- presumably First Virtual, CyberCash, DigiCash and others will continue
to have their supporters, and they should be encouraged to develop appropriate
standards for those applications and new ones that may appear. But in the
meantime it looks like iKP will be the mainstream protocol for the credit card
model. That's fine, but there is still a lot of work to be done. To use Nitin's
taxonomy, in this case we know the policy model -- it's the existing credit
card model, and we pretty well understand the mechanism model -- it's going to
be 3KP. Now we have to roll up our sleeves and work out the precise dataflow
requirements.
For example, in all of the iKP versions, the first step of the process is for
the merchant to provide the customer the certificate of the acquiring bank,
together with the merchant's own certificate. But how does the merchant get the
acquiring bank's certificate? In particular, if the acquiring bank changes its
working key occasionally (certainly prudent), a new certificate must be
generated by the acquiring bank's CA. Who is that CA, and how does the customer
know that CA should be trusted? Oh, I see -- the merchant must transmit the
acquiring bank's certificate, together with all of the rest of the certificates
in the chain up to the root CA, whatever that is. Presumably the public key of
the root is included in the customer's software package, and never changes.
(Never? What would happen in the event that root key were compromised somehow?)
Suddenly 50 million users have certificate chains that theoretically cannot be
trusted any longer. How do they get a new universal public key, and how do they
are get new certificate chains overnight?)
Does the merchant have to download the acquiring bank's certificate chain for
every transaction? If not, what other mechanism will be used to notify the
merchant of a key change? Is it really necessary for the merchant to include
its certificate when passing the customer's payment request on to the acquiring
bank? Wouldn't the acquiring bank already know it? These are not rocket science
issues, but they do have to be thought through.
Likewise, 3KP requires the merchant to pass the customer's certificate to the
acquiring bank, and presumably that means the entire certificate chain. But is
this really the best way to provide the certificate to the merchant? Or would
it be more efficient to simply pass the certificate by reference to a issuing
bank and account number, or to a certificate issuer and certificate serial
number, assuming that the acquiring bank has access to X.500 or some other
directory maintained by the customer's CA?
And what algorithms are going to be used? From the standpoint of computational
efficiency at the acquiring bank (which is likely to be the bottleneck, or at
least require the most cryptographic hardware), it might be worth considering
using RSA for anything that has to be verified by the bank but use DSS for
anything that has to be signed by the bank, since RSA is faster for
verification and DSS faster for signing. (This assumes that the user has
adequate computational power available, and that an additional second or two
per transaction won't matter to her.)
I would suggest that the existing e-payments list be used to focus exclusively
on these problems, again with the goal in mind of producing an RFC specifying
the dataflow in detail by October 1.
Finally, there are a number of serious issues which involve the certification
authorities, the format of the certificate to be used, the CA policy
constraints, etc. I am hoping that it will be possible to use certificates
generated by the credit card industry for other purposes, such as for securing
e-mail. But that will require us to support whatever industry-specific data
fields may be required, presumably using X.509 version 3
subjectDirectoryAttributes. The syntax and semantics of those attributes have
to be standardized as soon as possible, so that the application software can be
developed.
But I suspect that before we can convince the credit card industry to use a
general purpose certificate format which would promote the general PKI
infrastructure, they are going to have to be convinced that their liability can
be adequately specified and delimited, which probably means that we need a way
to include policy statements and disclaimers in the certificate. And since the
banking CAs will want to ensure that those disclaimers are forcibly brought to
the attention of anyone who is tempted to rely on one of their certificates for
anything other than credit card transactions, those policy attributes will
probably have to be marked as CRITICAL, so that applications that aren't
prepared to handle them properly, i.e., display them to the user for any
application that isn't already aware of the constraints, will rejecf them or at
least put the user on notice that he is on thin ice if he relys on the
information.
Because these issues are of considerable interest to the rest of the digital
signature community as well, I would suggest that this discussion be carried
out on pem-dev, and that a WG be chartered to specifically address these
issues.
The American Bar Association's Information Security committee has been working
in this area for more than a year, and a first exposure draft of their Digital
Signature Guidelines and Model Act should be published for public comment in
September. X9.30 has also done some work in this area, especially in refining
concepts for certificate revocation and temporary suspension. But I think it
would be useful for the IETF to take a look at these issues from a global
Certification Authority infrastructure perspective, and offer appropriate
advice to those segments of the industry which will be developing and deploying
CAs during the next year. I'd like to see an RFC written that takes the X.509
v3 PDAM written largely by Warwick Ford and extend it to cover some of these
industry specific problems. We need to agree on precisely which new attributes
will be essentially mandatory for the credit card model, which may be
implementation options, and which may not be needed at all, for otherwise
interoperability is going to be almost impossible.
Comments?
Bob
--------------------------------
"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>
Staff Scientist, Wireless and Secure Systems Laboratory
GTE Laboratories, 40 Sylvan Road, Waltham, MA 02254
Waltham office: Voice: 1-617-466-2820, FAX: 1-617-466-2603
Telecommuting: Voice: 1-508-264-0485, FAX: 1-508-264-4165