Subject: simple (ANSI) debit/credit protocol

From: [email-masked]
Date: Mon, 8 Nov 1999 10:57:54 -0800

the following is discussion of increase the LUID in x9.59->8583 mapping from 8
bytes to 16bytes ... which turned out for the purpose of inserting some sort of
truncated hash into the field. The original description of the LUID was that the
consumer could effectively use it as a transaction identifier ... in a manner
similar to check registry and that the debit/credit statements would be modified
to print the LUID information (i.e. that consumer then could cross-fit entries
from transaction registry with what was on the montly statement)

.... attachment

part of the the point for the x9.59 addenda field size discussion is that I get
abused by the operational people for every additional byte (in the addenda
field) that would have to flow thru a production network.

If it is a hash of some long unique string identifier ... then I assert that the
10% payload increase  hit to the payment infrastructure is not justified by the
near negligible business benefit of trying to cram a hash of some long unique
string identifier into the LUID.

In fact, the incremental business benefit would justify driving the x9.59
addenda field definition such that the supported LUID (at this state of
production interchange networks) to 4 bytes (which would show up as
4,000,000,000/4billion number in statement).

I assert that there is already a SHA1(OD) in the payment object and I assert
trying to cram a second hash of unique string identifier is superfulous.

Lets say that SHA1(unique string) truncated to 16 bytes (as in the LUID) meets
some requirements.

Then the existing SHA1(OD) in the object identifier meets those same
requirements or it doesn't.

If the existing SHA1(OD) does not meet the requirements for SHA1(unique string)
... then I assert for all possible functions F(OD, SHA1(unique string)),
combining OD and SHA1(unique string) ...that SHA1(F(OD, SHA1(unique string))
exceeds any requirements of a 16byte truncated SHA1(unique string).

Simple example would be to define that the "order detail" contains a customer
defined identifier which is

ODi = cancat(ODo, SHA1(unique string))

i..e. where cancatenating SHA1(unique string) is an acceptable F(OD, SHA1(unique
string).

typical ODo are likely to be in the range of several hundred bytes to several
thousand bytes ... so the incremental merchant overhead on ODo is a couple
percent or less ... and only occurs on the cuustomer/merchant exchange.

Then the ODi is sent to the merchant along with the signed payment object. The
signed payment object contains SHA1(ODi) ... and the merchant can recompute
SHA1(ODi) and verify it against the SHA1(ODi) in the payment object before
processing the order.

In the payment card case, the merchant can forward the 8583 transaction along
with the x9.59 addenda field. This x9.59 addenda field contains (for
identification purposes), at least a 4 byte LUID, the customers YYYYMMDDHHMMSS
(8 byte packed decimal date/time) and the SHA1(ODi). Reducing the LUID from 16
bytes to 4 bytes reduces the existing X9.59 addenda field definition from 88
bytes to 76 bytes.

We would advocate that standard statementing be enhanced to print the 4 byte
LUID on the statement for each item in addition to the existing identifying
information. For applications for which this isn't sufficient (i.e. 4 billion
count), then suggest those requirements be satisfied with an electronic
statement that has the x9.59 addenda field appended to every item detail.

For those applications they then have the following choices for identifying the
items:

* 20 byte               SHA1(ODi)
* 7+4=11 byte      yyyymmddhhmmss.LUID
* 20+7=27byte     SHA1(ODi).yyyymmddhhmmss
* 20+4=24byte     SHA1(ODi).LUID
* 20+7+4=31byte SHA1(ODi).yyyymmddhhhmmss.LUID

The assertion is that SHA1(F(OD,SHA1(unique string)) is a significantly better
business solution to the requirement and results in no incremental payload
burden on the payment infrastructure to meet its requirement.

The SHA1(F(OD,SHA1(unique string)) then can be used for both validating the ODi
in any dispute as well as serving as a customer unique identifier ... and it is
20bytes instead of only 16. If the 20 bytes isn't sufficient, then the
application can use some concatenated identifier combination of SHA1(ODi),
customer date/time, and LUID (possibility of 31bytes)

The proposed revised x9.59 addenda field then (with 4 byte LUID) is 76bytes or
36bytes with the 40 byte DSS digital signature.

There are a couple breaking points:

* some merchant acquiring interfaces use 80 byte fixed length records, having
the addenda field 80 bytes or less means that the addenda  field can be
transmitted in a single record rather than two

* trying to fit the addenda field into existing interchange 99byte field

* trying to minimize the amount of abuse I have to take from the operational
people on every additional byte that adds load to the existing operational
infrastructure

Note that in the above ... the unique string doesn't have to be transmitted to
the merchant ... only the SHA1(unique string) combined in some manner with the
order detail ... in effect, the SHA1(unique string) becomes a customer
identifier for the order detail information ... which is a useful thing in
itself ... and outside of the scope of the payment infrastructure. Then as a
fall-out of SHA1(F(OD, SHA1(unique string))) ... it becomes both a customer
identifier and also a validation of the order detail involved in the payment
.... w/o any increase in payload overhead impacting the payment infrastructure.

more detailed reference at:

http://www.garlic.com/~lynn/8583flow.htm

Now to the EC/DSS signature size. DSS/FIPS186 has r and s defined as 20bytes
each resulting in a digital signature of 40 bytes. The proposed revised X9.59
addenda field is then 36 bytes plus 40 bytes for a total of 76 bytes.

For EC/DSS, r and s size is defined to be the order of the field. Previously,
work has been done using fields n=160 resulitng in EC/DSS r and s being the same
size as DSS/FIPS186. The NIST recommendations is that n>160; two fields being
considered are n=163 and n=192.

For n=163, the EC/DSS r & s are then 21 bytes each and the digital signature is
42 bytes. The x9.59 addenda field then becomes 36bytes plus 42bytes equals
78bytes. This fits within some 80byte acquiring limits w/o having to use two
records and the 99byte limit.

For n=192, the EC/DSS r & s are then 24 bytes each and the digital signature is
48 bytes. The X9.59 addenda field then becomes 36bytes plus 48 bytes equal
84bytes. For those acquiring implementations that implementing 80byte fixed
length records, they will have to transmit the X9.59 addenda field as two
records. It does fit within any interchange mapping to 99 byte field.

If convention is that the 36byte part is first, and the signature is at the end
of the field, then any variability in the size of the field is based on
variability in the digital signature size.

It is believe that the current credit & debit production infrastructures are, in
some sense, at a stage compareable to n=163 ... i.e. the 78byte addenda record
with n=163 matches current production operation. It is anticipated that the
production infrastructure will evolve over time and be adequate level to handle
increases in sizes discussed for both larger secure hashes (>20bytes) & larger
EC/DSS signatures (>42bytes).

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]